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

Ce guide fait partie du hub Largest Contentful Paint (LCP). LCP mesure la vitesse de rendu du plus grand élément visible. Google exige un temps inférieur à 2,5 secondes. Voici le processus de diagnostic exact que j'utilise lors de mes consultations sur la vitesse de page.

Le guide du consultant pour diagnostiquer et corriger LCP

Je m'appelle Arjen Karel, consultant en vitesse de page. J'ai audité des centaines de sites au fil des ans. Largest Contentful Paint (LCP) reste l'un des défis les plus tenaces. Dans ce guide, je partage la méthode exacte que j'utilise pour diagnostiquer et résoudre les problèmes LCP. Vous verrez des mentions de CoreDash. C'est un outil RUM que j'ai créé pour obtenir les données précises nécessaires à ce processus. Les principes présentés ici sont universels. Je tiens cependant à montrer des exemples réels issus des outils que je crée et utilise au quotidien.

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

La méthode de diagnostic : d'abord la field data, ensuite la lab data

Pour optimiser efficacement, vous devez adopter un workflow de diagnostic en deux étapes. Cela garantit que vous résolvez les problèmes que vos utilisateurs rencontrent réellement, au lieu de chasser des scores dans un environnement de laboratoire.

1. La field data (RUM et CrUX) vous montre CE QUI se passe. La field data est collectée auprès d'utilisateurs réels visitant votre site. Elle vous indique si vous avez un problème LCP, quelles pages sont affectées et quels utilisateurs (mobile ou desktop) le subissent. Vous devez toujours commencer par là pour confirmer l'existence d'un problème réel.
2. La lab data (Lighthouse, DevTools) vous aide à diagnostiquer POURQUOI cela se passe. La lab data est collectée dans un environnement contrôlé et simulé. Une fois que votre field data a confirmé un problème sur une page spécifique, vous pouvez utiliser des outils de laboratoire pour reproduire le problème systématiquement et décortiquer le processus de chargement afin d'en trouver la cause racine.

Commencez par la field data pour que vos efforts d'optimisation ciblent des changements qui impactent réellement les utilisateurs.

Étape 1 : Identifier les problèmes LCP avec la field data

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

Le rapport Core Web Vitals dans Google Search Console est un bon point de départ. Connectez-vous, accédez au rapport et analysez les graphiques mobile et desktop. Si Google signale des URL avec le message « problème LCP : supérieur à 2,5 s », le Chrome User Experience (CrUX) Report confirme qu'un pourcentage de vos utilisateurs subit une mauvaise expérience.

Search Console confirme le problème, mais se met à jour lentement et regroupe les URL. Pour obtenir des détails au niveau de la page en temps réel, il vous faut un outil RUM.

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

Vous pouvez créer votre propre configuration RUM à l'aide de la bibliothèque web-vitals pour envoyer les données à votre backend d'analyse. Cela représente cependant un effort d'ingénierie important.

J'ai construit CoreDash spécifiquement pour cela. Vous ajoutez une balise script et la collecte des données LCP commence pour chaque visiteur réel. Les données sont réparties par page, appareil et élément.

Un bon outil 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 lesquels sont le plus fréquemment associés à un LCP lent.
• Le timing exact pour chacune des quatre phases LCP pour chaque vue de page, afin de cibler le goulot d'étranglement.

Regarder au-delà de l'élément LCP lui-même est crucial. 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 goulot d'étranglement LCP spécifique sur les landing pages clés. Ils ont combiné l'analyse de la field data et des correctifs ciblés. L'optimisation LCP ne se limite pas à l'image. Vous devez comprendre l'intégralité du pipeline de chargement : réponse du serveur, découverte des ressources, téléchargement et affichage.

Dans CoreDash, par exemple, 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 hero image), vous pouvez filtrer toutes les métriques. Cela permet de voir les données de performance uniquement pour les pages où cet élément était le LCP.

L'objectif : utilisez la field data pour trouver votre page la plus lente et son élément LCP le plus courant. C'est votre cible.

Mesurer LCP avec la Performance Observer API

