Identifier et corriger les problèmes de Largest Contentful Paint (LCP)

Ce guide fait partie du hub Largest Contentful Paint (LCP). Le LCP mesure la vitesse à laquelle l'élément visible le plus grand est rendu. Google souhaite qu'il soit inférieur à 2,5 secondes. Ce qui suit est le processus de diagnostic exact que j'utilise lors de mes missions de conseil sur la vitesse des pages.

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 ans, 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 de 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 issus des outils que je construis et utilise quotidiennement.

Améliorer le LCP est un processus d'élimination. Selon le 2025 Web Almanac, seulement 66 % des origines mobiles réussissent le LCP. Cela signifie qu'un tiers du web a un problème de chargement. Identifiez la phase la plus lente, corrigez-la, puis mesurez de nouveau.

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

Pour optimiser efficacement, vous devez adopter un flux de travail de diagnostic en deux étapes. Cela garantit que vous résolvez des problèmes auxquels vos utilisateurs sont réellement confrontés, et non que vous poursuivez simplement 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 des utilisateurs réels visitant votre site. Eles vous indiquent si vous avez un problème de LCP, quelles pages sont affectées et quels utilisateurs (mobiles ou desktop) en font l'expérience. 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é. Une fois que vos données de terrain ont confirmé un problème sur une page spécifique, vous pouvez utiliser les outils de laboratoire pour reproduire le problème de manière cohérente et disséquer le processus de chargement pour trouver la cause racine.

Commencez par les données de terrain pour que vos efforts d'optimisation ciblent des changements qui ont un impact réel sur les utilisateurs finaux.

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

Votre première tâche consiste à utiliser les données des 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 point de départ valable est le rapport Core Web Vitals dans la Google Search Console. Connectez-vous, accédez au rapport et examinez les graphiques mobile et desktop. Si Google signale des URLs avec "Problème de LCP : plus de 2,5 s", vous avez la confirmation par le Chrome User Experience Report (CrUX) qu'un pourcentage de vos utilisateurs a une mauvaise expérience.

La Search Console confirme le problème, maar elle se met à jour lentement et regroupe les URLs. Pour obtenir des détails au niveau de la page en temps réel, vous avez besoin d'un outil de RUM.

Real User Monitoring (RUM) : détails au niveau de la page

Vous pouvez construire votre propre configuration de RUM à l'aide de la bibliothèque web-vitals pour envoyer des données à votre backend d'analyse, mais cela représente un effort d'ingénierie significatif.

J'ai construit CoreDash spécifiquement pour cela. Vous ajoutez une seule balise script et il commence à collecter les données LCP de chaque visiteur réel, détaillées par page, appareil et élément.

Un bon outil de RUM vous permet de voir :

• Votre score LCP précis pour n'importe quelle URL spécifique.
• Une répartition de chaque élément LCP (par exemple, une image, un titre) et ceux qui sont le plus fréquemment associés à un LCP lent.
• Le timing exact pour chacune des quatre phases du LCP pour chaque vue de page, identifiant ainsi le gargalo.

Il est important de regarder au-delà de l'élément LCP lui-même. Dans une étude de cas bien documentée, Vodafone a amélioré son LCP de 31 %, ce qui a directement contribué à une augmentation de 8 % des ventes. Leur optimisation s'est concentrée sur l'identification et la résolution du gargalo spécifique du LCP sur les pages de destination clés en utilisant une combinaison d'analyse de données de terrain et de correctifs ciblés. L'optimisation du LCP ne concerne pas seulement l'image. Vous devez comprendre l'ensemble du pipeline de chargement : réponse du serveur, découverte des ressources, téléchargement et affichage (paint).

Par exemple, dans CoreDash, vous pouvez accéder à la page LCP et consulter un tableau de données qui affiche vos éléments LCP les plus lents. En cliquant sur un élément spécifique (comme une classe CSS particulière pour une image hero), 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.

L'objectif : utiliser les données de terrain pour trouver votre page la plus lente et son élément LCP le plus courant. C'est votre cible.

Mesurer le LCP avec l'API Performance Observer

L'API Performance Observer vous donne un accès direct aux entrées LCP en JavaScript. C'est la même API que celle utilisée par les outils de RUM sous le capot pour collecter les données de terrain. L'extrait suivant enregistre chaque candidat LCP identifié par le navigateur, y compris l'élément, sa taille et le temps de rendu.

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('Élément LCP :', lastEntry.element);
  console.log('Temps LCP :', lastEntry.renderTime || lastEntry.loadTime);
  console.log('Taille LCP :', lastEntry.size);
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });

Ceci est utile pour une validation rapide pendant le développement, mais pour une mesure en production, vous devriez utiliser la bibliothèque web-vitals, qui gère les cas particuliers comme les changements de visibilité des onglets et les restaurations de cache back/forward.

Étape 2 : Diagnostiquer le gargalo avec les outils de laboratoire

Vous savez quelle page corriger. Maintenant, découvrez pourquoi elle est lente. Effectuez un test avec PageSpeed Insights ou le panneau Lighthouse dans les Chrome DevTools.

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 de RUM devrait afficher une décomposition similaire basée sur vos données de terrain.

Votre objectif est de trouver la phase la plus longue dans cette décomposition. C'est votre gargalo principal, et c'est là que vous devez concentrer vos efforts d'optimisation en priorité.

Étape 3 : Comprendre les quatre phases du LCP

Chaque score LCP est la somme de quatre phases séquentielles. Chaque phase dispose d'un guide dédié sur ce site couvrant des techniques d'optimisation spécifiques.

• Time to First Byte (TTFB) : C'est la fondation incontournable. Une réponse lente du serveur est un ajout direct, milliseconde par milliseconde, à votre LCP. Avant d'optimiser une seule image, vous devez vous assurer que votre serveur répond rapidement. En savoir plus sur l'optimisation du TTFB.
• Resource Load Delay : C'est le "problème de découverte" et l'un des problèmes plus courants. Le navigateur ne peut pas télécharger une ressource dont il ignore l'existence. 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, perdant ainsi un temps précieux. Lisez le guide complet sur le Resource Load Delay.
• Resource Load Duration : C'est le temps de téléchargement du fichier de ressource LCP lui-même. Des images volumineuses et non compressées ou des conditions de réseau lentes peuvent faire de cette phase un gargalo. Lisez le guide complet sur la Resource Load Duration.
• Element Render Delay : C'est le problème du "trop occupé pour peindre". Le fichier image LCP peut être entièrement téléchargé, mais si le main thread du navigateur est bloqué par une exécution JavaScript lourde, il ne peut tout simplement pas passer à l'affichage de l'image à l'écran. Lisez le guide complet sur l'Element Render Delay.

Commencez toujours par vous assurer que votre TTFB est rapide et que votre ressource LCP est découvrable avant de passer aux optimisations de taille de fichier et de rendu.

Étape 4 : Exécuter le correctif

Une fois le gargalo identifié, appliquez le correctif. L'implémentation dépend de votre stack. Chaque phase ci-dessous couvre d'abord les principes universels, puis les spécificités de WordPress et des frameworks JS.

1. Optimiser le Time to First Byte (TTFB)

Si votre TTFB est lent (une bonne cible est inférieur à 800ms), il définit un plancher élevé pour votre LCP. Améliorer le TTFB améliorera toutes les autres métriques de chargement.

Solutions universelles pour le TTFB

• 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 ne la construise de toutes pièces à chaque visite.
• Utiliser un CDN : Un Content Delivery Network sert votre contenu à partir d'un serveur physiquement proche de votre utilisateur, ce qui réduit la latence du réseau. La mise en cache de vos pages HTML complètes en bordure (edge) du CDN est une stratégie puissante pour un TTFB global rapide. Pour des conseils détaillés sur la configuration du CDN, consultez notre guide sur comment configurer Cloudflare pour des performances optimales.
• Utiliser la compression Brotli ou Gzip : Assurez-vous que votre serveur compresse les ressources textuelles comme le HTML, le CSS et le JavaScript. Brotli offre une meilleure compression que Gzip et doit ê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, notamment un meilleur multiplexage. Il prend en charge le 0-RTT (Zero Round Trip Time Resumption), qui élimine le temps de configuration de la connexion pour les visiteurs récurrents, offrant ainsi un boost de TTFB instantané.
• Utiliser les 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 alors qu'il prépare encore le document HTML complet, permettant aux téléchargements de commencer encore plus tôt. Pour un guide d'implémentation complet, consultez notre article sur les 103 Early Hints.

Correctifs de 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 mutualisé bon marché peut être un gargalo. Envisagez un hébergeur WordPress infogéré optimisé pour la performance.
• Utiliser une extension de cache : Une extension de mise en cache de haute qualité (par exemple, WP Rocket, W3 Total Cache) est indispensable. Elle 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 l'exécution de fonctions serverless dès l'installation.
• 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 un nouveau rendu à chaque requête.
• Attention aux "Cold Starts" du 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 entraîner un TTFB élevé. Utilisez des stratégies de concurrence provisionnée ou de maintien en éveil (keep-alive) pour atténuer ce phénomène.

2. Réduire le Resource Load Delay

