Améliorer le LCP : guide complet pour accélérer l'affichage de votre site

TTFB, chargement des ressources, rendu : les quatre leviers qui décident du LCP, avec les actions concrètes à appliquer sur WordPress pour passer sous la barre des 2,5 secondes.

Vous venez de livrer un site WordPress à votre client. Le design est soigné, le contenu est en place, les fonctionnalités tournent. Puis vous lancez un test PageSpeed Insights et le verdict tombe : LCP à 4,2 secondes sur mobile. Le client voit un score orange, pose des questions, et votre crédibilité prend un coup avant même la mise en production.

Ce scénario, les freelances et agences web le vivent régulièrement. Améliorer le LCP (Largest Contentful Paint) est devenu un passage obligé pour tout professionnel qui veut livrer un site performant, bien référencé et convaincant pour ses clients. Ce guide vous donne les clés pour diagnostiquer, comprendre et corriger un LCP lent, étape par étape, avec des actions concrètes applicables dès votre prochain audit.

Qu'est-ce que le LCP et pourquoi cette métrique compte

Le LCP dans les Core Web Vitals

Le Largest Contentful Paint mesure le temps nécessaire pour afficher le plus grand élément de contenu visible dans la fenêtre du navigateur. Cet élément est généralement une image hero, une vidéo ou un bloc de texte principal situé au-dessus de la ligne de flottaison. Google considère qu'un bon LCP se situe sous 2,5 secondes au 75e percentile des visites. Entre 2,5 et 4 secondes, la page est classée "à améliorer". Au-delà de 4 secondes, elle est jugée "médiocre".

Le LCP fait partie des trois Core Web Vitals, aux côtés du CLS (Cumulative Layout Shift) et de l'INP (Interaction to Next Paint, qui a remplacé le FID en mars 2024). Ces trois métriques constituent un signal de classement officiel dans l'algorithme de Google depuis mai 2021, et leur poids dans le référencement naturel s'est renforcé au fil des mises à jour.

L'impact concret sur le business de vos clients

Un LCP lent ne se limite pas à un mauvais score dans un outil de test. Selon les données publiées par Google, Vodafone a constaté une hausse de 8 % de ses ventes en ligne après avoir amélioré son LCP de 31 %. D'après le Web Almanac 2025 (HTTP Archive), seules 62 % des pages mobiles atteignent un bon score LCP, ce qui signifie que près de quatre pages sur dix échouent encore sur cette métrique.

Pour une agence ou un freelance, ces chiffres représentent un argument commercial puissant. Un audit qui identifie un LCP dégradé ouvre la porte à une prestation d'optimisation, voire à un contrat de maintenance récurrent. Le LCP transforme un diagnostic technique en opportunité business.

Les quatre sous-parties du LCP

Comprendre la décomposition selon Google

Google recommande de décomposer le LCP en quatre phases séquentielles pour identifier précisément où se situe le goulot d'étranglement. Ces quatre sous-parties, documentées sur web.dev, couvrent l'intégralité du chemin entre la requête initiale et l'affichage de l'élément principal.

La première phase est le TTFB (Time to First Byte), qui mesure le temps entre la navigation de l'utilisateur et la réception du premier octet de la réponse HTML. La deuxième est le délai de chargement de la ressource LCP, c'est-à-dire le temps entre le TTFB et le moment où le navigateur commence à télécharger l'image ou la police nécessaire. La troisième est la durée de chargement de la ressource elle-même. La quatrième est le délai de rendu de l'élément, soit le temps entre la fin du téléchargement et l'affichage effectif à l'écran.

La règle des 80/20

Sur une page bien optimisée, environ 80 % du temps LCP devrait être consacré aux requêtes réseau (TTFB + chargement de la ressource) et seulement 20 % aux délais intermédiaires. Si vos délais de chargement ou de rendu dépassent cette proportion, c'est le signe d'un problème d'architecture ou de ressources bloquantes qui retardent inutilement l'affichage.

Dans les audits réalisés avec Orilyt, nous constatons régulièrement que le délai de chargement de la ressource LCP est la phase la plus sous-estimée. Le navigateur ne peut pas télécharger une image s'il ne sait pas encore qu'elle existe, et c'est précisément ce qui se produit quand l'image hero est injectée par JavaScript ou référencée uniquement dans une feuille de style CSS.

Optimiser le TTFB pour poser les bases

Pourquoi le TTFB conditionne tout le reste

Le TTFB est la fondation du LCP. Si votre serveur met 2 secondes à répondre, atteindre un LCP sous 2,5 secondes devient mathématiquement impossible. Google recommande un TTFB inférieur à 800 millisecondes. Chaque milliseconde gagnée sur le TTFB se répercute directement sur le LCP et sur toutes les autres métriques de chargement.

