Core Web Vitals : le guide pratique pour un site qui charge vite

Que mesurent les Core Web Vitals

Les Core Web Vitals mesurent l'expérience réelle de vos visiteurs à travers trois indicateurs que Google suit de près. Le LCP, Largest Contentful Paint, mesure le temps avant l'affichage du plus gros élément visible, souvent l'image principale ou le titre : on vise sous 2,5 secondes. L'INP, Interaction to Next Paint, mesure la réactivité quand on clique ou qu'on tape, c'est-à-dire le délai avant que l'interface réponde : on vise sous 200 millisecondes. Le CLS, Cumulative Layout Shift, mesure les sauts de mise en page pendant le chargement, ces moments où le contenu bouge sous le doigt : on vise sous 0,1.

Ces seuils ne sont pas théoriques. Ils sont calculés sur les vrais utilisateurs de votre site, à partir des données collectées par le navigateur Chrome, et c'est ce qui les rend crédibles. Un site peut sembler rapide depuis votre fibre et votre ordinateur récent, tout en étant pénible sur un téléphone milieu de gamme en 4G. Les Core Web Vitals capturent cette réalité-là, celle de la majorité de vos visiteurs.

Quel impact réel sur le référencement

L'impact des Core Web Vitals sur le SEO est réel mais mesuré, et je préfère être honnête là-dessus plutôt que de survendre. Ce sont un facteur de classement, pas le facteur principal : un contenu pertinent prime toujours sur un site rapide mais vide. Aucune optimisation de vitesse ne fera ranker une page qui ne répond pas à la recherche de l'internaute.

En revanche, à pertinence égale, la vitesse fait la différence, et surtout elle joue sur la conversion. Un site qui répond vite garde ses visiteurs ; un site qui rame les fait fuir avant même qu'ils aient lu votre offre. Google s'appuie sur les données de terrain, celles des vrais navigateurs, pas seulement sur un test en laboratoire. Améliorer ces métriques sert donc deux objectifs à la fois : le référencement et le chiffre d'affaires. C'est rare qu'un même effort travaille sur les deux fronts, autant en profiter.

Faire passer le LCP au vert

Pour le LCP, l'image est presque toujours le coupable. Je sers les visuels en AVIF ou WebP, des formats nettement plus légers que le JPEG, et toujours dimensionnés à la taille réelle d'affichage. Servir une photo de 4000 pixels dans un emplacement de 600 pixels, c'est faire télécharger au visiteur dix fois trop de données pour rien. Je précharge l'image principale et je réserve son espace avec des attributs width et height, ce qui aide aussi le CLS au passage.

Les polices web sont l'autre frein fréquent. Je les charge avec font-display swap et un préchargement de la police critique, sinon le texte clignote ou disparaît au démarrage le temps que la police arrive. Le rendu côté serveur fait le reste : via les React Server Components de Next.js, par exemple, le navigateur reçoit un HTML déjà prêt à afficher, ce qui raccourcit nettement le LCP par rapport à une page entièrement construite en JavaScript dans le navigateur. Moins le navigateur a de travail avant d'afficher, plus l'écran se remplit vite.

Maîtriser l'INP et le CLS

L'INP se règle en libérant le thread principal du navigateur. Quand on clique et que rien ne se passe pendant une fraction de seconde, c'est presque toujours du JavaScript qui monopolise ce thread et empêche l'interface de répondre. Je découpe les bundles pour ne charger que le code utile à la page, je diffère le code non critique, et j'évite les scripts tiers lourds comme certains chats en direct ou trackers mal intégrés, qui plombent la réactivité sans qu'on les voie.

Le CLS se traite en réservant l'espace de tout ce qui s'affiche en retard : images, publicités, bannières de consentement, éléments injectés par du script. Je n'insère jamais de contenu au-dessus de ce que l'utilisateur est déjà en train de lire, car rien n'agace plus qu'un bouton qui se dérobe au moment où on le vise. Pour mesurer, j'utilise PageSpeed Insights côté laboratoire et la Search Console côté terrain, parce que les deux ne disent pas la même chose : le labo donne un diagnostic reproductible, le terrain donne la vérité de vos visiteurs. Un site rapide n'est pas un coup de chance, c'est une suite de décisions prises à chaque ligne de code.