Corriger et identifier les problèmes de Largest Contentful Paint (LCP)

Guide d'un consultant pour diagnostiquer et corriger le LCP

Je m'appelle Arjen Karel et je suis consultant en vitesse de page. Au fil des années, j'ai audité des centaines de sites web, et l'un des défis les plus persistants est le Largest Contentful Paint (LCP). Dans ce guide, je partagerai la méthodologie exacte que j'utilise pour diagnostiquer et résoudre les problèmes de LCP. Vous verrez des mentions de CoreDash, un outil RUM que j'ai créé pour obtenir les données précises nécessaires à ce processus. Les principes ici sont universels, mais je crois qu'il est important de montrer des exemples réels tirés des outils que je construis et utilise quotidiennement.

Améliorer le LCP est un processus systématique d'élimination. En suivant une méthodologie claire, vous pouvez diagnostiquer efficacement les goulots d'étranglement dans le processus de chargement de votre page et appliquer des correctifs ciblés pour améliorer la performance de votre site et l'expérience utilisateur.

La méthodologie de diagnostic : Données de terrain d'abord, données de laboratoire ensuite

Pour optimiser efficacement, vous devez adopter un flux de travail de diagnostic en deux étapes. Cela garantit que vous résolvez les problèmes auxquels vos utilisateurs sont réellement confrontés, et pas seulement que vous poursuivez des scores dans un environnement de laboratoire.

1. Les données de terrain (RUM & CrUX) vous montrent CE QUI se passe. Les données de terrain sont collectées auprès d'utilisateurs réels visitant votre site [1]. Elles vous disent si vous avez un problème de LCP, quelles pages sont affectées, et quels utilisateurs (mobiles ou bureau) le rencontrent. Vous devez toujours commencer par là pour confirmer qu'un problème réel existe.
2. Les données de laboratoire (Lighthouse, DevTools) vous aident à diagnostiquer POURQUOI cela se produit. Les données de laboratoire sont collectées dans un environnement contrôlé et simulé [2]. Une fois que vos données de terrain ont confirmé un problème sur une page spécifique, vous pouvez utiliser des outils de laboratoire pour reproduire systématiquement le problème et disséquer le processus de chargement pour trouver la cause racine.

Commencer par les données de terrain garantit que vos efforts d'optimisation se concentrent sur les changements qui auront un impact mesurable sur vos utilisateurs réels.

Étape 1 : Identifier les problèmes de LCP avec les données de terrain

Votre première tâche est d'utiliser des données d'utilisateurs réels pour confirmer quelles pages, le cas échéant, ont un mauvais LCP.

Un point de départ accessible : Google Search Console

Un endroit valable pour commencer est le rapport Core Web Vitals dans la Google Search Console. Connectez-vous, naviguez vers le rapport et examinez les graphiques mobiles et bureau. Si Google signale des URL avec « Problème LCP : plus de 2,5 s », vous avez la confirmation du Chrome User Experience (CrUX) Report qu'un pourcentage de vos utilisateurs a une mauvaise expérience.

Bien que la Search Console soit inestimable pour confirmer un problème, elle est lente à se mettre à jour et regroupe les données par modèles d'URL. Pour des informations plus immédiates et granulaires, un outil RUM dédié est nécessaire.

Un regard plus approfondi : Real User Monitoring (RUM)

