Diagnostiquez le LCP avec le panneau Performance de Chrome DevTools

Ce guide fait partie du hub Largest Contentful Paint (LCP). Il couvre un seul outil : le panneau Performance des DevTools de Chrome. Vous allez enregistrer une trace bridée, lire les quatre sous-parties du LCP et repartir en sachant laquelle corriger en premier.

Les DevTools viennent à la fin, pas au début

Le panneau Performance est un outil de laboratoire. Il mesure un chargement de page, sur un appareil, sur un réseau : le vôtre. C'est le mauvais endroit pour commencer et le bon endroit pour terminer.

Commencez par les field data. CrUX vous indique si le LCP est vraiment un problème. Les données RUM vous indiquent quelles pages et quels éléments sont lents pour vos vrais utilisateurs. Ce workflow est couvert étape par étape dans Fix & Identify LCP Issues. Les DevTools répondent ensuite à la seule question restante : pourquoi.

Si vous ignorez les field data, vous finissez par optimiser la page que vous testez sur la connexion que vous avez. C'est le schéma que je vois sur presque chaque audit : la machine du développeur passe, le p75 de CrUX échoue et tout le monde est confus. Vous avez mesuré un ordinateur portable rapide sur la fibre. Vos utilisateurs sont sur un Android milieu de gamme dans un train.

La vue des métriques en direct

Ouvrez les DevTools (Ctrl+Shift+I sur Windows et Linux, Cmd+Option+I sur Mac) et allez dans l'onglet Performance. Le panneau ne s'ouvre plus vide. Avant d'enregistrer quoi que ce soit, il affiche une vue des métriques en direct avec le LCP, le CLS et l'INP de la page où vous êtes, mesurés localement pendant que vous naviguez.

Trois éléments de cette vue servent au travail sur le LCP. D'abord, elle nomme l'élément LCP. Le survoler met l'élément en évidence sur la page. Vous n'avez pas à deviner quelle image ou quel titre le navigateur a choisi. De plus, vous pouvez activer les field data dans cette vue. Les DevTools récupèrent alors les chiffres CrUX pour l'URL et l'origine et les affichent à côté de vos valeurs locales. Si votre LCP local affiche 0,8 seconde et le p75 des field data affiche 3,1 secondes, cet écart est votre première découverte : votre machine n'est pas représentative et le bridage n'est pas optionnel.

Astuce rapide : si vous voulez que l'élément LCP soit mis en évidence sur n'importe quelle page sans ouvrir les DevTools, utilisez notre extension Chrome gratuite Core Web Vitals Visualizer.

Bridez avant d'enregistrer

Une trace non bridée sur une machine de développeur ne vaut presque rien. Les chiffres seront excellents et aucun ne correspondra à ce que vivent vos utilisateurs. Configurez le bridage du CPU et du réseau dans le panneau avant d'enregistrer.

• Bridage du CPU : utilisez un ralentissement de 4x par défaut pour les tests mobiles. 20x correspond environ à un appareil bas de gamme. Les versions récentes de Chrome peuvent aussi calibrer des profils selon votre machine spécifique : l'option Calibrate génère des profils mobiles de bas et milieu de gamme selon la vitesse de votre propre matériel. C'est important car 4x sur un ordinateur de bureau rapide est un appareil très différent de 4x sur un vieil ordinateur portable.
• Bridage du réseau : utilisez Slow 4G. C'est le profil qui s'appelait Fast 3G avant que Chrome ne le renomme. C'est ce que Lighthouse simule pour le mobile. Fast 4G est l'option plus légère pour tester de meilleures connexions.

Quand les field data sont activées, les DevTools peuvent même recommander un profil de bridage qui correspond à ce que vivent vos vrais utilisateurs. Utilisez-le. Pour comprendre tout le raisonnement derrière ces paramètres, consultez notre guide sur les meilleurs paramètres réseau des DevTools pour les Core Web Vitals.

Enregistrez un chargement de page

Cliquez sur le bouton « Record and reload ». Chrome navigue vers une page blanche, démarre la trace, charge votre page et arrête l'enregistrement tout seul quelques secondes après la fin du chargement. Pour le LCP, vous n'avez besoin de toucher à rien pendant l'enregistrement. Gardez vos mains loin de la page.

Astuce rapide : enregistrez dans une fenêtre de navigation privée avec les extensions désactivées. Les extensions injectent des scripts dans chaque page. Ces scripts apparaissent dans votre trace comme des long tasks qui n'ont rien à voir avec votre site.

Lisez l'insight LCP breakdown

