Largest Contentful Paint (LCP) : optimiser le temps de chargement

Le Largest Contentful Paint (LCP) est la métrique Core Web Vitals sur laquelle échouent la plupart des sites web. Elle mesure le temps nécessaire au rendu du plus grand bloc de contenu visible à l'écran. Cet article explique comment le LCP fonctionne précisément, de quoi se compose le temps de chargement, comment tu peux optimiser le LCP sur le plan technique et pourquoi cette métrique influe directement sur la conversion et la visibilité des entreprises B2B en Europe.

Pourquoi le LCP compte pour les entreprises

Le LCP est l'un des trois Core Web Vitals avec lesquels Google évalue l'expérience utilisateur d'une page. C'est la plus exigeante des trois métriques. Selon le HTTP Archive Web Almanac 2025, 62 % des pages mobiles et 74 % des pages desktop atteignent une bonne valeur de LCP (étude internationale, données CrUX de juillet 2025). À titre de comparaison, l'INP atteint 77 % et le CLS 81 % de bonnes valeurs sur mobile. Le LCP est donc le facteur limitant : c'est précisément cette métrique qui décide le plus souvent si une page réussit le test Core Web Vitals. Au total, seules 48 % des origines mobiles et 56 % des origines desktop valident les trois Core Web Vitals (étude internationale).

Pour le marché autrichien, la performance mobile est particulièrement importante. En septembre 2025, environ 44,4 % de toutes les pages vues sur Internet en Autriche provenaient d'appareils mobiles (Autriche, données StatCounter hors tablettes). Selon le Web Almanac, les utilisateurs mobiles subissent presque deux fois plus souvent de mauvaises valeurs de LCP que les utilisateurs desktop, 13 % contre 7 % (étude internationale). Qui sert près de la moitié de son trafic sur mobile en Autriche optimise donc le LCP exactement là où la faiblesse est la plus grande.

Le business case est mesurable. Une étude A/B de Vodafone documentée par Google montre qu'un LCP amélioré de 31 % a entraîné 8 % de ventes en plus, un taux lead-to-visit amélioré de 15 % et un taux cart-to-visit amélioré de 11 % (étude internationale). Une analyse de Deloitte Digital et Fifty-Five pour Google confirme elle aussi le levier de la vitesse : dans le retail, un temps de chargement mobile plus rapide de seulement 0,1 seconde a augmenté le taux de conversion de 8,4 % et le panier moyen de 9,2 % (étude internationale). Pour les décideurs B2B, le LCP est donc un levier direct sur le chiffre d'affaires et la qualité des leads. Dans les décisions de classement serrées, la métrique sert en outre de critère de départage entre des résultats par ailleurs équivalents.

Comment fonctionne le LCP : seuils et sous-parties

Le LCP mesure le moment où le plus grand bloc de contenu visible dans le viewport est rendu. La mesure commence au début du chargement de la page. Les candidats typiques à l'élément LCP sont les images hero, les grands blocs de texte ou les vidéos. En pratique, les images dominent : sur 85,3 % des pages desktop et 76 % des pages mobiles, l'élément LCP est une image (étude internationale). Les éléments LCP textuels constituent le reste, un peu plus fréquents sur mobile (23,7 %) que sur desktop.

Google définit trois seuils, mesurés au 75e centile des données utilisateurs réelles :

• Bon : moins de 2,5 secondes. Cette valeur devrait être l'objectif de toute optimisation.
• À améliorer : entre 2,5 et 4,0 secondes. Il faut agir.
• Mauvais : plus de 4,0 secondes. Dans cette zone, l'expérience utilisateur souffre nettement.

Le 75e centile signifie que 75 % des chargements réels de la page doivent atteindre le seuil. Une bonne valeur en laboratoire sur un poste de développement rapide ne suffit donc pas si des appareils et des connexions plus lents tirent le centile vers le haut.

Pour optimiser le LCP de façon ciblée, il faut comprendre de quoi se compose ce temps. Google divise le LCP en quatre sous-parties :