Pour obtenir la vérité terrain, vous pouvez suivre le LCP pour chaque utilisateur sur chaque chargement de page en utilisant une solution de Real User Monitoring (RUM). Bien que vous puissiez créer la vôtre en tirant parti de la bibliothèque [url=https://github.com/GoogleChrome/web-vitals]web-vitals[/url] pour envoyer des données à votre backend d'analyse, cela peut représenter un effort d'ingénierie important.

Alternativement, des outils RUM dédiés sont conçus à cet effet. Des outils comme CoreDash sont construits pour fournir ces données prêtes à l'emploi. La configuration implique généralement l'ajout d'un petit extrait JavaScript dans l'en-tête de votre site. Une fois installé, il commence à collecter des données de performance auprès de chaque visiteur réel.

Un bon outil RUM vous aide à aller au-delà des groupes d'URL pour comprendre :

• Votre score LCP précis pour toute URL spécifique.
• Une ventilation de chaque élément LCP (par exemple, une image, un titre) et lesquels sont le plus souvent associés à un LCP lent.
• Le timing exact pour chacune des quatre phases du LCP pour chaque page vue, identifiant le goulot d'étranglement.

Lors d'un audit récent pour un client e-commerce, nous avons vu des valeurs LCP élevées sur les pages produits malgré une image héro entièrement optimisée. Nos données RUM ont révélé que le retard n'était pas l'image elle-même, mais un script de test A/B côté client qui changeait dynamiquement le titre du produit, qui était l'élément LCP. Ce script bloquait le rendu assez longtemps pour pousser le LCP dans la catégorie « pauvre ». La mise en pause du test a immédiatement résolu le problème, prouvant que l'optimisation du LCP nécessite de regarder au-delà du simple élément LCP lui-même.

Par exemple, dans CoreDash, vous pouvez naviguer vers la page LCP et voir un tableau de données qui montre vos éléments LCP les plus lents. En cliquant sur un élément spécifique (comme une classe CSS particulière pour une image héro), vous pouvez filtrer toutes les métriques pour voir les données de performance uniquement pour les pages où cet élément était le LCP.

Que vous utilisiez une solution personnalisée ou un outil comme CoreDash, l'objectif est le même : utiliser les données de terrain pour trouver votre page la plus lente et identifier son élément LCP le plus courant. Une fois que vous avez cette cible, vous êtes prêt à diagnostiquer.

Étape 2 : Diagnostiquer le goulot d'étranglement avec les outils de laboratoire

Maintenant que vous savez quelle page corriger, il est temps de comprendre pourquoi elle est lente. C'est là qu'un outil de laboratoire comme PageSpeed Insights ou le panneau Lighthouse dans Chrome DevTools devient essentiel [3].

Lancez un test sur votre URL cible. Dans le rapport, faites défiler jusqu'à la section « Diagnostics » et trouvez l'audit « Élément Largest Contentful Paint ». Ce graphique en cascade décompose votre temps LCP en ses quatre sous-parties. Votre outil RUM devrait montrer une ventilation similaire basée sur vos données de terrain.

Votre objectif est de trouver la phase la plus longue dans cette ventilation. C'est votre principal goulot d'étranglement, et c'est là que vous devriez concentrer vos efforts d'optimisation en premier.

Étape 3 : Comprendre le véritable goulot d'étranglement

Dans la plupart des scénarios réels, les problèmes de LCP les plus significatifs et persistants proviennent de l'une des trois autres phases.

• Time to First Byte (TTFB) : C'est la fondation incontournable. Une réponse serveur lente est une addition directe, milliseconde pour milliseconde, à votre LCP. Avant d'optimiser une seule image, vous devez vous assurer que votre serveur répond rapidement.
• Resource Load Delay : C'est le « problème de découverte » et l'un des problèmes les plus courants. Le navigateur ne peut pas télécharger une ressource dont il n'a pas connaissance. Si votre image LCP est cachée dans un fichier CSS ou JavaScript, ou même si elle est dans le HTML mais que d'autres ressources sont demandées en premier, le navigateur la trouve trop tard, gaspillant un temps précieux.
• Element Render Delay : C'est le problème « trop occupé pour peindre ». Le fichier image LCP peut être entièrement téléchargé, mais si le thread principal du navigateur est bloqué par une exécution lourde de JavaScript, il ne peut tout simplement pas peindre l'image à l'écran.

Le guide suivant est structuré pour aborder ces phases dans un ordre logique. Commencez toujours par vous assurer que votre TTFB est rapide et que votre ressource LCP est découvrable avant de passer à la taille du fichier et aux optimisations de rendu.

Étape 4 : Exécuter le correctif

Une fois le goulot d'étranglement identifié, vous pouvez appliquer des optimisations ciblées. La façon dont vous mettez en œuvre ces correctifs dépendra fortement de l'architecture de votre site. Nous couvrirons d'abord les principes universels pour chaque phase, puis fournirons des conseils spécifiques pour WordPress et les frameworks JavaScript modernes.

1. Optimiser le Time to First Byte (TTFB)

Si votre TTFB est lent (un bon objectif est sous 800 ms [4]), cela fixe un plancher élevé pour votre LCP. Améliorer le TTFB améliorera toutes les autres métriques de chargement. C'est le temps qu'il faut au navigateur pour recevoir le premier octet de HTML de votre serveur.

Solutions TTFB universelles

• Activer la mise en cache : C'est l'un des moyens les plus efficaces d'améliorer le TTFB. La mise en cache génère et stocke une copie de la page afin qu'elle puisse être servie instantanément sans attendre que le serveur la construise à partir de zéro à chaque visite.
• Utiliser un CDN : Un Content Delivery Network sert votre contenu depuis un serveur physiquement proche de votre utilisateur, ce qui réduit la latence réseau [5]. Mettre en cache vos pages HTML complètes à la périphérie du CDN est une stratégie puissante pour un TTFB rapide et mondial.
• Utiliser la compression Brotli ou Gzip : Assurez-vous que votre serveur compresse les actifs textuels comme le HTML, le CSS et le JavaScript. Brotli offre une meilleure compression que Gzip et devrait être privilégié.
• Utiliser HTTP/3 avec 0-RTT : Assurez-vous que votre serveur est configuré pour utiliser HTTP/3. Il offre des avantages de performance significatifs, y compris un meilleur multiplexage. De manière cruciale, il prend en charge 0-RTT (Zero Round Trip Time Resumption), qui élimine le temps d'établissement de la connexion pour les visiteurs réguliers, fournissant un boost TTFB instantané [6].
• Utiliser 103 Early Hints : Pour un boost avancé, utilisez le code d'état 103 Early Hints. Cela permet à votre serveur ou CDN d'envoyer des indices sur les fichiers CSS et JS critiques au navigateur pendant qu'il prépare encore le document HTML complet, permettant aux téléchargements de commencer encore plus tôt [7]. C'est une fonctionnalité au niveau du serveur puissante qui peut profiter à n'importe quelle plateforme.

Correctifs TTFB spécifiques à la plateforme

Sur WordPress :

• Investir dans un hébergement de qualité : Sur WordPress, un TTFB lent est souvent lié à l'environnement d'hébergement. Un hébergement partagé bon marché peut être un goulot d'étranglement. Envisagez un hôte WordPress géré qui est optimisé pour la performance.
• Utiliser un plugin de mise en cache : Un plugin de mise en cache de haute qualité (par exemple, WP Rocket, W3 Total Cache) est non négociable. Il gère la génération de fichiers HTML statiques pour vous, ce qui est le cœur d'une mise en cache efficace sur cette plateforme.

Sur un framework JS :

• Choisir la bonne plateforme d'hébergement : Pour les applications Node.js, des plateformes comme Vercel ou Netlify sont hautement optimisées pour les frameworks SSR/SSG et offrent une mise en cache intelligente et une exécution de fonctions serverless prêtes à l'emploi.
• Implémenter la mise en cache SSR : Si vous utilisez le Server-Side Rendering, mettez en cache les pages rendues sur le serveur (par exemple, en utilisant Redis ou un cache en mémoire) pour éviter de refaire le rendu à chaque requête.
• Attention aux démarrages à froid Serverless : Si vous utilisez des fonctions serverless pour le rendu, sachez qu'un « démarrage à froid » (la première requête après une période d'inactivité) peut avoir un TTFB élevé. Utilisez la concurrence provisionnée ou des stratégies de keep-alive pour atténuer cela.