La Performance Observer API vous donne un accès direct aux entrées LCP en JavaScript. Il s'agit de la même API que les outils RUM utilisent en arrière-plan pour collecter la field data. Le snippet suivant logue chaque candidat LCP identifié par le navigateur, y compris l'élément, sa taille et son temps de rendu.

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

Cela est utile pour une validation rapide lors du développement. Toutefois, pour la mesure en production, vous devriez utiliser la bibliothèque web-vitals. Elle gère les cas particuliers tels que les changements de visibilité des onglets et les restaurations du back/forward cache.

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

Vous savez quelle page corriger. Trouvez maintenant pourquoi elle est lente. Lancez un test avec PageSpeed Insights ou le panneau Lighthouse dans Chrome DevTools.

Dans le rapport, descendez jusqu'à la section « Diagnostics » et trouvez l'audit « Largest Contentful Paint element ». Ce graphique en cascade décompose votre temps LCP en ses quatre sous-parties. Votre outil RUM devrait afficher une répartition similaire basée sur votre field data.

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

Guide étape par étape : vous préférez travailler dans DevTools ? L'article Diagnostiquer LCP avec le panneau Performance de Chrome DevTools montre comment enregistrer une trace ralentie et lire les mêmes quatre sous-parties depuis l'analyse de la décomposition LCP.

Étape 3 : Comprendre les quatre phases 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 la moindre image, vous devez vous assurer que votre serveur répond rapidement. Apprenez-en plus sur l'optimisation du TTFB.
• Resource Load Delay : C'est le « problème de découverte » et l'un des problèmes les plus fréquents. Le navigateur ne peut pas télécharger une ressource qu'il ne connaît pas. 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 découvre trop tard. Cela gaspille un temps précieux. Lisez le guide complet sur le Resource Load Delay.
• Resource Load Duration : C'est le temps de téléchargement pour la ressource LCP elle-même. Des images volumineuses non compressées ou des conditions réseau lentes peuvent faire de cette phase un goulot d'étranglement. Lisez le guide complet sur la Resource Load Duration.
• Element Render Delay : C'est le problème du « trop occupé pour afficher ». Le fichier d'image LCP peut être entièrement téléchargé. Cependant, si le main thread du navigateur est bloqué par une exécution lourde de JavaScript, il ne peut tout simplement pas procéder à 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 d'affichage.

Étape 4 : Exécuter la correction

Une fois le goulot d'étranglement 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 moins de 800 ms), cela fixe un plancher élevé pour votre LCP. Améliorer le TTFB améliorera toutes les autres métriques de chargement.

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 soit servie instantanément. Le serveur n'a plus besoin de la construire 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. Mettre en cache vos pages HTML complètes à la bordure du CDN est une stratégie puissante pour un TTFB rapide et global. Pour des conseils de configuration détaillés de CDN, consultez notre guide sur la façon de configurer Cloudflare pour des performances optimales.
• Utiliser la compression Brotli ou Gzip : Assurez-vous que votre serveur compresse les ressources basées sur du texte 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. Il prend en charge 0-RTT (Zero Round Trip Time Resumption), ce qui élimine le temps d'établissement de la connexion pour les visiteurs récurrents. Cela fournit un gain instantané de TTFB.
• Utiliser 103 Early Hints : Pour une amélioration avancée, utilisez le code d'état 103 Early Hints. Cela permet à votre serveur ou CDN d'envoyer au navigateur des indications sur les fichiers CSS et JS critiques. Il le fait pendant la préparation du document HTML complet, permettant aux téléchargements de démarrer encore plus tôt. Pour un guide d'implémentation complet, consultez notre article sur les 103 Early Hints.

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 mutualisé bon marché peut être un goulot d'étranglement. Envisagez un hébergement WordPress infogéré optimisé pour la performance.
• Utiliser un plugin de cache : Un plugin de mise en cache de haute qualité (par exemple, WP Rocket, W3 Total Cache) est non négociable. Il gère pour vous la génération de fichiers HTML statiques. C'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, les plateformes comme Vercel ou Netlify sont hautement optimisées pour les frameworks SSR/SSG. Elles offrent d'emblée une mise en cache intelligente et l'exécution de fonctions serverless.
• Implémenter la mise en cache SSR : Si vous utilisez le Server-Side Rendering, mettez en cache les pages générées sur le serveur (par exemple, avec Redis ou un cache en mémoire) pour éviter un nouveau rendu à chaque requête.
• Se méfier des cold starts serverless : Si vous utilisez des fonctions serverless pour le rendu, sachez qu'un « cold start » (la première requête après une période d'inactivité) peut avoir un TTFB élevé. Utilisez la provisioned concurrency ou des stratégies de keep-alive pour atténuer cela.

