Core Web Vitals sur WordPress : LCP, INP et CLS

Un site WordPress lent coûte des visiteurs, et Google mesure cette lenteur avec trois indicateurs publics : les Core Web Vitals. Ce tutoriel donne les seuils officiels, la façon de les mesurer, puis les réglages à faire dans l’ordre. La plupart des conseils s’appuient sur la documentation de Google ou de WordPress.

À retenir

Les seuils « bon » sont : LCP à 2,5 secondes ou moins, INP à 200 millisecondes ou moins, CLS à 0,1 ou moins, mesurés au 75e centile.
Les données terrain (utilisateurs réels) priment sur le score de laboratoire : regardez d’abord la Search Console et PageSpeed Insights.
Ne chargez jamais en différé l’image LCP, et donnez-lui une priorité haute.
Moins d’extensions, des images WebP ou AVIF, un cache et un PHP à jour règlent la majorité des cas.

Les trois seuils officiels de Google

Les Core Web Vitals mesurent le chargement (LCP, Largest Contentful Paint), la réactivité (INP, Interaction to Next Paint) et la stabilité visuelle (CLS, Cumulative Layout Shift). Google évalue ces valeurs au 75e centile des chargements de pages, séparément sur mobile et sur ordinateur. Une page réussit si les trois indicateurs sont bons, selon web.dev.

Indicateur	Bon	À améliorer	Mauvais
LCP (chargement)	2,5 s ou moins	de 2,5 s à 4 s	plus de 4 s
INP (réactivité)	200 ms ou moins	de 200 ms à 500 ms	plus de 500 ms
CLS (stabilité)	0,1 ou moins	de 0,1 à 0,25	plus de 0,25

Ces seuils figurent dans l’aide de la Search Console et dans les articles web.dev sur le LCP et le CLS.

Où en est le web aujourd’hui ?

Le Web Almanac 2025 de HTTP Archive donne un repère utile : sur mobile, 62 % des sites ont un bon LCP, 77 % un bon INP et 81 % un bon CLS. Le LCP est donc l’indicateur où il reste le plus à gagner. Sur ordinateur, les parts sont de 74 %, 97 % et 72 %. Le chapitre précise que la plupart des données CrUX sont mesurées par origine, donc par site.

Source : HTTP Archive, Web Almanac 2025, chapitre Performance (données CrUX, mobile).

Étape 1 : mesurer avant de toucher à quoi que ce soit

Deux outils suffisent. PageSpeed Insights affiche des données terrain issues du Chrome UX Report sur les 28 derniers jours, et des données de laboratoire produites par Lighthouse. Les premières montrent l’expérience réelle ; les secondes servent à diagnostiquer, car elles simulent un seul appareil sur un réseau fixé. Les deux peuvent donc différer. La page réussit l’évaluation seulement si LCP, INP et CLS sont tous bons.

La Search Console propose le rapport Core Web Vitals. Il regroupe les URL similaires, ne liste que les pages indexées, et attribue à chaque groupe le statut de sa pire métrique. Après une correction, le bouton de suivi lance une validation de 28 jours. Un site neuf peut afficher « aucune donnée » pendant quelques jours : ce n’est pas une erreur.

Étape 2 : corriger le LCP

Le LCP est le moment où le plus gros élément visible s’affiche, souvent la photo de la page d’accueil. L’article web.dev sur l’optimisation du LCP décompose ce délai en quatre parties : temps de réponse du serveur (environ 40 % du total visé), délai avant le début du chargement de la ressource (moins de 10 %), durée de chargement (environ 40 %) et délai d’affichage (moins de 10 %). Les deux délais doivent être proches de zéro.

Les gestes qui comptent

Priorité haute sur l’image principale avec l’attribut fetchpriority="high", limité à une ou deux images.
Aucun chargement différé sur cette image. web.dev est catégorique : ne jamais utiliser le lazy-loading sur l’image LCP, car cela crée un délai inutile.
Réduire le temps de réponse du serveur : peu de redirections, un cache de pages, et pas de paramètres d’URL uniques qui empêchent le CDN de servir une copie en cache.

<img src="/wp-content/uploads/accueil-1200.webp"
     width="1200" height="800"
     fetchpriority="high"
     alt="Façade du cabinet">

<!-- Les images sous la ligne de flottaison, elles, peuvent être différées -->
<img src="/wp-content/uploads/equipe.webp"
     width="600" height="400"
     loading="lazy"
     alt="L'équipe du cabinet">

Étape 3 : images en WebP ou AVIF

Selon web.dev, WebP et AVIF compressent généralement mieux que les formats plus anciens et fonctionnent dans tous les navigateurs modernes. La même page signale un compromis : ces formats avec perte peuvent modifier légèrement certaines couleurs, il faut donc comparer le rendu. Vous pouvez conserver un JPEG ou un PNG de secours. Dans WordPress, on convertit les images avant l’envoi ou à l’aide d’une extension, puis on vérifie les dimensions réelles : inutile de publier une image de 4 000 pixels pour un emplacement de 800.

