Les Core Web Vitals sont devenues le raccourci commode pour parler de performance. Trois lettres, trois seuils, un feu vert ou rouge dans la Search Console : difficile de faire plus lisible. C’est précisément ce qui les rend trompeuses.
Elles ne mesurent pas la vitesse de votre site. Elles mesurent ce que perçoit un utilisateur réel, sur son appareil, sur son réseau. La nuance change tout à la façon dont on les corrige.
Trois métriques, trois questions distinctes
Chaque métrique répond à une question que l’utilisateur se pose sans la formuler.
- LCP — « est-ce que quelque chose d’utile est apparu ? » Le plus gros élément visible doit être peint en moins de 2,5 s.
- INP — « est-ce que ça répond quand je clique ? » Successeur du FID depuis mars 2024, l’INP mesure la latence de toutes les interactions, pas seulement la première.
- CLS — « est-ce que le contenu me file entre les doigts ? » Un bouton qui se déplace au moment du clic, c’est un CLS qui explose.
Le piège du laboratoire
Lighthouse tourne sur une machine au calme, avec un réseau simulé. Les données du CrUX, elles, viennent de vrais Chrome, chez de vrais gens, souvent sur un milieu de gamme Android en 4G dégradée. Un site « 98/100 » en local peut échouer sur le terrain.
Optimiser le score plutôt que l’expérience, c’est soigner le thermomètre.
Un principe qu’on répète à chaque audit
La règle de travail est simple : on diagnostique en laboratoire, on valide sur le terrain. Les données CrUX ont 28 jours de latence — une correction déployée aujourd’hui ne se lira pas avant un mois.
Par où commencer
Dans neuf cas sur dix, le LCP se joue sur l’image d’en-tête : mal dimensionnée, chargée en lazy alors qu’elle est visible d’emblée, ou servie après une police bloquante. Le CLS, lui, vient presque toujours d’images sans dimensions déclarées ou d’un bandeau injecté en JavaScript.
Commencez par là. Ce sont rarement les corrections les plus savantes qui font bouger les courbes — ce sont les plus ennuyeuses.