Le 5 mai 2020, Google a publié un billet qui va occuper les développeurs WordPress pour les mois à venir : les Core Web Vitals. Trois métriques censées résumer, en trois chiffres, ce qu’un internaute ressent réellement quand il ouvre une page. Fini le temps où l’on se contentait de mesurer un vague « temps de chargement » sans savoir ce qu’il représentait pour l’utilisateur assis devant son écran.
Pour qui développe ou administre un site WordPress, la nouvelle n’est pas anodine : Google a précisé que ces signaux compteront à terme dans le classement des résultats de recherche. Avant de paniquer ou de se jeter sur le premier plugin de cache venu, il vaut mieux comprendre ce que chaque métrique mesure réellement, et pourquoi un thème mal construit ou une extension mal codée peut plomber les trois à la fois.
Pourquoi Google a créé ces métriques
Avant les Core Web Vitals, les développeurs disposaient déjà d’indicateurs comme le Time to First Byte, le First Contentful Paint ou le Speed Index. Le problème : ces métriques mesurent des événements techniques, pas une expérience. Un First Contentful Paint rapide ne garantit rien si le contenu principal met encore deux secondes à s’afficher, ou si les boutons bougent sous les doigts de l’utilisateur pendant qu’il essaie de cliquer.
Google a donc choisi trois axes qui correspondent à des questions concrètes que se pose un visiteur, sans même le formuler consciemment :
- Est-ce que la page se charge assez vite pour que je voie le contenu utile ? (LCP)
- Est-ce que la mise en page reste stable pendant que je lis ou que je clique ? (CLS)
- Est-ce que le site répond quand j’interagis avec lui ? (FID)
LCP : le Largest Contentful Paint
Le Largest Contentful Paint mesure le temps nécessaire pour afficher le plus grand élément visible dans la zone d’écran initiale (le viewport), sans défilement. Sur un article WordPress classique, il s’agit souvent de l’image à la une ou du titre principal si aucune image n’est présente au-dessus de la ligne de flottaison.
Google fixe le seuil suivant, calculé sur le 75e centile des chargements de vraies visites, mobile et desktop confondus :
| Évaluation | Seuil LCP |
|---|---|
| Bon | 2,5 secondes ou moins |
| À améliorer | entre 2,5 et 4 secondes |
| Mauvais | plus de 4 secondes |
Sur WordPress, le LCP se dégrade typiquement à cause d’images à la une non optimisées, d’un hébergement mutualisé lent à répondre, ou de polices web bloquantes chargées avant le rendu du contenu principal.
CLS : le Cumulative Layout Shift
Le Cumulative Layout Shift quantifie les décalages inattendus de mise en page pendant toute la durée de vie de la page. Chaque fois qu’un élément visible se déplace sans que l’utilisateur ait déclenché l’action (un clic, un appui sur une touche), cela compte dans le score. Le calcul combine la fraction d’écran touchée par le décalage et la distance parcourue par les éléments.
Un score inférieur à 0,1 est considéré comme bon, entre 0,1 et 0,25 comme à améliorer, et au-delà comme mauvais. Sur un site WordPress, les coupables habituels sont bien identifiés :
- des images ou des vidéos insérées sans attribut
widthetheight, qui réservent un espace nul avant leur chargement ; - des bannières de cookies ou publicitaires injectées après coup en haut de page ;
- des polices web personnalisées (web fonts) qui remplacent une police par défaut avec une largeur de caractères différente ;
- des blocs Gutenberg embarqués (tweets, vidéos) dont la taille finale n’est connue qu’après chargement du script tiers.
Sur les thèmes que nous auditons, la première cause de CLS élevé reste, de loin, l’oubli des dimensions sur les images insérées manuellement dans le contenu plutôt que via la bibliothèque de médias. Prenez le réflexe de toujours passer par l’éditeur de médias natif, qui renseigne
widthetheightautomatiquement.
FID : le First Input Delay
Le First Input Delay mesure le temps qui s’écoule entre la première interaction d’un utilisateur (un clic sur un menu, un appui sur un champ de formulaire) et le moment où le navigateur peut effectivement commencer à traiter cette interaction. Contrairement au LCP et au CLS, le FID ne peut être mesuré qu’en conditions réelles : il dépend directement du comportement de l’utilisateur, donc aucun outil de laboratoire ne peut le simuler parfaitement.
Un FID de 100 millisecondes ou moins est jugé bon. Au-delà de 300 millisecondes, l’expérience est considérée comme mauvaise. La cause la plus fréquente est un thread JavaScript principal occupé trop longtemps : scripts de tracking, sliders en JavaScript lourd, ou extensions WordPress qui chargent leur propre copie de jQuery ou de bibliothèques tierces sans se soucier de ce qui tourne déjà sur la page.
Comment mesurer ces métriques sur un site WordPress
Plusieurs outils permettent déjà d’observer ces valeurs, avec des nuances importantes entre données « de laboratoire » et données « de terrain » :
- PageSpeed Insights : combine une analyse Lighthouse (laboratoire) et, quand le trafic est suffisant, des données réelles issues du Chrome User Experience Report (CrUX).
- Lighthouse, intégré aux outils de développement de Chrome, pour une mesure locale reproductible mais qui ne reflète qu’une seule condition réseau et matérielle.
- La Search Console, qui agrège les données CrUX de votre propre domaine pour de vrais visiteurs, groupées par type de page.
Il est important de retenir que Lighthouse ne peut pas mesurer le FID, faute d’interaction réelle d’un utilisateur : il affiche à la place une estimation appelée Total Blocking Time, qui corrèle fortement avec un mauvais FID sans en être l’exacte équivalence.
En résumé
Les Core Web Vitals ne sont pas un gadget marketing de plus : ils traduisent en chiffres ce que vos visiteurs ressentent déjà intuitivement. Un LCP lent, un CLS élevé ou un FID poussif ne sont jamais des fatalités liées à WordPress en tant que tel, mais presque toujours la conséquence de choix : thème surchargé, extensions mal codées, images non optimisées, hébergement sous-dimensionné. Dans les prochains articles de cette série, nous détaillerons les leviers concrets pour agir sur chacune de ces métriques, en commençant par la mise en cache côté serveur.