2. Réduire le Resource Load Delay

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

Solutions universelles pour le Load Delay

La solution universelle au Resource Load Delay consiste à s'assurer que votre ressource LCP est à la fois découvrable dans le balisage HTML initial et dotée d'une priorité élevée par le 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 » ultra-rapide pour anticiper le HTML brut et trouver des ressources à télécharger, comme les images et les scripts. Si votre image LCP est chargée via une background-image CSS ou injectée avec JavaScript, elle est invisible pour ce scanner. Cela provoque un retard 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 d'arrière-plan CSS), la meilleure alternative consiste à utiliser <link rel="preload">. Cette balise agit comme une instruction explicite dans votre <head> HTML. Elle indique 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 des détails d'implémentation et des exemples, consultez notre guide sur la façon de 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 maximale. Ajouter fetchpriority="high" à votre balise <img> ou à votre balise <link rel="preload"> est une indication forte pour le navigateur. Cela lui signale que cette ressource spécifique est la plus importante pour l'expérience utilisateur, l'aidant à remporter la course pour la bande passante face aux autres ressources.

Correctifs de Load Delay spécifiques à la plateforme

Sur WordPress :

• Éviter les images d'arrière-plan de page builder : De nombreux page builders facilitent la définition d'une hero image en tant que background-image CSS sur une 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'un plugin ou d'un code personnalisé pour précharger cette image spécifique.
• Désactiver le lazy loading pour l'image LCP : De nombreux plugins d'optimisation appliquent automatiquement le lazy loading à toutes les images. 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. C'est une erreur si courante que nous avons un article dédié à la correction des images LCP soumises au lazy loading.

Sur un framework JS :

• Utiliser le Server-Side Rendering (SSR) : C'est souvent le correctif le plus percutant. Une application React en Client-Side Rendering (CSR) par défaut envoie un HTML minimal. L'élément LCP n'existe qu'après le téléchargement et l'exécution d'un lourd bundle JS. Les frameworks SSR comme Next.js ou Remix délivrent le HTML complet, incluant la balise <img>. Le navigateur peut ainsi la découvrir immédiatement.
• Utiliser des composants d'image spécifiques au framework : Les frameworks comme Next.js proposent un composant d'image avec une prop priority. L'utilisation de cette prop 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 la 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 sur la Resource Load Duration en particulier.

Solutions universelles pour le temps de chargement

• 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 implique d'utiliser des formats modernes et hautement efficaces comme AVIF ou WebP. Vous devez également servir des images responsives 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 correctement dimensionnée pour son petit écran, au lieu de devoir télécharger une image massive conçue pour le 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 basés sur du texte, assurez-vous que vos polices sont au format WOFF2 efficace et fassent l'objet d'un subsetting pour supprimer les caractères inutilisés.
• Réduire la congestion réseau : La ressource LCP doit rivaliser pour la bande passante limitée de l'utilisateur. Le report des ressources non critiques, comme les scripts d'analyse ou le CSS pour le contenu en dessous de la ligne de flottaison, libère de la bande passante. Le navigateur peut ainsi se concentrer sur un 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. L'établissement d'une nouvelle connexion à un autre serveur ajoute des recherches DNS et des handshakes chronophages.

