Core Web Vitals : guide définitif pour optimiser LCP, FID et CLS

LCP en profondeur : anatomie et optimisation

Le LCP (Largest Contentful Paint) est souvent considéré comme le Core Web Vital le plus intuitif : il mesure simplement le temps nécessaire pour afficher le plus grand élément de contenu dans le viewport. Mais cette simplicité apparente cache une complexité technique que ce guide Core Web Vitals va décortiquer.

Le navigateur identifie l'élément LCP dynamiquement pendant le chargement. Il peut changer plusieurs fois : d'abord un titre H1, puis une image qui se charge après. L'élément final retenu est celui qui est le plus grand au moment où l'utilisateur interagit pour la première fois (ou au bout de la phase de chargement si pas d'interaction). Les types d'éléments éligibles sont : les images (<img>, <image> dans SVG), les éléments avec background-image url(), les vidéos avec poster, et les éléments de texte bloc (paragraphes, titres).

L'anatomie du LCP se décompose en quatre phases distinctes, et chaque phase a ses propres leviers d'optimisation. La première est le TTFB (Time to First Byte). C'est le temps entre la requête du navigateur et la réception du premier octet de la réponse HTML. Un TTFB lent signifie que votre serveur met trop de temps à répondre. Les solutions : passer à un hébergement Edge (Vercel, Cloudflare Workers), activer le caching serveur (Redis, CDN), compresser avec Brotli, et passer au HTTP/3. Un TTFB correct se situe sous les 800 millisecondes.

La deuxième phase est le resource load delay — le temps entre la réception du HTML et le moment où le navigateur commence à charger la ressource LCP. Cette phase est critique et souvent négligée. Si votre image LCP n'est pas directement dans le HTML (par exemple, elle est dans un composant React chargé via JavaScript, ou dans une CSS background-image), le navigateur ne peut pas commencer son téléchargement avant d'avoir exécuté le code correspondant. La solution : assurez-vous que l'image LCP est dans le HTML initial avec une balise <img> standard et ajoutez un <link rel=“preload”> dans le head.

La troisième phase est le resource load time — la durée de téléchargement de la ressource elle-même. Pour les images, c'est directement lié à la taille du fichier. Compressez en WebP (30% plus léger que JPEG) ou AVIF (50% plus léger). Utilisez des dimensions adaptées au viewport : ne servez pas une image 4K à un écran mobile de 375px. Le srcset et sizes natifs ou le composant Image de Next.js gèrent cette logique automatiquement.

La quatrième phase est le element render delay — le temps entre la fin du téléchargement et le rendu visuel. Les causes principales : un CSS bloquant qui empêche le rendu, des web fonts qui retardent l'affichage du texte, ou un JavaScript qui modifie le DOM après le chargement. Minimisez le CSS critique (inline le CSS above-the-fold), utilisez font-display: swap, et évitez les manipulations DOM synchrones.

INP en profondeur : mesurer la vraie réactivité

Le calcul de l'INP est subtil. Le navigateur enregistre la latence de chaque interaction (clic, tap, frappe clavier). Pour les sessions courtes (moins de 50 interactions), il retient la pire. Pour les sessions longues, il prend le 98e percentile — ce qui signifie qu'une ou deux interactions lentes sur 100 ne comptent pas, mais la troisième oui. Cela reflète une réalité utilisateur : une interaction lente occasionnelle est tolérable, mais des lenteurs récurrentes détruisent l'expérience.

Chaque interaction se décompose en trois phases. Le input delay est le temps entre l'action utilisateur et le début de l'exécution du handler. Il est causé par des tâches JavaScript qui occupent le thread principal au moment de l'interaction. Le processing time est la durée d'exécution des callbacks associés à l'événement. Le presentation delay est le temps nécessaire au navigateur pour calculer le layout, peindre les pixels et les afficher à l'écran après le traitement.

Pour réduire l'input delay, la stratégie principale est de casser les long tasks. Une long task est tout bloc JavaScript qui s'exécute pendant plus de 50 millisecondes sans rendre la main au navigateur. Utilisez scheduler.yield() (disponible dans les navigateurs modernes) ou un pattern setTimeout(callback, 0) pour découper les traitements longs en morceaux. Cela permet au navigateur de traiter les interactions utilisateur entre chaque morceau.

Pour le processing time, optimisez vos event handlers. Évitez les opérations DOM coûteuses (querySelectorAll sur des milliers d'éléments), les calculs de layout forcés (lecture de offsetHeight après une écriture de style), et les re-renders React inutiles (utilisez React.memo, useMemo et useCallback). Sur les applications React, le Profiler DevTools identifie précisément les composants qui se re-rendent lors de chaque interaction.

Pour le presentation delay, le levier principal est de réduire la complexité du DOM et du CSS. Un DOM profond avec des milliers de noeuds ralentit le calcul du layout. Un CSS avec des sélecteurs complexes (descendant selectors imbriqués) ralentit le style recalculation. Gardez le DOM le plus plat possible et utilisez des classes CSS simples — ce que Tailwind encourage naturellement grâce à son approche utility-first.

CLS en profondeur : chaque pixel compte

Le CLS (Cumulative Layout Shift) quantifie l'instabilité visuelle d'une page. Chaque fois qu'un élément visible se déplace de manière inattendue, un score de décalage est calculé en multipliant la fraction d'impact (la portion du viewport affectée) par la fraction de distance (la distance de déplacement relative au viewport). Le CLS est la somme de ces scores sur la fenêtre de session la plus importante.

Depuis 2022, le CLS utilise un système de fenêtres de session (session windows). Au lieu de cumuler tous les décalages de la vie de la page, il les regroupe en sessions de 5 secondes maximum avec un écart maximal d'une seconde entre deux shifts. Le CLS final est le score de la plus grande session. Ce changement a réduit la pénalisation des pages longues avec du contenu dynamique légitime (infinite scroll, lazy loading).

Les images sans dimensions restent la cause numéro un de CLS. Quand une image se charge sans width/height définis, le navigateur ne peut pas réserver l'espace — il affiche le texte, puis l'image pousse tout vers le bas. La solution est triviale : ajoutez toujours width et height, ou utilisez la propriété CSS aspect-ratio. Le composant Image de Next.js gère cela automatiquement en exigeant les dimensions.

Les contenus injectés dynamiquement au-dessus du fold sont la deuxième cause. Bannières publicitaires, barres de notification, bandeaux cookies — tout élément qui s'insère en haut de page et pousse le contenu provoque un CLS important. Les solutions : positionnez ces éléments en fixed/sticky (ils ne déplacent pas le contenu), ou réservez l'espace dans le layout initial avec un placeholder de taille fixe.

Les web fonts provoquent un type de CLS subtil : le FOUT (Flash of Unstyled Text). Le texte s'affiche d'abord avec une police de fallback, puis bascule vers la police personnalisée — ce changement modifie les dimensions des blocs texte et cause un décalage. La solution optimale : utilisez font-display: optional (la police custom s'affiche uniquement si elle est dans le cache, zéro FOUT) ou font-display: swap combiné avec un fallback dont les métriques sont ajustées via le descriptor size-adjust en CSS.

Outils de mesure : lab vs terrain

La mesure des Core Web Vitals s'appuie sur deux types de données fondamentalement différents, et confondre les deux est l'une des erreurs les plus fréquentes. Les données lab (laboratoire) proviennent de tests simulés dans des conditions contrôlées. Les données terrain (field data) proviennent des vrais utilisateurs via le Chrome User Experience Report (CrUX).

Outils lab : Lighthouse (intégré dans Chrome DevTools ou en CLI), PageSpeed Insights (partie “diagnostic”), WebPageTest, et les audits Lighthouse CI pour l'intégration dans votre pipeline CI/CD. Les données lab sont reproductibles et idéales pour le diagnostic — vous pouvez tester, modifier, re-tester. Mais elles ne reflètent pas les conditions réelles de vos utilisateurs (réseau variable, appareils différents, comportements de navigation variés).

Outils terrain : Le rapport Core Web Vitals de Google Search Console, les données CrUX dans PageSpeed Insights (partie “données terrain”), et la librairie JavaScript web-vitals.js intégrée dans votre code pour un monitoring en temps réel. C'est ce que Google utilise pour le classement. Les données terrain sont la vérité, mais elles nécessitent suffisamment de trafic pour être fiables (au moins 200 sessions sur 28 jours).

L'approche optimale combine les deux. Utilisez les données terrain pour identifier les pages problématiques, puis les outils lab pour diagnostiquer et résoudre. Intégrez web-vitals.js pour monitorer en continu et détecter les régressions après chaque déploiement. Pour les sites à fort trafic, envoyez les données CWV vers votre analytics (GA4 supporte les événements web-vitals nativement) pour segmenter par page, appareil et source de trafic.

Les 10 erreurs CWV les plus courantes

Après des centaines d'audits de performance, voici les erreurs que nous voyons le plus souvent en matière de Core Web Vitals. Chacune a un impact mesurable et une solution directe.

1. Images LCP sans preload. L'image hero est découverte tard dans la cascade de chargement. Solution : ajoutez un <link rel=“preload” as=“image”> ou utilisez fetchpriority=“high”. 2. Images sans dimensions. Cause CLS systématique. Solution : width/height ou aspect-ratio. 3. Third-party scripts non différés. Google Tag Manager, analytics, chat widgets chargés en synchrone bloquent le thread principal. Solution : async/defer ou chargement post-interaction.

4. CSS non-critique dans le head. Tout le CSS charge de manière bloquante par défaut. Solution : extraire et inliner le CSS critique, charger le reste en async. 5. Fonts non optimisées. Polices Google Fonts chargées depuis le CDN externe avec render-blocking. Solution : self-hosting avec next/font ou font-display: swap + preload. 6. Hydration excessive en React. Tous les composants côté client alors que 80% n'ont pas d'interactivité. Solution : Server Components par défaut.

7. Bundle JavaScript monolithique. Tout le code dans un seul fichier. Solution : code splitting par route (automatique en Next.js) + dynamic imports pour les composants lourds. 8. Pas de CDN ou CDN mal configuré. Le serveur origin est loin des utilisateurs. Solution : CDN Edge avec caching agressif et stale-while-revalidate. 9. Bandeau cookies mal implémenté. Injecté en haut de page, pousse le contenu. Solution : position fixed.

10. Optimiser uniquement pour le lab. Score Lighthouse parfait mais CWV terrain médiocre. Solution : monitorer les données CrUX et web-vitals.js, segmenter par appareil et réseau, et optimiser pour le 75e percentile réel de vos utilisateurs.

Checklist d'optimisation complète

Voici la checklist que nous utilisons chez Lokvo pour chaque audit de performance. Suivez-la méthodiquement pour couvrir l'ensemble des optimisations Core Web Vitals.

LCP Checklist : TTFB sous 800ms (CDN Edge, caching serveur, Brotli). Image LCP avec preload et fetchpriority=“high”. Images en WebP/AVIF avec srcset adaptatif. CSS critique inliné, CSS non-critique en async. Fonts preloadées et self-hosted. Pas de lazy loading sur l'image LCP. HTML streamé (Suspense boundaries en Next.js).

INP Checklist : Pas de long tasks (>50ms) sur le thread principal. Event handlers optimisés (pas de recalcul layout forcé). Third-party scripts chargés en defer/async ou post-interaction. Debouncing sur les inputs fréquents (scroll, resize, search). Server Components par défaut (React). Dynamic imports pour composants interactifs lourds. scheduler.yield() pour découper les traitements longs.

CLS Checklist : Toutes les images avec width/height ou aspect-ratio. Espace réservé pour les publicités/embeds. Bandeau cookies en position fixed/sticky. font-display: swap ou optional sur les web fonts. Pas d'injection de contenu au-dessus du viewport après le chargement. Animations CSS via transform (ne cause pas de layout shift) plutôt que via top/left/width/height.

Monitoring Checklist : web-vitals.js installé et connecté à votre analytics. Rapport CWV Search Console vérifié mensuellement. Lighthouse CI dans la pipeline de déploiement. Alertes sur les régressions CWV après chaque mise en production. Segmentation des données par page type, appareil et source géographique.

Cette checklist couvre les fondamentaux. Pour des optimisations avancées spécifiques à votre stack technique, consultez notre article sur les Core Web Vitals 2026 qui détaille les optimisations Next.js, ou contactez notre équipe pour un audit technique complet.