Pourquoi votre tableau Search Console affiche-t-il encore une majorité d’URL « À améliorer » alors qu’un plugin de cache tourne depuis des mois ? Un cache agit surtout sur le LCP ; il laisse le CLS et l’INP largement intacts. Après une chute de trafic sur une mise à jour de mars, la checklist habituelle (qualité éditoriale et maillage interne) laisse souvent de côté l’onglet Vitesse, faute de piste claire sur quoi régler en premier.
12 réglages permettent de couvrir les trois métriques Core Web Vitals sur un site WordPress standard. Hébergement et cache absorbent l’essentiel du LCP. Le JavaScript différé fait tomber l’INP. Les dimensions d’image et les polices verrouillent le CLS. Chaque réglage cible une métrique précise ; aucun ne couvre les trois en même temps.
Pourquoi WordPress traîne sur les Core Web Vitals
On dit souvent qu’installer WP Rocket ou LiteSpeed Cache suffit à passer au vert. Les chiffres de l’HTTP Archive publiés en avril 2026 racontent une autre histoire : sur 7 CMS comparés, WordPress arrive dernier avec environ 49 % de sites en bon score Core Web Vitals, loin derrière Shopify (79 %), Wix (80 %) et Duda (85 %) et même derrière Drupal (64 %) et Joomla (58 %), selon l’analyse publiée par Search Engine Journal en mai 2026.
Le rapport combine les données de terrain du Chrome UX Report avec les technologies détectées par HTTP Archive et montre que le poids de page ou le score Lighthouse ne prédisent pas toujours le résultat Core Web Vitals réel d’un site.
La cause n’est pas identique pour les trois métriques. Le tableau ci-dessous relie chaque métrique à son seuil officiel et à la cause la plus fréquente observée sur les installations WordPress.
| Métrique | Seuil « Bon » (Google) | Cause fréquente sur WordPress | Réglage prioritaire |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2,5 s | TTFB élevé (hébergement mutualisé, PHP obsolète) et image principale non préchargée | Cache serveur + preload de l’image LCP |
| INP (Interaction to Next Paint) | ≤ 200 ms | Scripts tiers non différés (chat, pixels publicitaires, popups) | Délai d’exécution JavaScript |
| CLS (Cumulative Layout Shift) | ≤ 0,1 | Images sans largeur ni hauteur, polices web sans font-display | Dimensions explicites + font-display: swap |
L’INP a remplacé le FID comme métrique officielle le 12 mars 2024, d’après la documentation Google Search Central : il mesure la réactivité de la page sur l’ensemble de ses interactions, du premier clic au dernier. Une page lente pénalise aussi l’exploration : un thème qui consomme son rendering budget sur du JavaScript non essentiel retarde la deuxième vague d’indexation, celle qui traite le contenu généré côté client. NavBoost, le système qui agrège les signaux de clic et d’engagement, capte l’effet indirect : un LCP au-dessus de 4 secondes fait grimper le taux d’abandon avant même que le contenu ne s’affiche.
Les 12 réglages, en un coup d’œil
Chaque réglage cible une métrique précise, listée ci-dessous avant le détail de mise en œuvre :
- Passer le serveur en PHP 8.3 ou plus récent (agit sur le LCP et le TTFB).
- Configurer un plugin de cache complet, page cache et cache navigateur activés (LCP).
- Convertir les images en WebP ou AVIF automatiquement à l’upload (LCP).
- Précharger l’image LCP avec fetchpriority= »high » et l’exclure du lazy loading (LCP).
- Activer la compression Brotli et le protocole HTTP/3 côté hébergeur (LCP, TTFB).
- Retarder l’exécution du JavaScript non critique via Delay JS (INP).
- Supprimer ou charger en différé les scripts tiers non indispensables (INP).
- Activer un cache objet Redis ou Memcached si l’hébergeur le propose (TTFB).
- Nettoyer les révisions d’articles et les transients expirés en base de données (TTFB).
- Espacer l’intervalle du Heartbeat API de 15 à 60 secondes (TTFB, charge serveur).
- Définir width et height explicites sur chaque image et vidéo intégrée (CLS).
- Charger les polices avec font-display: swap et réserver l’espace publicitaire (CLS).
Réduire le LCP : hébergement, cache et image principale
Le LCP dépend à parts égales du serveur et du navigateur. Sur un hébergement mutualisé avec PHP 7.4, le TTFB dépasse souvent 800 ms avant même le premier octet de HTML. Sur un VPS avec PHP 8.3 et un cache objet, il tombe sous 200 ms.
Vérifiez d’abord la version PHP depuis l’espace client de l’hébergeur (Outils > PHP sur OVH, Site Tools > PHP Configuration chez SiteGround) et passez en 8.3 minimum. Le cœur de WordPress ainsi que la majorité des thèmes et plugins maintenus la supportent depuis 2024.
Installez ensuite un plugin de cache complet, par exemple WP Rocket ou LiteSpeed Cache, puis activez le cache de page ainsi que le cache navigateur. Les deux solutions réduisent nettement le LCP par rapport à un site sans cache : LiteSpeed Cache tire parti du couple serveur LiteSpeed et de l’accélération QUIC.cloud quand l’hébergeur le propose, tandis que WP Rocket reste la valeur sûre sur les hébergements mutualisés classiques.
Convertissez les images au format WebP ou AVIF à l’upload (option native dans WP Rocket et LiteSpeed Cache ou via le plugin Imagify) et ajoutez un attribut fetchpriority= »high » sur l’image mise en avant. Elle doit rester exclue du lazy loading : une image LCP chargée en différé attend le scroll ou l’exécution du script avant de s’afficher, ce qui ajoute un délai évitable.
Terminez par la compression au niveau serveur. Activez Brotli (souvent une case à cocher dans le panneau d’hébergement ou via Cloudflare > Speed > Optimization) et vérifiez que le protocole HTTP/3 est actif sur le certificat SSL. Ces deux réglages ne changent rien à l’affichage mais réduisent le temps de transfert des fichiers CSS et JS.
Faire tomber l’INP : dompter le JavaScript tiers
L’INP mesure le délai entre un clic et le rendu visuel qui suit, tout au long de la visite et bien après le chargement initial. Sur WordPress, le coupable est presque toujours le même : des scripts tiers, chat en direct, pixel publicitaire ou parfois un popup d’exit-intent, qui bloquent le thread principal du navigateur.
Activez la fonction Delay JavaScript Execution de WP Rocket ou son équivalent dans Perfmatters (onglet JavaScript > Delay JS), qui repousse l’exécution des scripts non essentiels jusqu’à la première interaction de l’utilisateur. Passez ensuite en revue chaque script tiers via l’onglet Réseau des outils de développement Chrome (touche F12, filtre JS) : un widget de chat qui charge 400 Ko de JavaScript sur une page de blog qui n’en a pas besoin peut être limité aux pages de contact.
Le Delay JS agressif peut casser un formulaire ou un menu qui dépend d’un script différé trop tard. Testez systématiquement les pages critiques après activation : panier, formulaire de contact, en plus de la page d’accueil.
Pourquoi une page « déjà chargée » continue-t-elle à bouger sous les yeux ?
Le CLS mesure le déplacement cumulé des éléments visibles pendant le chargement. Sur WordPress, 2 causes reviennent dans la quasi-totalité des audits : des images sans dimension déclarée et des polices web qui remplacent la police système une fois affichées.
Ajoutez systématiquement les attributs width et height sur chaque balise img, y compris pour les images intégrées dans le contenu. WordPress les ajoute automatiquement depuis la version 5.5 pour les fichiers de la médiathèque mais pas pour une image collée depuis une URL externe. Pour les polices Google Fonts ou personnalisées, ajoutez la propriété font-display: swap dans le CSS d’enqueue ou activez l’option correspondante dans l’onglet Fichiers de WP Rocket.
Réservez également l’espace des blocs publicitaires et des iframes (vidéo YouTube, formulaire embarqué) avec un conteneur de taille fixe défini en CSS avant le chargement du script. Un bandeau publicitaire qui s’insère après 2 secondes de lecture pousse tout le contenu vers le bas et compte dans le CLS, même si la page paraissait déjà stable à l’œil.
Nettoyer le serveur : ce qui joue sur toutes les métriques à la fois
3 réglages serveur agissent sur l’ensemble des métriques Core Web Vitals en même temps, parce qu’ils réduisent la charge sur les workers PHP partagés par tous les visiteurs.
Activez le cache objet si l’hébergeur le propose (Redis ou Memcached, souvent une option à cocher dans l’espace technique ou le plugin Redis Object Cache) : les requêtes à la base de données répétées à chaque chargement de page passent en mémoire, ce qui abaisse le TTFB.
Nettoyez ensuite la base de données. Les révisions d’articles et les transients expirés s’accumulent silencieusement : un site actif depuis plusieurs années peut compter des dizaines de milliers de lignes inutiles dans wp_options. WP-Optimize ou Advanced Database Cleaner suppriment ces entrées en quelques clics, à programmer une fois par mois.
Limitez enfin le Heartbeat API. Par défaut, WordPress envoie une requête à admin-ajax.php toutes les 15 secondes pour chaque utilisateur connecté au back-office et chaque pulse occupe un worker PHP qui ne sert plus les visiteurs du site pendant ce temps, comme le détaille Delicious Brains. Passez l’intervalle à 60 secondes via l’onglet Heartbeat de WP Rocket ou désactivez-le complètement sur le front-end si aucun plugin n’en dépend.
Pièges courants observés sur les audits WordPress
Un plugin de cache agressif peut-il dégrader l’INP ? Oui, quand l’option de minification combine plusieurs scripts en un seul fichier chargé de façon synchrone : le navigateur attend ce bloc monolithique avant de rendre la page interactive. Désactivez l’option « Combine JS files » si l’INP se dégrade après configuration du cache, elle apporte peu depuis la généralisation de HTTP/2.
Le score PageSpeed Insights reste rouge malgré tous ces réglages ? Vérifiez la donnée de terrain (CrUX, en bas du rapport) plutôt que le score de laboratoire affiché en premier. PageSpeed simule une connexion mobile ralentie sur un appareil milieu de gamme, ce qui pénalise davantage un thème lourd que les visites réelles depuis un ordinateur de bureau.
Vérifier que les réglages ont porté leurs fruits
Attendez au moins 28 jours avant de tirer une conclusion depuis le rapport Core Web Vitals de Search Console : les données de terrain CrUX se basent sur une fenêtre glissante de 28 jours de visites réelles, largement antérieures au dernier déploiement. Comme pour les autres alertes de Search Console, mieux vaut vérifier la tendance réelle avant de rouvrir un ticket à chaque URL passée en rouge. Pour un retour plus rapide, lancez un test PageSpeed Insights sur les pages qui reçoivent le plus de trafic (accueil, catégorie principale, article le mieux positionné) et comparez le score avant et après sur ces mêmes URL.
Un site rapide ne garantit rien de plus. Il retire juste une excuse.