2. Réduire le Resource Load Delay

C'est souvent le plus grand goulot d'étranglement. Cela signifie que le navigateur était prêt à travailler, mais il n'a pas pu trouver votre image principale ou votre fichier de police tout de suite. Ce retard est généralement causé par l'un de deux problèmes : la ressource est découverte tardivement, ou elle se voit attribuer une priorité de téléchargement faible.

Solutions Load Delay universelles

La solution universelle au Resource Load Delay est de s'assurer que votre ressource LCP est à la fois découvrable dans le balisage HTML initial et qu'elle reçoit une priorité élevée de la part du navigateur. Voici comment y parvenir :

• Rendre la ressource LCP découvrable : L'étape la plus importante est de s'assurer que votre élément LCP est présent dans le HTML que le serveur envoie. Les navigateurs utilisent un « scanner de préchargement » à grande vitesse pour regarder en avance dans le HTML brut afin de télécharger des ressources comme des images et des scripts. Si votre image LCP est chargée via une `background-image` CSS ou injectée avec JavaScript, elle est invisible pour ce scanner, causant un retard majeur. La solution la plus robuste est toujours d'utiliser une balise <img> standard avec un attribut `src` dans votre HTML rendu par le serveur.
• Contrôler l'ordre de chargement avec preload : Si vous ne pouvez pas rendre la ressource LCP directement découvrable (un problème courant avec les polices ou les images d'arrière-plan CSS), la meilleure solution suivante est d'utiliser <link rel="preload">. Cette balise agit comme une instruction explicite dans votre <head>, indiquant au navigateur de commencer à télécharger une ressource critique beaucoup plus tôt qu'il ne l'aurait trouvée naturellement. C'est essentiel pour changer l'ordre de chargement absolu, garantissant que votre image LCP ou police est mise en file d'attente avant des ressources moins critiques comme le JavaScript asynchrone.
• Assurer une haute priorité avec fetchpriority : Même lorsqu'une ressource est découvrable, le navigateur peut ne pas lui donner la priorité de téléchargement la plus élevée. L'ajout de fetchpriority="high" à votre balise <img> ou votre balise <link rel="preload"> est un indice puissant pour le navigateur que cette ressource spécifique est la plus importante pour l'expérience utilisateur, l'aidant à gagner la course à la bande passante contre d'autres ressources [8].