C'est fréquemment le plus gros gargalo. Cela signifie que le navigateur était prêt à travailler, mais qu'il n'a pas pu trouver immédiatement votre image principale ou votre fichier de police. Ce délai est généralement causé par l'un des deux problèmes suivants : la ressource est découverte tardivement, ou elle se voit attribuer une faible priorité de téléchargement. Pour le guide complet sur ce sujet, lisez notre guide dédié sur le Resource Load Delay.

Solutions universelles pour le Load Delay

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 envoyé par le serveur. Les navigateurs utilisent un "preload scanner" à haute vitesse pour anticiper dans le HTML brut les ressources comme les images et les scripts à télécharger. Si votre image LCP est chargée via une background-image CSS ou injectée avec JavaScript, elle est invisible pour ce scanner, ce qui entraîne un délai majeur. La solution la plus robuste consiste toujours à utiliser une balise <img> standard avec un attribut src dans votre HTML rendu côté 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 de fond CSS), la meilleure solution suivante consiste à utiliser <link rel="preload">. Cette balise agit comme une instruction explicite dans le <head> de votre HTML, indiquant au navigateur de commencer le téléchargement d'une ressource critique bien plus tôt qu'il ne l'aurait trouvée naturellement. Pour les détails d'implémentation et des exemples, consultez notre guide sur comment précharger l'image LCP.
• Assurer une priorité élevée avec fetchpriority : Même lorsqu'une ressource est découvrable, le navigateur peut ne pas lui accorder la priorité de téléchargement la plus élevée. Ajouter 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.

Correctifs de Load Delay spécifiques à la plateforme

Sur WordPress :

• Éviter les images de fond des constructeurs de pages : De nombreux constructeurs de pages facilitent la définition d'une image hero en tant que background-image CSS sur un div. Cela la rend invisible pour le preload scanner du navigateur. Si possible, utilisez plutôt un bloc <img> standard. Sinon, vous pourriez avoir besoin d'une extension ou d'un code personnalisé pour précharger cette image spécifique.
• Désactiver le lazy-loading pour l'image LCP : De nombreuses extensions d'optimisation vont automatiquement activer le lazy-load sur toutes les images. Vous devez trouver le réglage dans votre extension pour exclure l'image LCP (et souvent les premières images de la page) du lazy-loading. C'est une erreur si fréquente que nous avons un article dédié sur la correction des images LCP chargées en différé.

Sur un framework JS :

• Utiliser le Server-Side Rendering (SSR) : C'est souvent le correctif ayant le plus d'impact. 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 <img>, afin que le navigateur puisse la découvrir immédiatement.
• Utiliser les composants d'image spécifiques au framework : Les frameworks comme Next.js proposent un composant d'image avec une propriété priority. L'utilisation de cette propriété applique automatiquement fetchpriority="high" et d'autres optimisations à votre image LCP.

3. Diminuer la Resource Load Duration

S'assurer que votre ressource LCP est aussi petite que possible reste une partie essentielle du processus. Cette phase concerne le temps nécessaire pour télécharger le fichier de ressource LCP sur le réseau. Pour un guide complet sur les techniques d'optimisation d'image, consultez notre article sur l'optimisation de l'image LCP, et pour en savoir plus spécifiquement sur la Resource Load Duration.

Solutions universelles pour le Load Time

• Réduire la taille du fichier avec des formats modernes et des images responsives : Le moyen le plus direct de raccourcir le temps de téléchargement est de réduire la taille du fichier. Pour les images, cela signifie utiliser des formats modernes et hautement efficaces comme AVIF ou WebP. Vous devez également servir des images responsives à l'aide de l'élément <picture> ou des attributs srcset et sizes. Cela garantit qu'un utilisateur sur un appareil mobile reçoit une image de taille appropriée pour son petit écran, au lieu d'être forcé de télécharger une image énorme au format desktop. 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 textuels, assurez-vous que vos polices sont au format WOFF2 efficace et qu'elles sont sous-ensemblees (subsetted) pour supprimer les caractères inutilisés.
• Réduire la contention du réseau : La ressource LCP doit rivaliser 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 (below-the-fold), libère de la bande passante pour que le navigateur puisse se concentrer sur le téléchargement plus rapide de la ressource LCP.
• Héberger les ressources critiques sur votre domaine principal : Évitez de charger votre ressource LCP depuis un domaine différent si possible. La configuration d'une nouvelle connexion vers un autre serveur ajoute des résolutions DNS et des handshakes chronophages.

Correctifs de Load Time spécifiques à la plateforme

Sur WordPress :

