Core Web Vitals : rendre un site rapide pour de vrai
La vitesse n'est pas un luxe : c'est un facteur de classement Google et de conversion. Décryptage des Core Web Vitals — LCP, INP, CLS — et des leviers concrets que j'utilise pour les tenir au vert.
« Ça marche bien chez moi » ne suffit pas
Le piège classique : le développeur teste sur une fibre, un MacBook récent, avec le cache chaud. L'utilisateur réel, lui, arrive sur un mobile milieu de gamme, en 4G capricieuse, le cache vide. Entre les deux, l'expérience n'a rien à voir.
Les Core Web Vitals existent pour mesurer ce que vit vraiment l'utilisateur. Google en a fait un facteur de classement — et surtout, ils prédisent la conversion : chaque seconde de chargement en trop fait fuir des visiteurs.
Les trois métriques qui comptent
- LCP (Largest Contentful Paint) — le temps avant que l'élément principal (souvent l'image ou le titre du hero) s'affiche. Objectif : sous 2,5 s.
- INP (Interaction to Next Paint) — la réactivité : le délai entre un clic et la réponse visible. Objectif : sous 200 ms. C'est le nerf de la guerre sur les sites riches en JavaScript.
- CLS (Cumulative Layout Shift) — la stabilité : ces sauts de mise en page qui font cliquer au mauvais endroit quand une image ou une pub se charge. Objectif : sous 0,1.
Un beau site lent est un site raté. La performance n'est pas l'ennemie du design — c'est une contrainte qui force à faire des choix nets.
Les leviers que j'utilise
Rendre un site rapide n'a rien de magique, c'est une somme de décisions :
- Images — format moderne (AVIF/WebP), dimensions correctes,
lazy loadingsous la ligne de flottaison, et une réservation d'espace pour éviter les sauts (CLS). - Polices —
font-display: swap, préchargement des graisses réellement utilisées, et surtout : ne charger que celles-là. - JavaScript — en envoyer le moins possible. Le code le plus rapide est celui qu'on n'expédie pas au navigateur. Composants serveur, chargement différé du non-critique.
- Rendu — privilégier le statique (pré-généré au build) quand le contenu le permet : rien ne bat un fichier déjà prêt.
- Mesure continue — un budget de performance et une surveillance (Lighthouse, Speed Insights) pour qu'une régression se voie avant la mise en production, pas après.
Mesurer sur le terrain, pas en labo
Il y a deux façons de mesurer : les données de labo (Lighthouse, environnement contrôlé) et les données de terrain (les vrais utilisateurs, via le Chrome UX Report). Les deux sont utiles, mais seule la seconde reflète la réalité. Un site peut afficher 100 en labo et décevoir sur le terrain à cause d'une connexion lente ou d'un appareil modeste.
Ma discipline : optimiser en labo pour aller vite, mais valider sur le terrain avant de crier victoire.
Pourquoi ça compte pour un client
Un site rapide n'est pas qu'une coquetterie technique. C'est plus de visiteurs qui restent, mieux classés sur Google, et plus de conversions. La vitesse est une des rares améliorations qui sert à la fois l'utilisateur, le référencement et le chiffre d'affaires. C'est pour ça que je la traite comme une exigence, pas comme un bonus.