Correctifs Load Delay spécifiques à la plateforme

Sur WordPress :

• Éviter les images d'arrière-plan des constructeurs de pages : De nombreux constructeurs de pages facilitent la définition d'une image héro comme `background-image` CSS sur une `div`. Cela la rend invisible au scanner de préchargement du navigateur. Si possible, utilisez un bloc `` standard à la place. Sinon, vous pourriez avoir besoin d'un plugin ou d'un code personnalisé pour `preload` cette image spécifique.
• Désactiver le Lazy-Loading pour l'image LCP : De nombreux plugins d'optimisation chargeront automatiquement toutes les images en différé (lazy-load). Vous devez trouver le paramètre dans votre plugin pour exclure l'image LCP (et souvent les premières images de la page) du lazy-loading.

Sur un framework JS :

• Utiliser le Server-Side Rendering (SSR) : C'est souvent le correctif le plus impactant. Une application React par défaut en Client-Side Rendering (CSR) envoie un HTML minimal, et l'élément LCP n'existe qu'après le téléchargement et l'exécution d'un gros bundle JS. Les frameworks SSR comme Next.js ou Remix livrent le HTML complet, y compris la balise ``, afin que le navigateur puisse la découvrir immédiatement.
• Utiliser des composants d'image spécifiques au framework : Les frameworks comme Next.js offrent un composant `` avec une prop `priority`. L'utilisation de ` ` applique automatiquement `fetchpriority="high"` et d'autres optimisations à votre image LCP.

3. Diminuer le Resource Load Time

S'assurer que votre ressource LCP est aussi petite que possible reste une partie cruciale du processus. Cette phase concerne le temps nécessaire pour télécharger le fichier de ressource LCP sur le réseau.

Solutions Load Time universelles