• Utiliser une extension d'optimisation d'image : Des outils comme ShortPixel ou Smush peuvent compresser automatiquement les images lors du téléversement, les convertir en formats modernes comme WebP/AVIF et générer des tailles srcset responsives.
• Redimensionner manuellement les images : Avant de les téléverser, redimensionnez vos images pour qu'elles ne soient pas plus grandes que nécessaire. Ne téléversez pas une image de 4000px de large pour un espace qui ne fait que 1200px 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 l'Image & Video Manager d'Akamai peuvent automatiser tout le processus d'optimisation. Vous téléversez une seule image de haute qualité, et ils livrent une version parfaitement dimensionnée, compressée et formatée à chaque utilisateur via un CDN rapide.
• Exploiter les outils de build : Lorsque vous importez une image dans un composant d'un framework moderne, l'outil de build (comme Webpack ou Vite) peut automatiquement générer un hash et optimiser le fichier dans le cadre du processus de build.

4. Raccourcir l'Element Render Delay

Le téléchargement de la ressource est terminé, maar elle n'est pas encore à l'écran. Cela signifie que le main thread du navigateur est occupé par d'autres tâches et ne peut pas afficher l'élément. C'est un autre gargalo très courant et significatif. Pour le guide complet, lisez notre guide sur l'Element Render Delay.

Solutions universelles pour le Render Delay

• 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é à l'aide des attributs defer ou async.
• Utiliser le CSS critique : Une feuille de style volumineuse qui bloque le rendu peut le retarder. La technique du CSS critique consiste à extraire le CSS minimum nécessaire pour styliser le contenu au-dessus de la ligne de flottaison (above-the-fold), à l'insérer en ligne (inline) dans le <head> et à charger le reste des styles de manière asynchrone.
• Découper les tâches longues : Un script à exécution longue peut bloquer le main thread pendant une période prolongée, empêchant le rendu. C'est également une cause majeure d'une mauvaise Interaction to Next Paint (INP). Découpez votre code en morceaux plus petits et asynchrones qui redonnent (yield) le contrôle au main thread.

Correctifs de Render Delay spécifiques à la plateforme

Sur WordPress :

• Auditer vos extensions : Trop d'extensions, en particulier les plus lourdes comme les diaporamas ou les constructeurs de pages complexes, peuvent ajouter des quantités importantes de CSS et de JS qui bloquent le main thread. Désactivez les extensions une par une pour identifier les gourmandes en performance.
• Utiliser un thème léger : Un thème surchargé de 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 de ressources d'extensions : Des outils comme Asset CleanUp ou Perfmatters vous permettent de désactiver de manière conditionnelle le CSS et le JS de certaines extensions sur les pages où ils ne sont pas nécessaires.

Sur un framework JS :

• Le fractionnement du code (Code Splitting) est la 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.
• Charger les composants en différé (Lazy Load) : 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 fenêtres modales). Cela permet de les exclure du bundle initial.

Avancé : optimiser le LCP pour les navigations suivantes

Corriger le LCP initial est important, maar vous pouvez rendre la navigation sur votre site instantanée en optimisant les chargements de pages suivants.

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

Le bfcache est une optimisation du navigateur qui stocke un instantané complet d'une page en mémoire lorsque l'utilisateur s'en éloigne. S'il clique sur le bouton retour, la page peut être restaurée instantanément, ce qui entraîne un LCP proche de zéro. De nombreuses pages ne sont pas éligibles à ce cache à cause d'éléments comme les écouteurs d'événements unload. Utilisez l'audit Lighthouse "bfcache" pour tester vos pages et supprimer toute fonctionnalité bloquante.

Utiliser l'API Speculation Rules pour le prérendu

L'API Speculation Rules vous permet d'indiquer de manière déclarative au navigateur les pages vers lesquelles 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, ce qui conduit à un LCP proche de zéro. 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 les liens sur la page actuelle qui mènent à des pages de produits et de commencer à les pré-rendre lorsqu'un utilisateur survole le lien.

Traitez les quatre phases dans l'ordre. Corrigez d'abord le plus gros gargalo, mesurez de nouveau, et recommencez.

Prochaines étapes : chaque phase du LCP en détail

Chaque phase du LCP a son propre guide :

• Optimiser l'image LCP : Un guide complet sur la sélection du format d'image, les images responsives, le preloading et les erreurs courantes d'optimisation d'image.
• Resource Load Delay : Comment s'assurer que le navigateur découvre votre ressource LCP le plus tôt possible à l'aide du preload, de fetchpriority et d'une structure HTML appropriée.
• Resource Load Duration : Comment réduire le temps de téléchargement de votre ressource LCP grâce à la compression de fichiers, aux formats modernes, à la configuration du CDN et à l'optimisation du réseau.
• Element Render Delay : Comment libérer le main thread du navigateur pour qu'il puisse afficher l'élément LCP immédiatement après le téléchargement, couvrant le CSS critique, le report du JavaScript et content-visibility.