Les Core Web Vitals sont devenus un critère de classement à part entière, et WordPress concentre à lui seul plus de 40 % des sites web dans le monde. Résultat : une part importante des problèmes de performance mesurés par Google provient de configurations WordPress mal maîtrisées. Les équipes techniques qui travaillent auprès de Geek Tonic, agence spécialisée WordPress, le constatent régulièrement lors d'audits : un thème chargé, trois greffons de cache qui se chevauchent et des images non optimisées suffisent à faire chuter le LCP au-delà des 4 secondes. Voici les causes les plus fréquentes et les leviers concrets pour repasser dans le vert.
LCP : identifier ce qui retarde réellement l'affichage principal
Le Largest Contentful Paint mesure le temps nécessaire pour afficher le plus grand élément visible du viewport. Sur WordPress, cet élément est presque toujours une image d'en-tête, un carrousel ou un bloc de titre. La cause racine est rarement le serveur : dans environ 70 % des cas observés, le coupable est une image non compressée ou chargée en lazy-load alors qu'elle se trouve au-dessus de la ligne de flottaison.
Trois actions corrigent la majorité des situations :
- Désactiver le lazy-load sur l'image héro : WordPress l'active par défaut depuis la version 5.5, ce qui retarde artificiellement le LCP de 300 à 800 ms.
- Convertir les visuels en WebP ou AVIF : le gain moyen sur le poids des images se situe entre 25 et 50 % par rapport au JPEG.
- Précharger la police et l'image critique via
rel="preload", en limitant le nombre de préchargements à deux ou trois pour ne pas saturer le réseau.
Un thème qui empile quatre polices Google Fonts différentes pèse souvent plus lourd que le contenu lui-même. Réduire à deux graisses maximum et héberger les fichiers localement fait gagner en moyenne 200 à 400 ms sur le first contentful paint.
INP : les greffons qui bloquent le fil principal
L'Interaction to Next Paint a remplacé le First Input Delay en mars 2024. Il mesure la réactivité de la page à chaque interaction : clic, appui clavier, tap. La valeur seuil est fixée à 200 ms. Sur WordPress, les scores INP médiocres viennent presque systématiquement de scripts tiers : chatbots, outils de heatmap, gestionnaires de consentement, sliders JavaScript.
Une analyse via l'onglet Performance de Chrome DevTools permet d'isoler les tâches longues supérieures à 50 ms. Les correctifs les plus efficaces :
- Charger les scripts non critiques après interaction ou au scroll, via
deferou un chargement conditionnel. - Limiter les greffons de page builder qui génèrent du JavaScript sur toutes les pages, même celles qui n'en ont pas besoin.
- Remplacer les sliders automatiques par des images statiques : un carrousel actif consomme 100 à 300 ms de traitement par interaction.
- Auditer les extensions de conformité : certaines ajoutent plus de 500 Ko de JavaScript pour un simple bandeau cookies.
Le piège des plugins de cache superposés
Empiler deux extensions de cache (une pour la page, une pour l'objet, une pour le CDN) produit fréquemment des conflits qui allongent le temps de réponse serveur au lieu de le réduire. Un seul plugin de cache page bien configuré, complété par un cache objet si le site utilise WooCommerce, suffit dans la grande majorité des cas. Le TTFB cible reste sous 600 ms.
CLS : les décalages de mise en page qui pénalisent la lecture
Le Cumulative Layout Shift mesure la stabilité visuelle. Le seuil recommandé est de 0,1. Sur WordPress, les sources de décalage sont bien identifiées :
| Source de CLS | Fréquence observée | Correction |
|---|---|---|
| Images sans dimensions width/height | Très fréquente | Déclarer les attributs ou utiliser aspect-ratio en CSS |
| Bannières publicitaires insérées dynamiquement | Fréquente | Réserver l'espace avec un conteneur de hauteur fixe |
| Polices web avec swap tardif | Fréquente | font-display: swap et préchargement |
| Blocs d'embed (YouTube, réseaux sociaux) | Moyenne | Placeholder avec ratio réservé |
Un décalage de 0,15 sur mobile suffit à faire passer l'URL en statut « à améliorer » dans la Search Console, avec un impact mesurable sur les positions dans les requêtes concurrentielles.
Mesurer avant d'optimiser : la méthode d'audit
Les données de terrain (CrUX) et les données de laboratoire (Lighthouse) ne racontent pas la même histoire. Un site peut afficher 95 sur Lighthouse et échouer sur le terrain à cause d'un hébergement lent ou d'un réseau mobile dégradé. La démarche rationnelle consiste à croiser trois sources :
- Le rapport Core Web Vitals de la Search Console, qui reflète l'expérience réelle des visiteurs sur 28 jours glissants.
- PageSpeed Insights, pour identifier les URL groupes concernés et les causes détaillées.
- Un outil de mesure terrain (RUM) installé sur le site, pour corréler les scores avec les conversions.
Il est conseillé de traiter d'abord les modèles de pages à fort trafic : accueil, catégories, articles les plus visités. Corriger le template d'un blog corrige mécaniquement des centaines d'URL. À l'inverse, optimiser une page de contact visitée dix fois par mois n'a aucun effet mesurable sur le référencement global.
Le coût réel d'une optimisation mal cadrée
Refondre entièrement un thème pour gagner 0,3 seconde de LCP représente souvent plusieurs semaines de développement. Dans la majorité des cas, compresser les images, supprimer deux greffons inutiles et activer un CDN suffit à passer sous les seuils. Une intervention ciblée sur les cinq modèles de pages les plus vus coûte généralement entre 1 500 et 4 000 euros selon la complexité du site, contre 10 000 à 30 000 euros pour une refonte complète.
Conclusion
Les Core Web Vitals ne se corrigent pas avec une extension miracle : ils se traitent par diagnostic. Images non optimisées, scripts tiers envahissants et mises en page instables expliquent l'essentiel des mauvais scores observés sur WordPress. Prioriser les templates à fort trafic, mesurer les effets sur 28 jours et éviter les refontes disproportionnées permet d'obtenir des résultats durables sans mobiliser des ressources excessives.
