Les Core Web Vitals en 2024 : ce qui a changé
Depuis mars 2024, Google a officialisé le remplacement du FID (First Input Delay) par l’INP (Interaction to Next Paint) comme métrique Core Web Vitals. Ce changement n’est pas anodin : là où le FID mesurait uniquement la latence du premier clic, l’INP mesure la réactivité de toutes les interactions tout au long de la session — clics, touches de clavier, tapotements sur mobile. Un changement de paradigme qui pénalise davantage les sites avec des interfaces JavaScript lourdes et des traitements synchrones coûteux. Les trois métriques à surveiller en 2024 sont donc : LCP (Largest Contentful Paint), INP (Interaction to Next Paint) et CLS (Cumulative Layout Shift).
LCP : optimiser le plus grand élément visible
Le LCP mesure le temps de rendu du plus grand élément visible dans le viewport au chargement. L’objectif est d’atteindre moins de 2,5 secondes. Sur WordPress, l’élément LCP est le plus souvent l’image hero de la page d’accueil ou une image en haut de page d’article. Les leviers d’optimisation sont multiples et cumulatifs.
Optimiser les images pour le LCP
Convertir toutes les images au format WebP ou AVIF réduit significativement leur poids sans perte de qualité perceptible. Ajouter l’attribut fetchpriority= »high » sur l’image LCP candidate indique explicitement au navigateur de la charger en priorité. Éviter le lazy loading sur les images above-the-fold — l’attribut loading= »lazy » est contre-productif sur les éléments visibles immédiatement. Enfin, précharger l’image LCP via une balise <link rel= »preload »> dans le head peut faire gagner plusieurs centaines de millisecondes.
Optimiser le TTFB pour le LCP
Le Time to First Byte impacte directement le LCP. Sur WordPress, le TTFB dépend de la qualité de l’hébergement, de la mise en cache serveur et de la complexité des requêtes en base de données. Un plugin de cache comme WP Rocket, LiteSpeed Cache ou W3 Total Cache bien configuré peut réduire le TTFB de plusieurs secondes sur les pages non mises en cache. L’activation du Full Page Cache est la première action à effectuer sur tout nouveau projet WordPress.
INP : réduire la latence de toutes les interactions
L’INP cible est inférieure à 200ms. Une valeur supérieure à 500ms est considérée comme mauvaise par Google. Sur WordPress, les coupables habituels sont les scripts JavaScript tiers — widgets de chat, scripts d’analytics, heatmaps, publicités — qui bloquent le thread principal et retardent le traitement des interactions utilisateur.
Identifier et corriger les problèmes INP
L’outil Chrome DevTools Performance est indispensable pour identifier les Long Tasks — les tâches JavaScript qui bloquent le thread principal plus de 50ms. La stratégie principale consiste à différer le chargement des scripts non critiques avec les attributs defer ou async, et à utiliser le chargement conditionnel pour ne charger les scripts que sur les pages qui en ont besoin. Sur WordPress, WP Rocket permet de configurer finement l’exclusion et le report des scripts par URL.
CLS : éliminer les décalages de mise en page
Le CLS mesure l’instabilité visuelle de la page — la somme des décalages de mise en page inattendus pendant le chargement. L’objectif est un score inférieur à 0,1. Les causes les plus fréquentes sur WordPress sont les images sans dimensions explicites, les publicités ou embeds qui se chargent tardivement et poussent le contenu vers le bas, et les polices Web qui provoquent un FOUT (Flash of Unstyled Text).
Corriger le CLS sur WordPress
Toujours définir des attributs width et height sur chaque balise img — WordPress le fait automatiquement depuis la version 5.5 mais les images insérées via des constructeurs de page peuvent échapper à cette règle. Réserver l’espace des publicités et embeds avec des conteneurs de hauteur fixe en CSS avant leur chargement. Utiliser font-display: swap ou font-display: optional dans les déclarations @font-face pour éviter les décalages liés aux polices Web.
Mesurer et suivre ses Core Web Vitals
Les outils de mesure sont complémentaires et ne doivent pas être confondus. Google Search Console fournit des données de terrain réelles (CrUX) agrégées sur 28 jours — c’est la source de vérité pour Google. PageSpeed Insights combine données de terrain et données de laboratoire pour un diagnostic instantané. Chrome DevTools et WebPageTest sont les outils de debug précis pour identifier les causes racines. Une bonne stratégie d’optimisation commence toujours par les données de terrain de la Search Console, pas par un score PageSpeed.