• Time to First Byte (TTFB) : le temps nécessaire pour que le serveur envoie le premier octet de la réponse. Il comprend le DNS, l'établissement de la connexion et le traitement côté serveur.
• Resource Load Delay : l'intervalle entre le TTFB et le début du chargement de la ressource LCP. Du temps se perd ici lorsque le navigateur découvre tardivement l'image LCP.
• Resource Load Duration : le temps de chargement pur de la ressource LCP, c'est-à-dire la durée de téléchargement de l'image ou de la police.
• Element Render Delay : le temps entre le chargement complet de la ressource et son rendu effectif, souvent bloqué par du JavaScript ou du CSS.

Cette décomposition est la clé du diagnostic. Une image LCP lente appelle une autre mesure qu'un serveur lent ou un JavaScript qui bloque le rendu.

Bonnes pratiques : optimiser le LCP de façon ciblée

Les optimisations les plus efficaces agissent sur les quatre sous-parties. Voici les mesures qui ont le plus d'impact en pratique :

• Réduire le TTFB et accélérer le serveur : un serveur lent est souvent le poste le plus lourd. Le rendu côté serveur, un cache bien configuré et un CDN avec des points de présence edge raccourcissent les trajets. HTTP/3 (QUIC) et la compression Brotli accélèrent en plus le transfert. Pour un public européen, un hébergement ou un edge CDN proche de tes utilisateurs est rentable, par exemple un nœud à Vienne ou à Francfort.
• Bien servir l'image LCP : les formats modernes comme WebP et AVIF réduisent nettement la taille des fichiers par rapport au JPEG, à qualité égale. Pourtant, selon le Web Almanac, le JPEG reste, avec environ 57 %, le format d'image LCP le plus courant, suivi du WebP avec 11 %, tandis que l'AVIF n'atteint que 0,7 % (étude internationale). Il y a donc là un potentiel inexploité. Sers des variantes responsive via srcset et sizes, définis les bonnes dimensions d'image et applique fetchpriority="high" à l'image LCP. Un preload n'est nécessaire que si le navigateur ne trouve pas l'image directement dans le HTML, par exemple pour un arrière-plan CSS.
• Éviter le lazy loading de l'image LCP : l'image LCP ne doit jamais être chargée en différé. Selon le Web Almanac, environ 16 à 17 % des pages chargent leur image LCP en différé (étude internationale) et gaspillent ainsi un temps précieux. loading="lazy" est destiné aux images situées sous la zone visible, pas à l'élément LCP.
• Supprimer le blocage du rendu : le CSS critique doit être servi inline, le reste en différé. Le JavaScript se charge avec defer ou async pour ne pas bloquer le rendu. Les polices web reçoivent font-display: swap et un preload, afin que les blocs de texte n'attendent pas la police.

Erreurs fréquentes dans l'optimisation du LCP

Lors de l'optimisation, certains schémas coûteux en temps de chargement reviennent régulièrement :

• Charger l'image LCP en différé : l'erreur la plus fréquente. Un loading="lazy" appliqué à toutes les images touche aussi l'image hero et allonge inutilement le Resource Load Delay.
• N'optimiser que les valeurs de laboratoire : si tu ne regardes que les scores Lighthouse, tu optimises pour un test synthétique, pas pour de vrais utilisateurs. Le 75e centile des données de terrain peut être nettement moins bon.
• Ignorer le TTFB : beaucoup d'équipes optimisent les images alors que le vrai frein est le serveur. Sans regarder les sous-parties, on travaille au mauvais endroit.
• Conserver des formats d'image dépassés : la forte part du JPEG montre que les formats modernes sont rarement utilisés. Rester sur JPEG, c'est renoncer à un gain d'efficacité facile.
• Sous-estimer l'hydratation JavaScript : dans les frameworks modernes, l'élément LCP peut être entièrement chargé mais rendu avec retard à cause de l'hydratation. L'Element Render Delay augmente sans que l'image ou le serveur soient en cause.

Le LCP dans l'architecture Next.js

Next.js offre plusieurs mécanismes qui agissent directement sur le LCP. Le composant next/image sert automatiquement des formats modernes, des dimensions correctes et des tailles responsive. Pour l'image LCP, à partir de Next.js 16, tu définis loading="eager", pour qu'elle ne soit pas chargée en différé, et fetchPriority="high". L'ancienne prop priority est obsolète depuis Next.js 16 et remplacée par la prop preload. Selon la documentation, tu as toutefois rarement besoin de preload : dans la plupart des cas, loading="eager" ou fetchPriority="high" suffisent, et preload ne doit pas être combiné à ces props sur une même image. Dans Next.js 15 et les versions antérieures, priority reste la bonne approche. Une seule image par page, l'élément LCP, doit être priorisée de cette manière.