Les causes les plus fréquentes d'un TTFB lent sont un hébergement mutualisé surchargé, l'absence de cache serveur, des requêtes SQL non optimisées et la distance géographique entre le serveur et les visiteurs. Pour approfondir ce sujet, notre guide dédié permet de comprendre et optimiser votre TTFB avec les seuils, les causes et les solutions.

Les actions prioritaires côté serveur

La mise en place d'un cache de page est le levier le plus rentable. Sur WordPress, un plugin comme WP Super Cache ou WP Rocket peut réduire le TTFB de 60 à 80 % en servant des pages HTML pré-générées au lieu d'exécuter PHP et des requêtes en base de données à chaque visite. Pour les sites à audience internationale, l'utilisation d'un CDN (Cloudflare, par exemple) permet de servir le contenu depuis un serveur géographiquement proche de chaque visiteur.

La réduction des redirections est un autre levier souvent négligé. Chaque redirection ajoute un aller-retour réseau complet. Un lien raccourci qui redirige vers une URL intermédiaire, puis vers la page finale, peut ajouter plusieurs centaines de millisecondes au TTFB sans que le visiteur ne s'en rende compte.

Réduire le délai de chargement de la ressource LCP

Faire découvrir la ressource le plus tôt possible

Le délai de chargement de la ressource est le temps perdu entre la réception du HTML et le moment où le navigateur commence effectivement à télécharger l'élément LCP. Sur une page bien construite, ce délai devrait être proche de zéro. En pratique, il explose quand l'image hero est chargée via JavaScript, référencée dans un fichier CSS externe, ou cachée derrière une chaîne de requêtes dépendantes.

La solution la plus efficace est de placer l'image LCP directement dans le HTML source de la page, via une balise img, plutôt que de la charger dynamiquement. Le navigateur découvre les images présentes dans le HTML dès le parsing initial, avant même d'avoir téléchargé les feuilles de style.

Utiliser preload et fetchpriority

Pour les cas où l'image LCP ne peut pas être placée directement dans le HTML (image de fond CSS, par exemple), la balise link rel="preload" indique au navigateur de commencer le téléchargement immédiatement. Combinée avec l'attribut fetchpriority="high", elle envoie un signal de priorité encore plus fort.

Attention cependant à ne pas abuser du preload. Précharger trop de ressources dilue l'effet de priorité et peut même ralentir le chargement global. Réservez le preload à l'image LCP et, éventuellement, à la police de caractères principale. Chaque ressource préchargée en trop consomme de la bande passante qui aurait pu servir à charger l'élément critique plus vite.

Consultez la documentation Orilyt pour comprendre comment nos tests de performance détectent automatiquement les ressources critiques mal priorisées.

Accélérer le chargement de l'image LCP

Choisir le bon format d'image

Quand l'élément LCP est une image (ce qui représente 76 % des cas sur mobile selon le Web Almanac 2025), la taille du fichier impacte directement la durée de chargement. Les formats modernes comme WebP et AVIF offrent une compression nettement supérieure au JPEG et au PNG traditionnels, sans perte de qualité perceptible.

AVIF, en particulier, permet des réductions de poids de 30 à 50 % par rapport au WebP sur les photographies, et sa compatibilité navigateur atteint désormais 94 % au niveau mondial. Sur WordPress, des plugins comme ShortPixel ou Imagify automatisent la conversion et servent le format optimal en fonction du navigateur du visiteur.

Dimensionner correctement les images

Une erreur fréquente consiste à servir une image de 2400 pixels de large pour un affichage de 800 pixels sur mobile. Le navigateur télécharge des données inutiles, ce qui allonge la durée de chargement sans bénéfice visuel. L'attribut HTML srcset permet de servir des images adaptées à chaque taille d'écran, et WordPress le gère nativement depuis la version 4.4.

Chez Orilyt, nous analysons les ressources chargées par chaque page auditée. Quand une image est surdimensionnée par rapport à sa zone d'affichage, le rapport le signale avec une recommandation précise, en indiquant le gain potentiel en kilo-octets.

Ne jamais lazy-loader l'image LCP

Le lazy loading retarde volontairement le chargement d'une image jusqu'à ce qu'elle soit proche de la zone visible. C'est excellent pour les images situées sous la ligne de flottaison, mais catastrophique pour l'élément LCP. D'après le Web Almanac 2025, 16 % des sites mobiles appliquent le lazy loading à leur image LCP par erreur, ce qui double pratiquement le temps de chargement de cet élément.

Si votre image hero porte l'attribut loading="lazy", retirez-le immédiatement et ajoutez plutôt fetchpriority="high". C'est l'une des corrections les plus simples et les plus impactantes que vous puissiez appliquer sur un site WordPress.

Éliminer les délais de rendu inutiles

