Core Web Vitals : Comment optimiser le LCP

Le Largest Contentful Paint (LCP) mesure la rapidité de chargement de votre contenu principal—l’image héros, le titre ou la vidéo que les visiteurs voient en premier. Lorsque cela prend plus de 2,5 secondes, les utilisateurs perçoivent votre site comme lent, les taux de rebond augmentent et vos scores Core Web Vitals en pâtissent. Ce guide détaille précisément comment diagnostiquer et corriger les problèmes de LCP à travers les quatre phases du processus de chargement.

Qu’est-ce que le Largest Contentful Paint (LCP) ?

Le LCP suit le temps de rendu du plus grand élément de contenu visible dans la fenêtre d’affichage avant l’interaction utilisateur. Il peut s’agir d’un <img>, <video>, ou d’un bloc de texte. Contrairement aux métriques abstraites, le LCP reflète ce que les utilisateurs vivent réellement—quand la page “semble” chargée.

Google définit des seuils clairs :

• Bon : Moins de 2,5 secondes
• À améliorer : 2,5-4,0 secondes
• Médiocre : Plus de 4,0 secondes

Pour réussir les Core Web Vitals, 75% de vos visites de page doivent atteindre des scores LCP “bons”. Cela impacte directement le classement SEO, car Google utilise les Core Web Vitals comme signal de classement.

Les quatre phases d’optimisation du LCP

Le LCP n’est pas une métrique unique—c’est la somme de quatre phases distinctes. Comprendre cette décomposition est crucial pour une optimisation ciblée :

1. Time to First Byte (TTFB) : Temps de réponse du serveur (~40% du LCP total)
2. Délai de chargement des ressources : Temps entre le TTFB et le début du téléchargement de la ressource LCP (<10%)
3. Durée de chargement des ressources : Temps de téléchargement effectif (~40%)
4. Délai de rendu de l’élément : Temps entre la fin du téléchargement et le rendu visuel (<10%)

Les phases de “délai” devraient approcher zéro. Tout temps d’attente est du pur gaspillage.

Phase 1 : Optimiser le temps de réponse du serveur (TTFB)

Un TTFB lent compromet tout le reste. Si votre serveur met 3 secondes à répondre, atteindre un LCP de 2,5 secondes devient impossible.

Problèmes TTFB courants :

• Redirections multiples (chacune ajoute 100-500 millisecondes)
• Serveurs distants des utilisateurs
• Code backend inefficace
• Goulots d’étranglement de base de données

Solutions :

• Implémenter la mise en cache côté serveur
• Utiliser un CDN pour servir le contenu depuis des emplacements de périphérie
• Minimiser les redirections—utiliser directement le format d’URL final
• Optimiser les requêtes de base de données et le traitement backend

Conseil pro : Les CDN peuvent masquer les problèmes de serveur. Testez avec des paramètres d’URL (ex. ?test=123) pour contourner les caches CDN et révéler les vraies performances serveur.

Phase 2 : Éliminer les délais de découverte des ressources

Le navigateur doit trouver votre ressource LCP immédiatement. Tout délai de découverte est du temps perdu.

Erreur critique : Appliquer le lazy-loading à l’image LCP. N’utilisez jamais loading="lazy" sur le contenu above-the-fold—cela retarde intentionnellement votre élément le plus important.

Rendre les ressources découvrables :

<!-- Bon : Image dans le HTML -->
<img fetchpriority="high" src="/hero.webp" alt="...">

<!-- Mauvais : Cachée dans le CSS -->
.hero { background-image: url('/hero.webp'); }

Pour les images de fond CSS (évitez-les pour le LCP quand possible), préchargez-les :

<link rel="preload" fetchpriority="high" as="image" href="/hero.webp" type="image/webp">

L’attribut fetchpriority="high" indique aux navigateurs de prioriser cette ressource par rapport aux autres. Sans cela, les images se téléchargent souvent avec une priorité “Low” par défaut.

Phase 3 : Réduire la durée de chargement des ressources

Les fichiers plus petits se téléchargent plus rapidement. Cette phase relève de la pure physique—réduire les octets, réduire le temps.

Optimisation d’images :

• Utiliser des formats modernes (WebP, AVIF)
• Implémenter des images responsives avec srcset
• Compresser sans perte de qualité visible
• Dimensionner correctement les images—ne pas charger d’images 4K pour mobile

Optimisation de polices pour LCP textuel :

• Utiliser font-display: swap pour afficher le texte immédiatement
• Sous-ensemble des polices aux caractères requis
• Précharger les polices critiques

Considérations CDN :

• Les CDN d’images optimisent automatiquement les formats et la compression
• Le service same-origin évite la surcharge de connexion
• Utiliser les fonctionnalités proxy CDN quand disponibles

Phase 4 : Minimiser le blocage de rendu

Même avec les ressources téléchargées, le rendu peut stagner à cause de la congestion du thread principal.

Bloqueurs courants :

• CSS bloquant le rendu dans <head>
• Exécution JavaScript synchrone
• Tâches longues des scripts tiers

Solutions :

CSS critique inline :

<style>
  /* Seulement les styles above-the-fold */
  .hero { /* styles */ }
</style>

Reporter le JavaScript non critique :

<script defer src="/app.js"></script>

Pour les éléments LCP textuels bloqués par les polices web, assurer le rendu de fallback :

@font-face {
  font-family: 'Custom';
  font-display: swap; /* Affiche le fallback immédiatement */
  src: url('/font.woff2') format('woff2');
}

Cas spéciaux : Vidéo et images de fond

Éléments vidéo : L’image poster ou la première frame devient le candidat LCP. Optimisez l’image poster comme toute autre image, et assurez-vous que l’encodage vidéo soit efficace.

Images de fond CSS : Elles créent des délais de découverte inhérents. Le navigateur ne peut pas précharger ce qu’il n’a pas analysé. Convertissez les images de fond critiques en éléments <img>, ou préchargez-les explicitement.

Mesurer et surveiller le LCP

Les données de laboratoire (PageSpeed Insights, Lighthouse) aident à diagnostiquer les problèmes, mais les données de terrain (CrUX, RUM) montrent l’expérience utilisateur réelle. Priorisez toujours les données de terrain—c’est ce que Google utilise pour les classements.

Utilisez le panneau Performance de Chrome DevTools pour voir les décompositions LCP localement. La bibliothèque JavaScript web-vitals permet une surveillance personnalisée :

import {onLCP} from 'web-vitals';

onLCP(({value, entries}) => {
  console.log('LCP:', value, entries[0].element);
});

Conclusion

Optimiser le LCP nécessite une attention systématique aux quatre phases. Commencez par le TTFB—aucune optimisation n’importe si votre serveur est lent. Assurez la découverte immédiate des ressources, minimisez les tailles de fichiers et éliminez les ressources bloquant le rendu. Plus important encore, n’appliquez jamais le lazy-loading à votre élément LCP. Avec ces optimisations en place, atteindre un LCP inférieur à 2,5 secondes devient non seulement possible, mais prévisible.

FAQ

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.