• Réduire la taille du fichier avec des formats modernes et des images réactives : Le moyen le plus direct de raccourcir le temps de téléchargement est de rendre le fichier plus petit. Pour les images, cela signifie utiliser des formats modernes et très efficaces comme AVIF ou WebP [9]. De manière critique, vous devez également servir des images réactives en utilisant l'élément <picture> ou les attributs srcset et sizes. Cela garantit qu'un utilisateur sur un appareil mobile reçoit une image dimensionnée de manière appropriée pour son petit écran, plutôt que d'être forcé de télécharger une image massive de taille bureau. Un écran mobile de 400 pixels de large n'a tout simplement pas besoin d'un fichier image de 2000 pixels de large. Pour les LCP basés sur du texte, assurez-vous que vos polices sont au format efficace WOFF2 et sont sous-ensemblées pour supprimer les caractères inutilisés.
• Réduire la contention réseau : La ressource LCP doit concourir pour la bande passante réseau limitée de l'utilisateur. Différer les ressources non critiques, comme les scripts d'analyse ou le CSS pour le contenu sous la ligne de flottaison, libère de la bande passante afin que le navigateur puisse se concentrer sur le téléchargement de la ressource LCP plus rapidement.
• Héberger les ressources critiques sur votre domaine principal : Évitez de charger votre ressource LCP à partir d'un domaine différent si possible. L'établissement d'une nouvelle connexion à un autre serveur ajoute des recherches DNS et des handshakes chronophages.

Correctifs Load Time spécifiques à la plateforme

Sur WordPress :

• Utiliser un plugin d'optimisation d'image : Des outils comme ShortPixel ou Smush peuvent compresser automatiquement les images lors du téléchargement, les convertir en formats modernes comme WebP/AVIF, et générer des tailles `srcset` réactives.
• Redimensionner manuellement les images : Avant de télécharger, redimensionnez vos images pour qu'elles ne soient pas plus grandes que nécessaire. Ne téléchargez pas une image de 4000 px de large pour un espace qui ne fait que 1200 px de large sur les plus grands écrans.

Sur un framework JS :

• Utiliser un CDN d'image : C'est une solution puissante. Des services comme Cloudinary, Imgix ou Image & Video Manager d'Akamai peuvent automatiser tout le processus d'optimisation. Vous téléchargez une image de haute qualité, et ils livrent une version parfaitement dimensionnée, compressée et formatée à chaque utilisateur via un CDN rapide.
• Tirer parti des outils de build : Lorsque vous `import`ez une image dans un composant dans un framework moderne, l'outil de build (comme Webpack ou Vite) peut automatiquement hacher et optimiser le fichier dans le cadre du processus de build.

4. Raccourcir l'Element Render Delay

La ressource a fini de se télécharger, mais elle n'est pas encore à l'écran. Cela signifie que le thread principal du navigateur est occupé par d'autres tâches et ne peut pas peindre l'élément. C'est un autre goulot d'étranglement très courant et significatif.

Solutions Render Delay universelles

• Différer ou supprimer le JavaScript inutilisé : Tout JS qui n'est pas essentiel pour le rendu de la partie initiale et visible de la page doit être différé en utilisant les attributs defer ou async.
• Utiliser le Critical CSS : Une grande feuille de style bloquant le rendu peut retarder le rendu. La technique du Critical CSS consiste à extraire le CSS minimum nécessaire pour styliser le contenu au-dessus de la ligne de flottaison, à l'insérer en ligne dans le <head>, et à charger le reste des styles de manière asynchrone [10].
• Diviser les tâches longues : Un script de longue durée peut bloquer le thread principal pendant une période prolongée, empêchant le rendu. C'est également une cause principale d'un mauvais Interaction to Next Paint (INP). Divisez votre code en morceaux plus petits et asynchrones qui rendent la main au thread principal (yield).

Correctifs Render Delay spécifiques à la plateforme

Sur WordPress :

• Auditer vos plugins : Trop de plugins, surtout les lourds comme les sliders ou les constructeurs de pages complexes, peuvent ajouter un CSS et un JS significatifs qui bloquent le thread principal. Désactivez les plugins un par un pour identifier les consommateurs de performance.
• Utiliser un thème léger : Un thème gonflé avec des dizaines de fonctionnalités que vous n'utilisez pas peut être une source majeure de code bloquant le rendu. Choisissez un thème axé sur la performance.
• Utiliser des gestionnaires d'actifs de plugin : Des outils comme Asset CleanUp ou Perfmatters vous permettent de désactiver conditionnellement le CSS et le JS de plugins spécifiques sur les pages où ils ne sont pas nécessaires.

Sur un framework JS :