Identifier les ressources qui bloquent l'affichage

Une fois la ressource LCP téléchargée, le navigateur doit encore l'afficher. Ce délai de rendu devrait être minimal, mais il peut exploser si des feuilles de style CSS volumineuses ou des scripts JavaScript bloquent le thread principal. Tant que le CSS critique n'est pas chargé et analysé, le navigateur ne peut rien afficher, même si l'image est déjà en mémoire.

La suppression des CSS inutilisés est un levier majeur. Sur un site WordPress typique utilisant un constructeur de pages comme Elementor ou Divi, il n'est pas rare que 80 % du CSS chargé ne soit jamais utilisé sur la page en cours. Réduire ce CSS accélère le parsing et libère le thread principal pour le rendu.

Différer les scripts non critiques

Les scripts JavaScript chargés dans le head sans attribut defer ou async bloquent le parsing du HTML et retardent l'affichage de tout le contenu qui suit. Notre article sur les scripts bloquants et chargement différé explique en détail pourquoi un simple attribut defer peut transformer le comportement de chargement d'une page.

Les scripts tiers (analytics, widgets de chat, pixels publicitaires) sont souvent les premiers responsables. Chaque script tiers ajouté sans précaution consomme du temps CPU et de la bande passante au moment le plus critique du chargement. La bonne pratique consiste à différer tout ce qui n'est pas strictement nécessaire à l'affichage initial.

Réduire le poids du HTML lui-même

Un point souvent ignoré : la taille du document HTML impacte aussi le délai de rendu. Les constructeurs de pages WordPress génèrent parfois des DOM de plus de 3000 nœuds, avec des couches de div imbriquées qui n'apportent aucune valeur sémantique. Un HTML plus léger se parse plus vite, et l'élément LCP s'affiche plus tôt.

Certains développeurs obtiennent des gains de 25 % sur le LCP simplement en réduisant la quantité de code inline (CSS et JavaScript intégrés directement dans le HTML). Externaliser ces ressources dans des fichiers séparés permet au navigateur de les mettre en cache et de ne pas les re-télécharger à chaque visite.

Mesurer et suivre le LCP en continu

Les outils de diagnostic

PageSpeed Insights reste l'outil de référence pour une mesure ponctuelle. Il combine des données de laboratoire (Lighthouse) et des données terrain (Chrome UX Report) pour donner une vision complète. La section "Diagnostics" affiche l'élément LCP identifié ainsi qu'une décomposition des quatre sous-parties, ce qui permet de cibler précisément la phase à optimiser.

Google Search Console offre une vue d'ensemble au niveau du site entier. Le rapport Core Web Vitals classe chaque page dans les catégories "Bon", "À améliorer" ou "Médiocre", en se basant sur les données réelles des visiteurs Chrome. C'est l'outil idéal pour identifier les gabarits de pages qui posent problème (toutes les fiches produits, toutes les pages catégories, etc.).

Intégrer le suivi dans une offre de maintenance

Pour un freelance ou une agence, le suivi du LCP dans le temps est un argument de fidélisation. Un score qui se dégrade après l'ajout d'un nouveau plugin ou d'un slider en page d'accueil se détecte immédiatement si un monitoring est en place. Orilyt permet de surveiller plusieurs pages en continu et de générer des rapports périodiques en marque blanche, directement exploitables dans un rendez-vous client.

Découvrez les tarifs Orilyt pour intégrer le suivi de performance dans votre offre de maintenance.

Fixer des objectifs réalistes

Si votre LCP actuel est à 5 secondes, viser 2,5 secondes immédiatement peut être irréaliste selon l'infrastructure en place. Une approche progressive fonctionne mieux : commencez par descendre sous 4 secondes (sortir de la zone "médiocre"), puis visez les 2,5 secondes dans un second temps. Priorisez les pages qui génèrent du trafic ou des conversions, là où le retour sur investissement de l'optimisation est le plus élevé.

Documentez chaque intervention et mesurez l'impact avant/après. Un tableau comparatif montrant un LCP passé de 4,1 à 2,2 secondes est infiniment plus convaincant qu'un discours technique pour justifier votre prestation auprès d'un client non technique.

Vos questions les plus fréquentes

Sources et références

• Google web.dev, Optimize Largest Contentful Paint — guide officiel d'optimisation du LCP par Google
• Google web.dev, Largest Contentful Paint (LCP) — définition et seuils officiels de la métrique LCP
• Google web.dev, Common misconceptions about how to optimize LCP — analyse des sous-parties LCP à partir des données CrUX
• HTTP Archive, Web Almanac 2025, Performance — statistiques de performance web et taux de conformité LCP
• MDN Web Docs, Fix your website's LCP by optimizing image loading — bonnes pratiques d'optimisation des images pour le LCP