Une fois la trace terminée, la barre latérale Insights à gauche liste ce que les DevTools ont trouvé. Celui que vous cherchez est l'insight LCP breakdown (les anciennes versions de Chrome l'appellent LCP by phase). Il divise le temps du LCP en ses quatre sous-parties :

Pour un LCP textuel sans webfont, il n'y a rien à télécharger. Les deux sous-parties de ressource sont à zéro. L'histoire complète se résume au TTFB plus le délai de rendu.

Survolez une sous-partie dans l'insight et les DevTools mettent en évidence cette fenêtre exacte dans la timeline. Cliquez dessus et la timeline zoome. Vous pouvez ainsi voir quelles requêtes et tâches tombent dans cette fenêtre. Et si vous avez activé les field data, l'insight affiche la valeur p75 de CrUX à côté de chaque sous-partie lab (quand CrUX a des données LCP d'image pour votre site). Cette comparaison est la fonctionnalité la plus sous-estimée du panneau. Elle vous indique si la trace que vous regardez ressemble à ce que vivent réellement vos utilisateurs, avant d'y passer un après-midi.

À quoi devrait ressembler une décomposition saine ? Les directives de Google indiquent que les deux sous-parties de délai devraient être proches de zéro (moins de 10 % du LCP chacune). Presque tout le temps devrait aller au TTFB et au téléchargement réel. Notre propre recherche sur les Core Web Vitals sur des millions de chargements de page montre à quel point la réalité en est loin : le TTFB prend 48 %, le délai de chargement 24 %, la durée de chargement seulement 10 % et le délai de rendu 17 %. Relisez cela : sur le site médian, les deux phases d'attente combinées gaspillent quatre fois plus de temps que le téléchargement lui-même. Rien ne se télécharge pendant ces phases. Rien ne s'affiche non plus. Le navigateur attend du travail qu'il aurait pu commencer plus tôt. C'est pourquoi ces deux sous-parties sont le premier endroit où chercher des gains.

L'insight LCP request discovery

Quand le LCP est une image, un deuxième insight vaut la peine d'être ouvert : LCP request discovery. Il exécute trois vérifications sur la requête LCP :

• Est-ce que fetchpriority="high" est appliqué à l'image (ou à son preload) ?
• La requête est-elle découvrable dans le document HTML initial ?
• Le lazy loading est-il correctement non appliqué à celle-ci ?

Tout échec à une vérification signale un problème de découverte. L'insight annote aussi la timeline avec le moment où l'image aurait pu commencer à se télécharger et une estimation du temps que vous perdez. Chacun de ces trois échecs a une solution concrète. Ils sont tous couverts dans le guide Resource Load Delay.

Lire la timeline vous-même

Les insights couvrent les cas courants. Pour tout le reste, vous lisez la trace directement. Trois pistes comptent pour le LCP.

La piste Timings affiche des marqueurs pour le FCP, le LCP, le DCL et l'événement load. Le marqueur LCP est le moment où l'élément a été affiché. Tout ce que vous diagnostiquez se passe à sa gauche.

La piste Network affiche chaque requête. Trouvez la ressource LCP et regardez quand elle démarre, pas seulement combien de temps elle prend. Une requête qui démarre à 2,5 secondes sur un LCP de 3 secondes est un problème de découverte. Aucune compression d'image ne la sauvera. Si vous aviez rendu cette image découvrable dès les premiers octets HTML, le téléchargement aurait commencé pendant que le navigateur analysait encore le head.

La piste Main affiche le travail du main thread. Les long tasks sont signalées par un triangle rouge dans le coin. Le schéma à chercher : la ressource LCP a fini de se télécharger, mais le marqueur LCP se trouve des centaines de millisecondes plus à droite. Cet écart est l'element render delay. Une de ces tâches signalées en est généralement responsable. Survolez la tâche pour voir quel script est en cause. D'après mon expérience, c'est bien plus souvent un gestionnaire de balises ou un script de consentement que votre propre code.

Corrigez ce que vous avez trouvé

La sous-partie la plus large de la décomposition décide où vous allez ensuite : TTFB, Resource Load Delay, Resource Load Duration ou Element Render Delay. Si l'élément LCP est une image, le guide Optimize the LCP Image couvre les quatre.

Une dernière note : une page pré-rendue affiche les quatre sous-parties à presque zéro, car le navigateur a fait tout le travail avant que l'utilisateur ne clique. Si votre problème de LCP survient sur les navigations au sein de votre site plutôt que sur les pages de destination, les speculation rules peuvent vous faire sauter tout le diagnostic.