Correctifs de temps de chargement 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 de l'upload. Ils les convertissent dans des formats modernes comme WebP/AVIF et génèrent des tailles srcset responsives.
• Redimensionner manuellement les images : Avant l'upload, redimensionnez vos images pour qu'elles ne soient pas plus grandes que nécessaire. N'uploadez pas une image de 4000 px de large pour un espace qui ne fait que 1200 px de large sur les écrans les plus grands.

Sur un framework JS :

• Utiliser un CDN d'image : C'est une solution puissante. Des services comme Cloudinary, Imgix, ou Akamai Image & Video Manager peuvent automatiser l'intégralité du processus d'optimisation. Vous uploadez une image de haute qualité. Ils délivrent une version parfaitement dimensionnée, compressée et formatée à chaque utilisateur via un CDN rapide.
• Tirer parti des build tools : Lorsque vous importez une image dans un composant au sein d'un framework moderne, le build tool (comme Webpack ou Vite) peut automatiquement hasher et optimiser le fichier pendant le 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 main thread du navigateur est occupé par d'autres tâches et ne peut pas afficher l'élément. C'est un autre goulot d'étranglement très courant et significatif. Pour le guide complet, lisez notre article 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 au rendu de la partie initiale et visible de la page doit être différé à l'aide des attributs defer ou async.
• Utiliser le Critical CSS : Une feuille de style volumineuse en render blocking peut retarder le rendu. La technique du Critical CSS consiste à extraire le CSS minimal nécessaire pour styliser le contenu au-dessus de la ligne de flottaison. Vous l'intégrez en inline dans le <head> et chargez le reste des styles de façon asynchrone.
• Découper les long tasks : 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 principale d'un mauvais Interaction to Next Paint (INP). Découpez votre code en plus petits morceaux asynchrones qui effectuent un yield vers le main thread.

Correctifs de Render Delay spécifiques à la plateforme

Sur WordPress :

• Auditer vos plugins : Trop de plugins, particulièrement les plus lourds comme les sliders ou les page builders complexes, peuvent ajouter d'importants CSS et JS qui bloquent le main thread. Désactivez les plugins un par un pour identifier les gouffres de performance.
• Utiliser un thème léger : Un thème surchargé avec des dizaines de fonctionnalités que vous n'utilisez pas peut être une source majeure de code render blocking. Choisissez un thème axé sur la performance.
• Utiliser des gestionnaires d'assets 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. Découpez votre code par route (pour que les utilisateurs ne téléchargent que le code de la page qu'ils visitent) et par composant.
• Appliquer le lazy loading aux composants : Utilisez React.lazy et Suspense pour charger en lazy loading les composants qui ne sont pas immédiatement visibles (par exemple, les composants en dessous de la ligne de flottaison ou dans des modales). Cela les garde en dehors du bundle initial.

Avancé : Optimiser LCP pour les navigations ultérieures

Corriger le LCP initial est important. Vous pouvez cependant rendre la navigation sur votre site instantanée en optimisant les chargements de page ultérieurs.

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 lorsqu'un utilisateur la quitte. S'il clique sur le bouton retour, la page peut être restaurée instantanément, ce qui donne un LCP proche de zéro. De nombreuses pages sont inéligibles à ce cache en raison d'éléments tels que les écouteurs d'événements unload. Utilisez l'audit Lighthouse « bfcache » pour tester vos pages et supprimer toute fonctionnalité bloquante.

Utiliser la Speculation Rules API pour le Prerendering

La Speculation Rules API 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 à 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 demande au navigateur de rechercher les liens sur la page actuelle qui mènent aux pages produits et de commencer à les pré-rendre lorsqu'un utilisateur survole le lien.

Parcourez les quatre phases dans l'ordre. Corrigez le plus gros goulot d'étranglement en premier, mesurez à nouveau, répétez.

Prochaines étapes : chaque phase LCP en détail

Chaque phase LCP possède son propre guide :

• Optimiser l'image LCP : Un guide complet sur la sélection du format d'image, les images responsives, le préchargement 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 en utilisant preload, fetchpriority et 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 CDN et à l'optimisation 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. Couvre le critical CSS, le report JavaScript et le content-visibility.