• Le Code Splitting est clé : N'envoyez pas tout le JavaScript de votre application dans un seul bundle géant. Divisez votre code par route (pour que les utilisateurs ne téléchargent que le code de la page qu'ils visitent) et par composant.
• Lazy Load des composants : Utilisez `React.lazy` et `Suspense` pour charger en différé les composants qui ne sont pas immédiatement visibles (par exemple, les composants sous la ligne de flottaison ou dans les modales). Cela les garde hors du bundle initial.

Avancé : Optimiser le LCP pour les navigations ultérieures

Corriger le LCP initial est crucial, mais vous pouvez créer une expérience radicalement plus rapide pour les utilisateurs lorsqu'ils naviguent sur votre site en optimisant pour les chargements de page ultérieurs.

S'assurer que les pages sont éligibles pour le Back/Forward Cache (bfcache)

Le bfcache est une optimisation du navigateur qui stocke un instantané complet d'une page en mémoire lorsqu'un utilisateur navigue ailleurs. S'ils cliquent sur le bouton retour, la page peut être restaurée instantanément, résultant en un LCP proche de zéro. De nombreuses pages sont inéligibles pour ce cache en raison de choses comme les écouteurs d'événements `unload`. Utilisez l'audit « bfcache » de Lighthouse pour tester vos pages et supprimer toute fonctionnalité bloquante [11].

Utiliser la Speculation Rules API pour le prérendu

La Speculation Rules API est un nouvel outil puissant qui vous permet d'indiquer de manière déclarative au navigateur vers quelles pages un utilisateur est susceptible de naviguer ensuite. Le navigateur peut alors récupérer et pré-rendre ces pages en arrière-plan. Lorsque l'utilisateur clique sur un lien vers une page pré-rendue, la navigation est instantanée, menant à une expérience utilisateur phénoménale et un LCP proche de zéro [12]. Vous pouvez définir ces règles dans une balise <script type="speculationrules"> dans votre HTML.

<script type="speculationrules"> 
 { 
  "prerender": [{ 
   "source": "document", 
   "where": { 
    "href_matches": "/products/*" 
   }, 
   "eagerness": "moderate" 
  }] 
 } 
 </script>  

Cet exemple indique au navigateur de rechercher des liens sur la page actuelle qui mènent à des pages produits et de commencer à les pré-rendre lorsqu'un utilisateur survole le lien.

En travaillant méthodiquement à travers ces quatre phases et en considérant les optimisations de navigation avancées, vous pouvez identifier la cause exacte de vos problèmes de LCP et appliquer le correctif correct et à fort impact.

Références

1. [url=https://web.dev/articles/lab-and-field-data]web.dev : Données de laboratoire et de terrain[/url]
2. [url=https://developer.chrome.com/docs/devtools/performance/debug-web-vitals]Chrome for Developers : Déboguer les Web Vitals sur le terrain[/url]
3. [url=https://web.dev/articles/optimize-lcp]web.dev : Optimiser le Largest Contentful Paint[/url]
4. [url=https://web.dev/articles/optimize-ttfb]web.dev : Optimiser pour un bon TTFB[/url]
5. [url=https://www.cloudflare.com/learning/cdn/what-is-a-cdn/]Cloudflare : Qu'est-ce qu'un CDN ?[/url]
6. [url=https://web.dev/articles/http3]web.dev : HTTP/3[/url]
7. [url=https://web.dev/articles/103-early-hints]web.dev : Plus lent est plus rapide ? Envoyer une réponse HTTP 103 pour accélérer votre site[/url]
8. [url=https://web.dev/articles/lcp-fetchpriority]web.dev : Optimiser le LCP avec fetchpriority[/url]
9. [url=https://web.dev/articles/serve-images-in-modern-formats]web.dev : Utiliser des formats d'image modernes[/url]
10. [url=https://web.dev/articles/extract-critical-css]web.dev : Extraire le Critical CSS[/url]
11. [url=https://web.dev/articles/bfcache]web.dev : Back/forward cache[/url]
12. [url=https://web.dev/articles/speculation-rules]web.dev : Speculation Rules API[/url]