L'App Router, avec les Server Components et le SSR en streaming, rend les contenus critiques côté serveur et les envoie tôt au navigateur. Cela réduit le Resource Load Delay et l'Element Render Delay, car le contenu LCP n'est pas d'abord généré côté client. L'essentiel est de ne pas placer l'élément LCP derrière une hydratation côté client. Les contenus rendus en Server Component sont disponibles immédiatement. S'ils sont au contraire déplacés dans un Client Component à l'hydratation lourde, le délai de rendu augmente.

Métriques et mesure : données de terrain contre données de laboratoire

Le LCP se mesure de deux façons, et les deux sont nécessaires. Les données de terrain proviennent de vrais utilisateurs et reflètent la réalité. Elles sont issues du Chrome User Experience Report (CrUX), de PageSpeed Insights et de la Google Search Console. Ces données déterminent le 75e centile officiel et donc si une page réussit le test. Les données de laboratoire sont générées de manière synthétique dans des conditions contrôlées, par exemple avec Lighthouse ou des outils locaux. Elles sont reproductibles et permettent de tester des modifications avant le déploiement et d'isoler des causes précises.

Le point décisif : les deux se complètent. Les données de laboratoire montrent d'où vient le problème, les données de terrain montrent s'il touche vraiment les utilisateurs. Une optimisation n'est considérée comme réussie que lorsqu'elle se traduit dans les données de terrain.

Pour un contrôle continu, le Real User Monitoring (RUM) est recommandé. La bibliothèque officielle web-vitals mesure le LCP directement dans le navigateur de vrais utilisateurs et transmet les valeurs à un outil d'analyse. Tu peux ainsi configurer des alertes et repérer tôt les régressions après un déploiement. Sans ce monitoring, une dégradation du LCP n'est souvent remarquée qu'une fois les classements ou les conversions déjà touchés. Une place fixe dans le processus de déploiement, par exemple un contrôle Lighthouse automatique combiné à une comparaison RUM, protège contre les régressions insidieuses.

LCP, crawlers IA et GEO : bien situer la métrique

Un rendu côté serveur rapide aide les utilisateurs comme les crawlers. Les crawlers IA et les robots classiques des moteurs de recherche en profitent lorsque les contenus sont servis côté serveur, sans longues dépendances JavaScript. La même architecture qui améliore le LCP, c'est-à-dire le SSR, un TTFB rapide et peu de JavaScript bloquant le rendu, rend aussi les contenus accessibles de manière fiable aux crawlers IA.

La distinction est importante. Le LCP est une métrique de performance liée à l'expérience utilisateur, pas un facteur GEO direct. La Generative Engine Optimization se joue sur le contenu, la structure et la citabilité, pas sur le temps de chargement d'une image hero. Le LCP contribue indirectement, car un rendu serveur rapide facilite la diffusion aux crawlers. Mais il ne remplace aucune mesure GEO. Optimiser le LCP améliore l'accessibilité technique, pas la pertinence du contenu pour les réponses des IA.

Pour aller plus loin et conclusion

Le LCP est la métrique Core Web Vitals qui offre le plus grand potentiel d'optimisation et le lien le plus direct avec le business. Atteindre l'objectif de moins de 2,5 secondes au 75e centile des données de terrain améliore l'expérience utilisateur, la conversion, le taux de rebond et les chances lors de décisions de classement serrées. Pour y arriver, il faut travailler les quatre sous-parties : un serveur rapide, une image LCP découverte tôt et servie dans un format moderne, pas de lazy loading sur l'image hero et un chemin de rendu sans CSS ni JavaScript bloquant.

Les prochaines étapes utiles : mesurer le LCP actuel dans PageSpeed Insights et la Search Console, identifier l'élément LCP et ses sous-parties, puis mettre en place un Real User Monitoring pour un contrôle durable. Sur le marché autrichien, où la part du trafic mobile est élevée, il vaut particulièrement la peine de se concentrer sur le LCP mobile, car c'est là que se trouvent les plus grandes lacunes.