Optimiser le LCP : leviers concrets pour accélérer l’affichage
Décomposez le LCP en sous-parties et appliquez les leviers concrets de Google pour afficher votre contenu principal en moins de 2,5 secondes.
Le Largest Contentful Paint (LCP) est l’une des trois métriques Core Web Vitals. Il mesure le temps écoulé entre le lancement du chargement de la page et l’affichage de la plus grande image ou du plus grand bloc de texte dans la fenêtre d’affichage. Autrement dit, il reflète la vitesse à laquelle le contenu principal devient visible. Google recommande d’afficher ce plus grand élément en 2,5 secondes ou moins pour au moins 75 % des visites.
Pour le SEO, le LCP est déterminant : il fait partie des signaux d’expérience de page et conditionne fortement la perception de rapidité. Avant d’optimiser, mieux vaut savoir comprendre et mesurer le LCP sur vos propres pages. Rares sont les corrections ponctuelles qui le transforment d’un coup. L’approche efficace consiste à examiner l’ensemble du processus de chargement et à optimiser chaque étape, plutôt que de chercher une astuce isolée.
Avant de plonger dans les leviers, je décompose toujours le LCP en ses sous-parties pour savoir où je perds vraiment du temps. C’est l’étape que la plupart des gens sautent, et c’est pour ça qu’ils optimisent au hasard. Faire découvrir tôt la ressource principale au navigateur, via la priorisation, est souvent le levier le plus rentable et le plus sous-exploité que je rencontre.
Décomposer le LCP en quatre sous-parties
Pour optimiser le LCP, il est utile de le décomposer en quatre sous-parties qui s’enchaînent sans chevauchement ni écart, et dont la somme forme le temps total. Sur une page bien optimisée, l’essentiel du temps doit être consacré au chargement du document HTML et de la ressource LCP, tandis que les deux phases de « délai » doivent être réduites au maximum. La première sous-partie étant le TTFB, il est souvent payant de commencer par optimiser le TTFB pour libérer du temps sur tout le reste.
| Sous-partie | Ce qu'elle mesure | Part visée |
|---|---|---|
TTFB |
Délai jusqu’au premier octet du document HTML |
Environ 40 % |
Délai de chargement de la ressource |
Temps entre le TTFB et le début du chargement de la ressource LCP |
Moins de 10 % |
Durée de chargement de la ressource |
Temps de chargement de la ressource LCP elle-même |
Environ 40 % |
Délai d’affichage de l’élément |
Temps entre la fin du chargement et le rendu de l’élément |
Moins de 10 % |
Causes fréquentes et leviers d'optimisation
Les recommandations de Google se présentent par ordre d’impact, en commençant par les leviers les plus efficaces. L’idée directrice : faire en sorte que la ressource LCP commence à se charger le plus tôt possible, puis qu’elle s’affiche immédiatement une fois chargée, sans blocage.
| Cause d'un LCP lent | Levier d'optimisation |
|---|---|
Ressource LCP découverte trop tard |
La rendre détectable dans le HTML initial, précharger avec fetchpriority élevé |
Image LCP en chargement différé |
Ne jamais utiliser loading=lazy sur l’élément LCP |
Feuilles de style ou scripts bloquant l’affichage |
Réduire, différer ou intégrer le CSS et le JavaScript critiques |
Élément ajouté tardivement par JavaScript |
Privilégier le rendu côté serveur (SSR) ou la génération statique |
Ressource volumineuse ou lointaine |
Compresser, utiliser des formats modernes (WebP, AVIF) et un CDN |
TTFB élevé |
Réduire les redirections et soigner la mise en cache |
Prioriser et faire découvrir la ressource LCP
Pour que la ressource LCP démarre tôt, le scanner de préchargement du navigateur doit pouvoir la repérer dans la réponse HTML initiale. Une image LCP référencée seulement depuis un fichier CSS ou JavaScript externe sera découverte trop tard. La solution consiste à la rendre visible dans le HTML et, si nécessaire, à la précharger avec une priorité de récupération élevée. Veillez aussi à éviter le chargement différé de l’élément LCP, qui retarderait inutilement son apparition.
<!-- Charger la feuille de style qui référence l'image LCP. -->
<link rel="stylesheet" href="/path/to/styles.css">
<!-- Précharger l'image LCP avec une priorité élevée. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">Appliquer loading=lazy à l’élément LCP introduit toujours un délai de chargement inutile et dégrade le LCP. Réservez le chargement différé aux images situées sous la ligne de flottaison, jamais à celle qui constitue le plus grand élément visible au démarrage.
À faire
- rendre la ressource LCP détectable dès le HTML
- la précharger avec fetchpriority élevé
- compresser et servir des formats modernes
- réduire le CSS et le JavaScript bloquants
- optimiser le TTFB
À éviter
- charger l’image LCP en différé
- insérer des scripts synchrones lourds dans le head
- héberger la ressource critique sur une origine tierce sans préconnexion
- optimiser une seule sous-partie en ignorant les autres
Points clés à retenir
- Visez un LCP de 2,5 secondes ou moins au 75e centile
- Faites démarrer la ressource LCP le plus tôt possible
- Supprimez les blocages d'affichage côté CSS et JavaScript
- Réduisez le poids de la ressource et rapprochez-la via un CDN
- Optimisez les quatre sous-parties, pas une seule
Le LCP s’optimise en travaillant le chargement de la ressource principale de bout en bout.
Quiz : testez vos connaissances
Quiz : testez vos connaissances
-
Pourquoi une image LCP référencée uniquement depuis un fichier CSS ou JavaScript externe pose-t-elle problème ?
- Le navigateur refuse de charger les images définies hors du HTML
- Elle est toujours chargée deux fois, ce qui ralentit la page
- Le scanner de préchargement ne la repère pas dans le HTML initial, elle est découverte trop tard
Le scanner de préchargement repère les ressources dans la réponse HTML initiale. Une image LCP visible seulement via un CSS ou JS externe est découverte trop tard, ce qui retarde le LCP.
-
Que se passe-t-il si l'on applique loading=lazy à l'élément LCP ?
- Cela n'a aucun effet sur le LCP, l'attribut étant ignoré
- Cela accélère le LCP en allégeant le chargement initial
- Cela introduit toujours un délai de chargement inutile et dégrade le LCP
Appliquer
loading=lazyà l’élément LCP ajoute toujours un délai inutile et dégrade le LCP. Le chargement différé doit être réservé aux images situées sous la ligne de flottaison. -
Réduire le poids de l'image LCP suffit-il toujours à améliorer le LCP ?
- Oui, à condition d'utiliser un format moderne comme le WebP
- Non, si l'élément reste masqué jusqu'au chargement d'un script, le gain de poids ne suffit pas
- Oui, alléger l'image garantit toujours un meilleur LCP
Le LCP s’optimise de bout en bout. Si la ressource est découverte tard ou reste masquée jusqu’au chargement d’un script, réduire son poids ne corrige pas le vrai goulet d’étranglement.
À propos de l'auteur
Besoin d'un accompagnement SEO ?
Votre contenu principal s'affiche trop lentement ? Repérons ensemble les sous-parties du LCP à corriger en priorité.