LCP sur n’importe quel site : causes fréquentes et solutions concrètes

Un LCP à 3,8 secondes ne vous dit pas quoi corriger. Le même chiffre peut venir d’un serveur lent, d’une image découverte trop tard ou d’un rendu bloqué par le CSS, et chacune de ces causes appelle un correctif différent. La bonne méthode consiste à découper le LCP en quatre sous-parties, comparer leur poids à une répartition idéale connue, et travailler celle qui dépasse le plus sa part.

Le LCP en bref : seuils et éléments éligibles

Le Largest Contentful Paint mesure le temps d’affichage du plus grand élément de contenu visible dans la fenêtre, à partir du début du chargement. Les seuils, au 75e centile des visites : bon en dessous de 2,5 secondes, à améliorer entre 2,5 et 4 secondes, mauvais au-delà de 4 secondes.

Les éléments pris en compte : les images, les images dans un SVG, la première image ou le poster d’une vidéo, les éléments avec image de fond chargée en url(), et les blocs de texte. Sur la plupart des pages, c’est l’image de couverture ou le titre principal.

Les quatre sous-parties et leur répartition idéale

Google décompose le LCP en quatre durées successives, et publie la répartition d’une page bien optimisée. C’est cette répartition qui sert d’instrument de diagnostic.

Lecture : l’essentiel du temps doit partir dans le chargement du document HTML et dans celui de la ressource LCP. Les deux délais, avant chargement de la ressource et avant rendu, doivent rester marginaux. Dès qu’un des deux gonfle, c’est une opportunité d’amélioration claire, indépendamment du chiffre global.

Mesurer sa propre répartition

Deux façons d’obtenir le découpage réel.

Le panneau Performances de DevTools

Rechargez la page avec l’enregistrement actif. DevTools affiche l’événement LCP et permet de reconstituer les quatre phases à partir de la timeline : début de navigation, premier octet, début et fin de chargement de la ressource, rendu. Bridez le processeur pour approcher les conditions terrain.

La bibliothèque web-vitals avec attribution

La fonction onLCP() de la version avec attribution renvoie un objet qui expose directement timeToFirstByte, resourceLoadDelay, resourceLoadDuration et elementRenderDelay, plus element et url pour la ressource. C’est la mesure la plus fiable, et elle se déploie sans accès au code via un gestionnaire de balises.

Une fois la répartition en main, la règle est simple : la sous-partie la plus au-dessus de sa part idéale est celle sur laquelle travailler en premier. Une page à 3,4 secondes dont 65 % en délai de rendu n’a pas besoin d’une image plus légère, elle a besoin qu’on débloque son rendu.

Quand le site n’a pas de données terrain dans le rapport CrUX, faute de trafic suffisant, on raisonne par gabarit et on mesure une page de chaque type, comme pour l’INP dans notre article sur l’audit des Core Web Vitals sans données de champ.

L’élément LCP du labo n’est pas celui du terrain

Avant d’optimiser, vérifiez que vous parlez du bon élément. Lighthouse désigne un élément LCP dans ses conditions : un écran donné, pas de bannière de consentement, pas d’historique. Les vrais visiteurs ont des tailles d’écran différentes, une bannière cookies qui s’affiche, parfois une hydratation tardive : leur élément LCP peut être un autre visuel, un bloc de texte, ou l’overlay du consentement lui-même.

Optimiser l’image de couverture repérée par Lighthouse ne changera alors rien au score terrain. Le champ element de l’attribution web-vitals donne l’élément LCP réel des visiteurs. Faites ce contrôle par gabarit, une page de chaque type, avant de décider quoi optimiser.

TTFB trop long : causes et solutions

Si le Time to First Byte dépasse nettement 40 % du LCP, ou 800 millisecondes en absolu, c’est le serveur et la livraison du HTML qu’il faut regarder.

Causes fréquentes

Plusieurs redirections au chargement, souvent des liens raccourcis ou des redirections de campagne. Un visiteur loin du serveur d’origine sans CDN. Un HTML non mis en cache côté CDN, ou des paramètres d’URL uniques, de suivi par exemple, qui cassent le cache à chaque visite. Un serveur applicatif lent, base de données non optimisée ou rendu à chaque requête sans cache de page.

Solutions concrètes

Réduire les redirections au strict nécessaire sur le chargement initial. Servir le HTML depuis un CDN proche des utilisateurs. Poser des en-têtes Cache-Control qui permettent la mise en cache du document, et normaliser les paramètres d’URL pour ne pas invalider ce cache. Côté applicatif, activer un cache de page pleine.

Délai de chargement de la ressource