Étape 4 : cache, PHP, extensions, CDN

La documentation officielle de WordPress sur l’optimisation des performances recommande plusieurs leviers : supprimer les extensions inutiles (en les désactivant une à une pour mesurer l’effet), utiliser un cache de pages, activer un cache d’opcode, tourner sur une version de PHP récente, déporter les fichiers statiques vers un CDN, minifier le CSS et le JavaScript, limiter les révisions d’articles et garder les options chargées automatiquement sous environ 800 Ko.

Ce travail relève de la maintenance de site web : mises à jour, nettoyage de base de données et suivi des performances dans la durée. Quand le thème lui-même est en cause, une refonte est parfois plus rentable que dix correctifs.

Étape 5 : stabiliser la mise en page (CLS) et la réactivité (INP)

web.dev liste les causes du CLS : images ou vidéos sans dimensions connues, polices dont la taille diffère de la police de secours, publicités ou widgets tiers qui se redimensionnent, contenu inséré au-dessus du contenu existant. Les remèdes en découlent : indiquer width et height sur les images (comme dans l’exemple ci-dessus), réserver l’espace des bannières et des widgets, et animer avec transform plutôt qu’avec top, left, width ou height.

Pour l’INP, qui doit rester sous 200 ms, la logique est la même que pour le LCP : moins de scripts, donc moins d’extensions et de widgets tiers (chat, vidéos intégrées, cartes). Testez la page avec et sans chaque script avant de décider de le garder.

Les erreurs que nous voyons le plus souvent

Au fil des audits, les mêmes pièges reviennent. Le premier est de se fier au seul score Lighthouse : il vient du laboratoire, et Google évalue les Core Web Vitals sur les données de vrais visiteurs. Le deuxième est d’empiler les extensions d’optimisation, qui ajoutent elles-mêmes du code à charger ; la documentation WordPress recommande au contraire de désactiver ce qui n’est pas indispensable. Le troisième est de mettre en chargement différé toutes les images, y compris la première, ce qui pénalise directement le LCP. Le quatrième est de corriger l’accueil et d’oublier les pages de service ou d’articles, alors que la Search Console regroupe les URL par modèle de page et note chaque groupe selon sa pire métrique.

Combien de temps avant de voir l’effet ?

Les données terrain couvrent une fenêtre glissante de 28 jours, aussi bien dans PageSpeed Insights que dans la validation de la Search Console. Une correction publiée aujourd’hui ne transformera donc pas le rapport demain : les anciennes mesures disparaissent progressivement. Pour juger rapidement, utilisez le test de laboratoire comme indicateur de direction, puis attendez la fin de la fenêtre pour confirmer. Si vous avez peu de trafic, Google peut ne pas disposer d’assez de données pour une page précise et se rabattre sur les données de l’ensemble du site, comme l’indique la documentation de PageSpeed Insights.

La checklist à imprimer

Relever LCP, INP et CLS terrain dans PageSpeed Insights et la Search Console.
Identifier l’élément LCP de chaque modèle de page (accueil, service, article).
Passer cette image en fetchpriority="high", sans lazy-loading.
Convertir les images en WebP ou AVIF, aux bonnes dimensions.
Renseigner width et height partout.
Activer un cache de pages et vérifier la version de PHP.
Désactiver les extensions inutiles, une par une, en mesurant.
Réserver l’espace des widgets tiers et des bannières.
Lancer la validation dans la Search Console et attendre la fin des 28 jours.

Le cas particulier des sites de santé

Un cabinet ou un centre d’imagerie a souvent des visiteurs qui consultent depuis leur téléphone, parfois avec une connexion moyenne, pour trouver une adresse ou prendre rendez-vous. C’est le cas où le mobile compte le plus, et où les écarts entre scores de laboratoire et données réelles se voient vite. Testez toujours la page de contact et la page de prise de rendez-vous, pas seulement l’accueil, et vérifiez que les modules externes (agenda en ligne, carte) ne dégradent ni la stabilité de la page ni sa réactivité. Si un module tiers est indispensable, réservez-lui sa place dans la mise en page et chargez-le après le contenu principal.

Conclusion

La vitesse se gagne par petites corrections mesurées, pas par une extension miracle. Notre équipe réalise ces audits sur des sites WordPress existants, et conçoit les nouveaux sites pour qu’ils respectent ces seuils dès la mise en ligne, notamment en création de site web. Pour un diagnostic de votre site, écrivez-nous ou consultez nos tarifs. Vous pouvez aussi voir ce que cela donne dans nos réalisations.

Accélérer un site WordPress : le guide Core Web Vitals pas à pas