Core Web Vitals : mécanique de mesure et pièges à éviter.

Tout le monde a un avis sur les Core Web Vitals, et la plupart des chantiers d'optimisation partent quand même dans le mur. La raison tient rarement aux métriques elles-mêmes (elles sont bien documentées), mais à la mécanique de mesure qui les entoure : d'où viennent les chiffres, qui est compté, comment Google agrège, et pourquoi le score Lighthouse affiché fièrement en réunion ne prédit rien.

Ce billet reprend le fonctionnement réel du dispositif, métrique par métrique, et les pièges qu'on peut documenter pour chacune. Ce qu'il ne couvre pas : le tuto d'optimisation détaillé de chaque métrique (web.dev le fait très bien) ni le débat sur le poids réel des CWV (Core Web Vitals) dans le ranking.

Le trio et ses seuils

Trois métriques composent les Core Web Vitals. Le LCP (Largest Contentful Paint) mesure le temps d'affichage du plus grand élément visible dans le viewport initial. L'INP (Interaction to Next Paint) mesure la réactivité aux interactions sur toute la durée de vie de la page : il a remplacé le FID (First Input Delay) en mars 2024. Le CLS (Cumulative Layout Shift) quantifie l'instabilité visuelle.

Deux détails changent tout dans la lecture de ces seuils. D'abord, l'évaluation se fait au 75e percentile des sessions réelles : un quart de vos visiteurs peut vivre pire que le chiffre affiché, et la médiane confortable de vos tests sur fibre parisienne ne dit rien du mobile 4G en zone blanche.

Ensuite, la fenêtre d'observation est de 28 jours glissants : chaque correctif met des semaines à se refléter pleinement dans les rapports. Mobile et desktop sont évalués séparément, et une page « passe » quand les trois métriques sont au vert simultanément. D'après le rapport CrUX (Chrome User Experience Report) de mai 2026, environ 56 % des origines suivies passent les trois à la fois, alors que chaque métrique prise isolément affiche des taux de réussite entre 68 et 87 %. La leçon : la plupart des sites échouent à cause d'une seule métrique faible.

D'où viennent les chiffres : la tuyauterie CrUX

Les données qui comptent pour Google viennent du Chrome User Experience Report (CrUX) : les mesures remontées par les utilisateurs de Chrome ayant activé la synchronisation et le partage de statistiques, sur des pages publiquement découvrables. C'est ce qui alimente Search Console, la section « field data » de PageSpeed Insights, et le signal de ranking.

Cette tuyauterie a des angles morts qu'il faut connaître avant d'interpréter quoi que ce soit :

• Safari, Firefox et la plupart des webviews sont invisibles. Selon les baromètres usuels, iOS pèse autour d'un tiers du trafic mobile en France : cette part de l'audience n'existe pas dans les données que Google utilise. Vos utilisateurs iPhone peuvent souffrir sans que CrUX ne bronche, et inversement.
• L'agrégation se fait par URL (Uniform Resource Locator) quand le trafic suffit, sinon par origine. Un site à faible trafic n'aura que des données origine-level : impossible de distinguer la page d'accueil rapide du tunnel de commande poussif.
• Search Console groupe les URLs par similarité de template. Le statut d'un groupe correspond à sa pire métrique. Corriger une page individuelle ne déplace rien : c'est le template (header partagé, slot publicitaire, script tiers commun) qu'il faut traiter.
• La latence de 28 jours s'applique aux deux sens. Une régression met du temps à apparaître, un correctif met du temps à « verdir ». Comparer J+3 après déploiement relève de la lecture de marc de café.

Labo vs terrain : la confusion qui coûte le plus cher

Lighthouse tourne dans un environnement contrôlé : connexion simulée, CPU (Central Processing Unit) throttlé, aucune interaction utilisateur, aucun script de consentement accepté. C'est un outil de diagnostic, pas de mesure. Deux conséquences directes :

1. Lighthouse ne mesure pas l'INP. Il n'y a pas d'utilisateur pour interagir. Il fournit le TBT (Total Blocking Time), un proxy corrélé mais distinct : un TBT propre n'exclut pas un INP catastrophique sur un filtre de recherche ou un menu mobile.
2. Un score de 100 ne garantit rien en CrUX, et un score médiocre peut coexister avec un field data au vert. Les deux sections de PageSpeed Insights racontent des histoires différentes : le haut (field) est ce que Google voit, le bas (lab) sert à comprendre pourquoi.

