Diagnostiquer un LCP lent : trouver la cause avant de corriger

Pour diagnostiquer un LCP lent, identifiez l'élément mesuré et reconstituez ce qui précède son affichage. Le poids d'une image peut être en cause, mais aussi sa découverte tardive ou un traitement qui retarde le rendu. Modifier toutes les images du site sans cette observation risque de traiter le mauvais problème.

Fixer une page et des conditions de mesure

Choisissez une URL représentative et notez l'appareil simulé, la taille de fenêtre, l'état du cache et l'heure de l'essai. Conservez le rapport complet, pas seulement la pastille de score. La documentation du LCP décrit cet indicateur d'affichage et les éléments admissibles à sa mesure.

Comparez des essais effectués dans les mêmes conditions. Une page mobile et sa version large peuvent avoir des candidats LCP différents. Un résultat isolé ne permet pas non plus de distinguer une variation de réseau d'une régression introduite par le code.

Remonter de l'élément vers son attente

Dans un enregistrement de performance, relevez l'élément associé au LCP. S'il s'agit d'une image, cherchez sa requête dans le panneau Réseau (Network) des outils de développement et comparez sa chronologie. Est-elle demandée rapidement ? Sa réponse arrive-t-elle tard ? Reste-t-il un délai entre la réception et l'affichage ? Pour un texte, examinez les ressources et traitements nécessaires à son rendu.

Consignez une hypothèse à la fois : découverte tardive, ressource inutilement volumineuse, réponse lente ou affichage empêché. Cette liste ne constitue pas un diagnostic automatique. Elle organise l'essai suivant et vous oblige à préciser la preuve qui ferait abandonner votre hypothèse.

Exemple fictif : une image principale masquée

Imaginons une page d'atelier dont l'image principale est téléchargée rapidement, mais reste invisible jusqu'à la fin d'une animation. Une compression supplémentaire peut réduire quelques octets sans supprimer l'attente qui retarde l'affichage.

Préparez une version de test où l'image est visible immédiatement, avec les autres réglages inchangés. Refaites l'enregistrement, identifiez à nouveau le candidat LCP et comparez les chronologies. Si l'élément mesuré change, signalez-le : les deux valeurs ne racontent plus exactement la même séquence.

Votre fiche contient l'URL, la version du code, le candidat, l'hypothèse, la modification et le résultat observé. Ce scénario fictif propose une méthode ; il n'annonce aucun gain constaté sur un site réel.

Corriger puis surveiller les effets voisins

Si le problème vient de la ressource reçue, vérifiez les images responsives et leurs indications de largeur. Si le retard apparaît ailleurs, gardez une modification ciblée et revenez à la chronologie plutôt que d'appliquer une liste d'optimisations sans ordre.

Après correction, contrôlez les autres pages qui réutilisent le composant. Distinguez également cet essai des données de visiteurs en suivant le guide pour lire PageSpeed entre laboratoire et terrain. La présentation de PageSpeed Insights explique cette coexistence de mesures.

Questions fréquentes

Le LCP correspond-il toujours à une image ?

Non. Identifiez l'élément réellement retenu dans votre mesure. Optimiser une image parce qu'elle semble importante visuellement peut ne pas agir sur le candidat observé.

Faut-il tester seulement la page d'accueil ?

Non. Les modèles de pages peuvent charger des ressources différentes. Choisissez plusieurs pages représentatives et conservez un résultat séparé pour chacune.

Un bon essai local prouve-t-il que les visiteurs voient la même chose ?

Non. Il valide une observation dans un environnement précis. Les appareils, les réseaux, les caches et les parcours réels peuvent produire d'autres conditions.