Cette sous-partie doit rester sous 10 %. Quand elle gonfle, c’est que le navigateur découvre la ressource LCP trop tard ou lui donne une priorité trop basse.

Causes fréquentes

L’image LCP absente du HTML initial, ajoutée ensuite par JavaScript. Une image de fond en CSS, non préchargée. Un attribut loading="lazy" posé sur l’image LCP, ce qui la retarde volontairement. Une priorité insuffisante accordée par le navigateur. Une ressource hébergée sur une autre origine, qui ajoute une négociation de connexion.

Solutions concrètes

Mettre le src ou le srcset de l’image LCP directement dans le HTML. Ajouter fetchpriority="high" sur cette image. Pour une image de fond CSS, un <link rel="preload" as="image" fetchpriority="high">. Ne jamais mettre loading="lazy" sur l’image LCP, et au contraire passer les images secondaires, carrousel par exemple, en fetchpriority="low" pour libérer de la bande passante. Héberger la ressource critique sur la même origine que le document.

Durée de chargement de la ressource

Environ 40 % du LCP dans l’idéal. Au-delà, la ressource LCP est simplement trop lourde à télécharger.

Causes et solutions

Servir la bonne taille d’image, avec des images réactives et des points de rupture adaptés, plutôt qu’une image démesurée redimensionnée par le navigateur. Utiliser des formats modernes, WebP ou AVIF, et compresser. Passer par un CDN d’images qui adapte taille et format à la volée. Poser un Cache-Control long sur les images : une ressource en cache ramène cette durée à quasi zéro pour les visiteurs récurrents. Pour une police qui porte le texte LCP, réduire le fichier et utiliser font-display avec une valeur autre que auto ou block.

Délai de rendu de l’élément

Sous 10 % dans l’idéal. C’est la sous-partie la plus souvent responsable d’un mauvais LCP sur les sites riches en scripts : la ressource est chargée, mais l’élément n’apparaît pas.

Causes fréquentes

Du CSS bloquant le rendu, feuille de style volumineuse chargée dans le <head>. Du JavaScript synchrone dans le <head>. Du JavaScript qui retarde l’ajout de l’élément au DOM, cas des pages rendues côté client. Un script de test A/B qui masque le contenu le temps de décider quelle version afficher. Des tâches longues qui monopolisent le thread principal, sur lequel se fait aussi le décodage image.

Solutions concrètes

Intégrer en ligne le CSS critique et différer le reste, supprimer les règles inutilisées, viser une feuille critique plus petite que la ressource LCP. Retirer le JavaScript synchrone du <head>, passer les scripts en async ou defer. Envisager un rendu côté serveur pour renvoyer un HTML où l’élément LCP est déjà présent et détectable. Limiter le délai des scripts de test A/B, ou réserver l’effet de masquage aux zones concernées. Découper les tâches longues et rendre la main au navigateur.

Le cas « n’importe quel site », sans accès au code

En audit externe, sans dépôt, vous ne poserez pas vous-même un fetchpriority ni un CSS critique en ligne. Ce que vous pouvez faire : mesurer la répartition via un gestionnaire de balises, identifier l’élément LCP terrain, et rendre un ticket qui nomme la sous-partie fautive et le correctif attendu. La méthode de diagnostic en boîte noire, transposable au LCP, est détaillée dans notre article sur le diagnostic des interactions lentes sans accès au code source.

Un préchargement d’image injecté par le gestionnaire de balises est théoriquement possible, mais il arrive trop tard dans le chargement pour être fiable : mieux vaut le ticket. Le seul levier vraiment actionnable sans l’équipe technique reste le retrait ou le report d’un script tiers chargé par le gestionnaire de balises, quand c’est lui qui bloque le rendu.

Vérifier que c’est corrigé

Re-mesurez la répartition, pas seulement le chiffre global : une correction réussie fait revenir la sous-partie fautive vers sa part idéale. Un LCP qui baisse de 3,6 à 3,1 secondes mais garde 60 % de délai de rendu n’est pas réglé, il est atténué.

Diagnostiquer la sous-partie, pas le chiffre

Un mauvais LCP se traite en quatre temps : découper la mesure en ses quatre sous-parties, les comparer à la répartition idéale de 40, 10, 40, 10, vérifier au passage que l’élément LCP du terrain est bien celui qu’on croit, puis appliquer les correctifs de la seule sous-partie qui dépasse. C’est ce qui évite d’alléger une image alors que le problème est un CSS bloquant, ou de refaire l’hébergement alors que le TTFB est déjà dans les clous. Le chiffre global dit qu’il y a un problème ; la répartition dit où.

Questions fréquentes