La scène classique en réunion : quelqu'un ouvre Search Console, voit du rouge, brandit un Lighthouse à 95 et demande qui a cassé quoi. Personne n'a rien cassé. Les deux outils ne mesurent ni la même chose, ni les mêmes gens, ni au même moment.

LCP : anatomie et pièges

Le LCP se décompose en quatre segments, et la répartition entre eux dicte le correctif : TTFB (Time To First Byte : le serveur répond), resource load delay (le navigateur découvre la ressource), resource load time (il la télécharge), render delay (il l'affiche). L'attribution de la librairie web-vitals donne cette répartition en production.

Les pièges récurrents :

• Lazy-loader l'image LCP. L'anti-pattern numéro un, souvent injecté par défaut par un plugin d'optimisation ou un framework. Un loading="lazy" sur le hero retarde sa découverte et son chargement, l'exact inverse du but recherché.
• Cacher l'image hero au préchargeur. Un background-image en CSS (Cascading Style Sheets) ou une image injectée en JS (JavaScript) n'est découverte que tardivement. Une balise <img> dans le HTML (HyperText Markup Language) initial, avec fetchpriority="high", reste la voie royale. Le <link rel="preload"> avec imagesrcset dépanne quand la structure l'impose.

<img src="hero.avif" width="1200" height="630"
     fetchpriority="high" decoding="async"
     alt="…">
<!-- jamais loading="lazy" sur l'élément LCP -->

• S'acharner sur le poids d'image quand le TTFB mange le budget. Sur un TTFB à 800 ms, aucune conversion AVIF (AV1 Image File Format) ne sauvera le seuil des 2,5 s. C'est côté serveur que ça se joue : cache pleine page (Varnish, WP Rocket selon le contexte), worker mode FrankenPHP pour du Symfony, CDN (Content Delivery Network) correctement configuré, early hints 103 quand la stack le permet.
• Diagnostiquer sur un seul viewport. L'élément LCP change souvent entre mobile et desktop (une image ici, un H1 (titre de niveau 1) là). Les deux se traitent séparément : Google les évalue séparément aussi.

INP : anatomie et pièges

L'INP observe toutes les interactions d'une page vue (clic, tap, clavier : le scroll est exclu) et retient approximativement la pire (le 98e percentile, pour lisser les valeurs aberrantes sur les pages très interactives). Chaque interaction se découpe en trois phases : input delay (le main thread est occupé ailleurs), processing (vos handlers tournent), presentation delay (le frame suivant s'affiche).

C'est la métrique la plus échouée du trio, une grosse minorité de sites ratent les 200 ms, et elle se corrige rarement avec un plugin. Les pièges :

• Croire qu'un bon FID historique ou un bon TBT couvre le sujet. Le FID ne mesurait que le délai de la première interaction ; l'INP couvre toute la session, traitement et rendu compris. Un site « bon FID » peut être franchement mauvais en INP.
• Ne regarder que le chargement. Le menu mobile qui rame, le filtre de listing qui fige, l'accordéon poussif : tout compte, y compris dix minutes après l'arrivée sur la page.
• Des handlers qui font tout en synchrone. Le pattern correct : donner un retour visuel immédiat, puis céder le main thread avant le travail lourd (scheduler.yield() là où c'est disponible, sinon découpage via setTimeout), et déporter ce qui peut l'être en Web Worker.
• Les scripts tiers. Bandeau de consentement, analytics, chat, tag manager : chacun réclame sa part de main thread au pire moment. L'audit des tiers précède toute optimisation de son propre code.
• Diagnostiquer sur sa machine. Un M3 masque tout. DevTools avec throttling CPU 4-6x s'approche du téléphone milieu de gamme réel. En production, l'API (Application Programming Interface) Long Animation Frames (LoAF) et le build attribution de web-vitals identifient le script et l'élément responsables.

CLS : anatomie et pièges

Le CLS additionne les décalages de mise en page inattendus, regroupés en fenêtres de session (une fenêtre se ferme après 1 s sans shift, plafonnée à 5 s) ; la pire fenêtre fait le score. Les shifts survenant dans les 500 ms après une interaction utilisateur sont exclus : ouvrir un accordéon ne pénalise pas.

C'est la métrique la plus mécanique à corriger, et pourtant :

• Images et iframes sans dimensions. width/height (ou aspect-ratio en CSS) réservent l'espace avant le chargement. Basique, toujours oublié quelque part, souvent dans le contenu contribué.
• Les webfonts qui reflowent. Le swap d'une fallback vers la police finale déplace tout le texte si les métriques divergent. size-adjust et les descripteurs de fallback (ascent-override, etc.) alignent les métriques ; précharger la police critique réduit la fenêtre de swap.
• Le contenu injecté au-dessus de l'existant. Bandeau consent, barre promo, bloc de recommandations, publicités : tout ce qui arrive en asynchrone doit avoir un conteneur dimensionné à l'avance.
• Animer top/left au lieu de transform. Les premiers déclenchent des layouts comptabilisés, le second non.
• Oublier que ça court sur toute la vie de la page. Un carrousel mal fichu ou un lazy-load qui pousse le footer peut ruiner le score longtemps après le premier rendu.

Les pièges transversaux

Au-delà des métriques individuelles, les échecs de chantier CWV se ressemblent :

1. Optimiser le score au lieu de l'expérience. Deux semaines à gratter des points Lighthouse sur des optimisations que les visiteurs ne sentent jamais, pendant que le field data ne bouge pas.
2. Raisonner par URL quand Google raisonne par template. Le correctif qui compte s'applique au groupe d'URLs, se valide en field data, et se surveille après chaque déploiement.
3. Sur-pondérer l'enjeu SEO (Search Engine Optimization). Les CWV participent au ranking, mais la pertinence du contenu et l'autorité pèsent davantage ; ils jouent surtout les départage sur requêtes concurrentielles. L'argument massif est ailleurs : les études de cas web.dev (Rakuten 24, Vodafone, RedBus) documentent des gains de conversion et de revenu directs après optimisation. Le ROI (Return On Investment) se calcule côté business, le SEO vient en bonus.
4. Gober la désinformation. Mi-2026, une vague d'articles SEO annonce un seuil LCP « abaissé à 2,0 s », un « Visual Stability Index » ou des « Core Web Vitals 2.0 ». Rien de tout ça n'existe dans la documentation Google ou web.dev : les seuils restent 2,5 s / 200 ms / 0,1. Ces articles se citent entre eux, jamais la source. Avant de lancer un chantier sur la foi d'un blog, vérifier web.dev et le blog Search Central. Ce qui évolue réellement, c'est la mesure elle-même : l'intégration progressive des soft navigations côté Chrome, des affinements dans l'échantillonnage INP. D'où l'intérêt de suivre les release notes CrUX plutôt que les newsletters.
5. Piloter sans instrumentation. Entre deux rafraîchissements CrUX, on avance à l'aveugle. Un RUM (Real User Monitoring) maison ferme la boucle en heures au lieu de semaines.

La boucle de travail qui tient

Le workflow qui évite de tourner en rond : Search Console pour identifier les groupes d'URLs en rouge et la métrique fautive → PageSpeed Insights sur une URL représentative du groupe (field pour l'état, lab pour les hypothèses) → DevTools/WebPageTest pour reproduire et isoler → correctif au niveau template → RUM pour valider en jours → CrUX/Search Console pour confirmer en semaines.

Pour le RUM, la librairie officielle avec son build attribution suffit largement :

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function send(metric) {
  navigator.sendBeacon('/rum', JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    // élément LCP, script fautif INP, source du shift CLS
    attribution: metric.attribution,
    page: location.pathname,
  }));
}

onLCP(send);
onINP(send);
onCLS(send);

Côté stockage, n'importe quel endpoint qui pousse vers votre stack d'observabilité fait l'affaire ; l'API CrUX complète avec l'historique officiel par origine ou URL.

La performance web s'est banalisée en discipline opérationnelle : mesurer en continu, corriger par template, valider sur le terrain. Les équipes qui passent durablement au vert sont celles qui ont arrêté de courir après un score d'audit pour surveiller ce que vivent leurs visiteurs après chaque déploiement.