Google mesure l'expérience de chargement de vos pages à travers trois indicateurs, les Core Web Vitals. Ce ne sont pas des métriques abstraites de développeur : elles capturent ce que ressent réellement un visiteur — attendre, ne pas pouvoir cliquer, voir la page bouger sous ses yeux. Voici ce qu'elles mesurent et comment agir dessus.
Les trois indicateurs
LCP — Largest Contentful Paint
Le temps au bout duquel le plus grand élément visible (souvent l'image principale ou le titre) est affiché. C'est le meilleur proxy de « à partir de quand la page paraît chargée ». Objectif : sous 2,5 secondes.
INP — Interaction to Next Paint
Le temps de réaction de la page à une interaction (clic, tape, appui). Il a remplacé l'ancien FID en 2024 et mesure la réactivité tout au long de la visite, pas seulement au premier clic. Objectif : sous 200 millisecondes.
CLS — Cumulative Layout Shift
La stabilité visuelle : est-ce que des éléments se déplacent pendant le chargement ? Vous avez tous vécu ce moment où vous allez cliquer et une publicité s'insère, décalant tout. Le CLS mesure ça. Objectif : sous 0,1.
Données de labo contre données réelles
Point méthodologique essentiel, souvent source de confusion. Il existe deux types de mesures :
- Les données de labo (Lighthouse, PageSpeed Insights en mode simulé) : un test unique, dans des conditions contrôlées. Utile pour déboguer, mais ce n'est pas ce que voit Google.
- Les données de terrain (CrUX, le rapport dans la Search Console) : les mesures réelles de vos vrais visiteurs, sur leurs vrais appareils et connexions. C'est ce que Google utilise pour le classement.
Un score Lighthouse de 100 ne sert à rien si vos données de terrain sont mauvaises. Priorisez toujours les données de terrain. Elles sont agrégées sur 28 jours, donc une amélioration met plusieurs semaines à se refléter — ne vous découragez pas d'un résultat qui ne bouge pas immédiatement.
Améliorer le LCP sur WordPress
- L'image principale. C'est le coupable numéro un. Servez-la dans un format moderne (WebP ou AVIF), correctement dimensionnée, et sans lazy-loading sur l'image LCP (la retarder par lazy-load dégrade mécaniquement le LCP).
- Le cache serveur. Un cache de pages (statique ou objet, via Redis par exemple) évite de reconstruire la page à chaque visite. C'est le levier le plus rentable côté serveur.
- Le temps de réponse serveur (TTFB). Un hébergement lent plombe tout le reste. Aucun réglage front-end ne rattrape un serveur qui met une seconde à répondre.
Améliorer l'INP
L'INP est presque toujours un problème de JavaScript. Chaque script qui s'exécute monopolise le fil principal du navigateur et retarde la réponse aux interactions.
- Auditez vos extensions : chaque plugin qui charge son propre JavaScript sur toutes les pages est suspect. Beaucoup n'en ont besoin que sur une page précise.
- Méfiez-vous des scripts tiers (chats, trackers, widgets sociaux) : ils sont souvent les pires contributeurs à un mauvais INP.
- Différez (
defer) le JavaScript non essentiel pour qu'il ne bloque pas le rendu initial.
Éliminer le CLS
Le CLS se corrige presque toujours en réservant l'espace à l'avance :
- Spécifiez toujours
widthetheight(ou un ratio d'aspect) sur les images et vidéos, pour que le navigateur réserve leur place avant même de les charger. - Réservez un emplacement fixe pour les bannières, encarts et publicités, afin qu'ils n'insèrent pas d'espace en arrivant.
- Attention aux polices web : une police qui se charge tard peut provoquer un décalage. La stratégie
font-display: swapavec une police de repli aux métriques proches limite le saut.
Une méthode, pas une course au score
Ne cherchez pas le 100/100. Cherchez à faire passer vos trois indicateurs de terrain dans le vert, sur mobile en priorité (c'est l'index mobile qui compte). Mesurez sur données réelles, corrigez le plus gros contributeur, attendez que la moyenne sur 28 jours se mette à jour, recommencez. La performance web est un entretien continu, pas un sprint ponctuel.