Les Core Web Vitals : les trois métriques clés
Google a défini trois indicateurs de performance centrés sur l'expérience utilisateur réelle. Ils sont mesurés à partir des données de navigation des visiteurs de Chrome (données réelles, pas simulées).
| Métrique | Ce qu'elle mesure | Seuil "Bon" |
|---|---|---|
| LCP (Largest Contentful Paint) | Temps d'affichage du plus grand élément visible (image, titre, bloc) | Moins de 2,5 secondes |
| INP (Interaction to Next Paint) | Réactivité de la page lors d'une interaction (clic, frappe au clavier) | Moins de 200 millisecondes |
| CLS (Cumulative Layout Shift) | Stabilité visuelle : les éléments bougent-ils pendant le chargement ? | Score inférieur à 0,1 |
L'INP a remplacé le FID (First Input Delay) en mars 2024. Il mesure non plus le premier clic uniquement, mais l'ensemble des interactions pendant toute la visite.
Outils pour mesurer la performance
- PageSpeed Insights (Google) : analyse une URL depuis les serveurs Google, donne à la fois des données de labo et des données réelles (CrUX). C'est l'outil de référence.
- Google Search Console : le rapport "Expérience de page" agrège les données réelles de vos visiteurs sur l'ensemble du site. Très utile pour détecter les pages problématiques.
- Lighthouse : outil open source intégré aux DevTools Chrome, mesure les performances en conditions de labo.
- GTmetrix : combine Lighthouse et WebPageTest, permet de tester depuis différentes localisations géographiques.
- WebPageTest : outil avancé pour analyser chaque ressource chargée (waterfall), utile pour diagnostiquer les blocages précis.
Les leviers d'amélioration
Améliorer la performance d'un site, c'est agir sur plusieurs niveaux simultanément :
Les images
Les images sont souvent responsables d'un mauvais LCP. Je recommande : format WebP ou AVIF, compression adaptée, attribut loading="lazy" pour les images hors écran, et dimensions spécifiées dans le HTML pour éviter le CLS.
Le serveur et l'hébergement
Un serveur lent (TTFB élevé, Time To First Byte) pénalise toutes les autres métriques. Un hébergement mutualisé bon marché génère souvent des temps de réponse de 800 ms à 1,5 seconde. Un VPS ou un hébergement dédié fait souvent passer ce délai sous 200 ms.
CSS et JavaScript
Les fichiers CSS et JS bloquants retardent l'affichage. Solutions : minification, chargement différé (defer/async pour JS), suppression du CSS inutilisé, mise en cache navigateur.
Mise en cache
Un système de cache (fichiers statiques, cache navigateur, CDN) réduit drastiquement les temps de chargement pour les visiteurs récurrents et les utilisateurs géographiquement éloignés du serveur.
Lien avec le classement Google
Depuis mai 2021, les Core Web Vitals sont officiellement des signaux de classement dans le cadre du "Page Experience Update". Leur poids reste modéré par rapport à la pertinence du contenu, mais sur des requêtes compétitives où plusieurs sites ont un contenu équivalent, la performance peut faire la différence.
Je les intègre systématiquement dans mes audits SEO, au même titre que la structure, le maillage et le contenu.
Diagnostiquer le principal frein à la performance
Avant d'agir sur la performance, il faut identifier le vrai goulet d'étranglement. Agir sur les images quand le problème vient du serveur, ou l'inverse, perd du temps. PageSpeed Insights est l'outil de départ : ses recommandations indiquent généralement le type de problème dominant.
| Symptôme | Cause probable | Première action |
|---|---|---|
| TTFB (Time To First Byte) élevé > 600ms | Serveur ou hébergement lent | Changer d'hébergement, ajouter du cache serveur, passer à un VPS |
| LCP élevé sur une page avec une grande image hero | Image trop lourde ou pas préchargée | Compresser, passer en WebP, ajouter fetchpriority="high" sur l'image |
| CLS > 0,1 avec des sauts visuels | Dimensions manquantes sur images ou iframes, fonts qui se chargent | Spécifier width/height sur tous les médias, utiliser font-display: swap |
| INP > 200ms sur les clics | JavaScript lourd qui bloque le thread principal | Différer les scripts non nécessaires, réduire le JS inutilisé |
Performance sur WordPress : les points d'attention spécifiques
WordPress concentre une grande partie des sites web avec des problèmes de performance chroniques. La cause principale : les plugins. Chaque plugin peut ajouter des fichiers CSS et JS supplémentaires, des requêtes base de données et des appels serveur qui s'accumulent.
Les actions les plus efficaces sur WordPress :
- Plugin de cache : WP Rocket, W3 Total Cache ou LiteSpeed Cache selon l'hébergeur. Ils génèrent des fichiers statiques qui évitent de recalculer chaque page à chaque visite.
- Optimisation des images à l'upload : Imagify ou ShortPixel compressent les images automatiquement et les convertissent en WebP. À installer avant de charger les images, pas après.
- Minification CSS/JS : les plugins de cache incluent souvent cette option. Elle réduit la taille des fichiers de 20 à 40 % sans modifier leur comportement.
- Audit des plugins inutiles : chaque plugin inactif ou inutilisé peut encore charger des scripts. Supprimer (pas seulement désactiver) les plugins non nécessaires.
- CDN : Cloudflare gratuit suffit pour la plupart des sites. Il met en cache les ressources statiques sur des serveurs proches de l'utilisateur, réduisant la latence.
Questions fréquentes
La performance est-elle vraiment un facteur de classement Google ?
Oui, depuis 2021 et l'intégration officielle des Core Web Vitals dans l'algorithme. C'est un signal réel mais modeste : à contenu et autorité comparables, le site plus rapide passe devant. Sur des requêtes très concurrentielles, la performance peut faire la différence. Au-delà du facteur algorithmique direct, la performance impacte le taux de rebond et la conversion : tout ralentissement de 1 seconde au-delà de 3 secondes fait chuter le taux de conversion de plusieurs points.
Quels sont les seuils Core Web Vitals à viser ?
LCP (Largest Contentful Paint) : sous 2,5 secondes (bon), entre 2,5 et 4 (à améliorer), au-delà (mauvais). INP (Interaction to Next Paint) : sous 200 ms (bon), entre 200 et 500 (à améliorer), au-delà (mauvais). CLS (Cumulative Layout Shift) : sous 0,1 (bon), entre 0,1 et 0,25 (à améliorer), au-delà (mauvais). Google utilise les données réelles de Chrome (CrUX) sur 28 jours glissants.
Quels sont les leviers les plus efficaces pour améliorer la performance ?
Quatre actions à fort impact : optimiser les images (WebP, lazy loading, dimensionnement adapté) car elles représentent 60-80 % du poids des pages, mettre en place un cache full-page (Varnish, WP Rocket, Cloudflare), supprimer ou différer le JavaScript bloquant (defer, async, code splitting), passer sur un hébergement performant (mutualisé bas de gamme = limite haute des performances atteinte rapidement).
PageSpeed Insights donne 95/100 mais mes Core Web Vitals sont mauvais : pourquoi ?
PageSpeed Insights affiche deux types de données distincts. Le score sur 100 (en bas) est un score de laboratoire, mesuré en conditions idéales. Les Core Web Vitals (en haut) sont des données réelles d'utilisateurs (CrUX). C'est cette deuxième donnée qui compte pour le classement Google. Un site peut avoir un bon score lab mais des CWV réels dégradés si les utilisateurs ont des connexions lentes ou des appareils anciens.