Core Web Vitals : le guide complet pour 2026

Votre site est rapide « à l’œil ». Il s’affiche net, le scroll est fluide, vous en êtes fier. Et pourtant, dans Search Console, le rapport « Expérience de la page » est rouge, vos positions glissent, et vous ne comprenez pas pourquoi. Le problème : la vitesse ressentie au bureau, sur fibre et machine récente, n’a rien à voir avec ce que Google mesure — le terrain réel, sur mobile milieu de gamme et réseau dégradé. Depuis que l’INP a remplacé le FID en mars 2024, ce décalage coûte cher : un thread principal saturé pendant 400 ms après un clic ne se voit pas en démo, mais il plombe votre INP, donc votre classement.

Voici comment fermer cet écart, par où commencer, et les pièges qui font perdre du temps.

Par où commencer : le LCP d’abord

Si vous ne deviez optimiser qu’une métrique, ce serait le LCP. Trois raisons concrètes : il est presque toujours le plus loin de sa cible sur un site non optimisé, il dépend de leviers que vous contrôlez directement (images, CSS bloquant, hébergement), et il corrèle le mieux avec la perception de rapidité. Stabilisez le LCP, et le CLS comme l’INP deviennent plus simples à traiter ensuite.

LCP — Largest Contentful Paint

Cible : < 2,5 s sur le terrain (CrUX, 75e percentile)

Le LCP mesure le moment où le plus grand élément visible — souvent une image hero ou un bloc de texte principal — est rendu.

Dans l’ordre d’impact :

Identifier l’élément LCP réel (DevTools > Performance le marque) avant d’optimiser au hasard.
Précharger cette ressource avec <link rel="preload">, et seulement celle-là.
Servir des formats modernes : AVIF puis WebP en fallback.
Supprimer le CSS et le JS bloquants en tête de document ; inliner le CSS critique.
Servir depuis un CDN proche de l’utilisateur.

CLS — Cumulative Layout Shift

Cible : < 0,1

Le CLS mesure les décalages visuels inattendus : le bouton qui se déplace au moment où vous cliquez parce qu’une image ou une pub a poussé le contenu.

Causes principales :

Images et iframes sans dimensions explicites (width/height ou aspect-ratio).
Emplacements publicitaires sans espace réservé.
Contenu injecté au-dessus du contenu existant (bannières, encarts).
Substitution de fonte web mal gérée — le point le plus mal compris.

Le piège des fontes. On lit souvent que font-display: swap « cause » le CLS. C’est inexact. Le décalage vient du fait que la fonte de secours et la fonte web ont des métriques différentes (hauteur de x, chasse, interligne) : quand la web font remplace la fonte système, le texte se recompose et pousse la mise en page. swap ne fait que rendre cette substitution visible. La vraie solution n’est pas de bannir swap, mais d’aligner les métriques :

Déclarer une fonte de secours locale avec size-adjust, ascent-override et descent-override pour qu’elle occupe exactement la place de la web font.
Ou utiliser font-display: optional, qui renonce à la web font si elle n’arrive pas à temps — zéro décalage.
Et précharger la fonte critique (<link rel="preload" as="font" crossorigin>) pour réduire la fenêtre de substitution.

INP — Interaction to Next Paint

Cible : < 200 ms

Successeur du FID, l’INP mesure la réactivité de la page à toutes les interactions (clics, touches, frappe clavier), pas seulement la première. C’est la métrique qui sanctionne le JavaScript trop gourmand côté client.

Optimisations :

Découper les tâches longues (toute tâche JS > 50 ms bloque la réponse à l’interaction).
Réduire le JavaScript expédié au client — c’est ici qu’une architecture qui livre peu de JS par défaut, comme Astro, change la donne.
Optimiser les gestionnaires d’événements : déléguer, débouncer, sortir le travail lourd du chemin critique.

Sur scheduler.yield() — avec réserve. Cette API permet de céder la main au navigateur au milieu d’une tâche longue tout en reprenant la priorité ensuite. Élégante, mais encore récente et au support partiel : elle n’est pas disponible dans tous les navigateurs stables. Ne l’utilisez pas sans repli. Un fallback robuste :

Détecter la disponibilité (if ('scheduler' in window && 'yield' in scheduler)) et fournir une alternative.
Découper le travail avec setTimeout(…, 0) pour rendre la main entre deux lots.
Programmer le travail non urgent via requestIdleCallback.
Combiner avec navigator.scheduling.isInputPending() pour interrompre dès qu’une interaction utilisateur arrive.

Les outils de mesure

PageSpeed Insights : données terrain (CrUX) + données lab dans une même vue.
Chrome DevTools : panneau Performance pour traquer les Long Tasks et l’élément LCP.
web-vitals.js : la bibliothèque officielle pour mesurer en production, sur vos vrais utilisateurs.
Search Console : rapport « Expérience de la page », vos données terrain agrégées.

Règle de méthode : les données lab servent à diagnostiquer, les données terrain (CrUX) sont celles qui comptent pour le classement. Optimisez le lab, mais validez sur le terrain.

Ce que ça donne quand c’est fait sérieusement

On ne prêche pas dans le vide. Après notre migration WordPress → Astro, notre page d’accueil — mesurée au même protocole (Lighthouse mobile, Slow 4G, médiane de 3 runs) — affiche :

LCP 2,42 s (cible < 2,5 s) ✓
CLS 0,000 (cible < 0,1) ✓
TBT 0 ms — bon proxy lab de l’INP : le thread principal reste libre entre les interactions.

Le détail de la migration et le comparatif avant/après sont dans Pourquoi nous avons choisi Astro.

Pour chaque projet, nous auditons les Core Web Vitals avant livraison et visons Performance, Accessibilité et SEO > 95, Best Practices à 100. Ce n’est pas du perfectionnisme : c’est ce qui sépare un site rapide « à l’œil » d’un site rapide pour Google.

Votre site coince sur les Core Web Vitals ?

Si Search Console est rouge et que vous ne savez pas par quel bout commencer, on peut le diagnostiquer. Demandez un audit de performance : on identifie vos éléments LCP, vos sources de CLS et vos tâches longues, et on vous remet un plan d’action priorisé — LCP d’abord.