CWV POUR WORDPRESS
Ce qui influence réellement les indicateurs LCP, INP et CLS sur un site WordPress réel, selon quelqu'un qui en a mis en ligne des milliers.
← Tous les guides Tous les guides de ce sujet
Les seuils, en bref
Trois indicateurs, mesurés au 75e centile des visiteurs réels : un LCP inférieur à 2,5 secondes, un INP inférieur à 200 millisecondes et un CLS inférieur à 0,1. Google tire ces données des informations de terrain issues du « Chrome User Experience Report », et non de vos tests Lighthouse ; un score « vert » en environnement de laboratoire est donc nécessaire, mais pas suffisant.
Point clé : WordPress peut satisfaire aux critères des Core Web Vitals, mais ses paramètres par défaut vous mettent des bâtons dans les roues : thèmes lourds, prolifération des plugins et fichiers multimédias non optimisés. Commencez par optimiser les fichiers multimédias et la mise en cache, réduisez ensuite le nombre de plugins, puis vérifiez les résultats à l'aide de données de terrain, et non de scores obtenus en laboratoire.
Pourquoi WordPress obtient de mauvais résultats par défaut
- Thèmes lourds et éditeurs de pages. Les thèmes polyvalents et les éditeurs tels qu’Elementor et Divi intègrent d’importants fichiers CSS et JavaScript, dont une grande partie reste inutilisée sur une page donnée.
- Prolifération des plugins. Chaque plugin actif peut ajouter ses propres scripts et feuilles de style à l'ensemble du site, même sur des pages qui ne l'utilisent jamais.
- Fichiers multimédias non optimisés. La médiathèque diffuse tels quels les fichiers qui y ont été mis en ligne. Les grandes images d'en-tête, sans format WebP et sans redimensionnement, sont la principale cause de LCP.
- Aucune mise en cache par défaut. Une installation WordPress standard exécute le code PHP à chaque requête. Sans mise en cache des pages, le temps de réponse jusqu'au premier octet se détériore en cas de forte charge.
Les corrections qui font vraiment la différence
Par ordre d'importance : activez la mise en cache des pages et utilisez un CDN ; optimisez et redimensionnez correctement les images (format WebP, chargement différé sous le pli) ; réduisez le code JavaScript du thème et des plugins que vous intégrez ; et hébergez votre site sur une infrastructure qui garantit un temps de réponse « time to first byte » (TTFB) faible. Un bon [hébergeur géré ou VPS](/blog/best-vps-for-wordpress-2026/) contribue davantage au TTFB que n'importe quel plugin. Si votre site est suffisamment lourd pour que rien de tout cela ne suffise, c'est le moment d'envisager [WordPress Headless avec Astro](/blog/headless-wordpress-astro-setup/), qui supprime entièrement le poids du front-end.
Pour une approche pratique de cette question, consultez ma page [Optimisation de la vitesse de WordPress](/wordpress-speed-optimization/) ; pour une liste indépendante de la plateforme, consultez la [liste de contrôle Core Web Vitals](/guides/cwv-checklist/).
Erreurs courantes sur WordPress
- Installation de trois plugins de mise en cache. Ils entrent en conflit. Choisissez un seul plugin de mise en cache de pages (ou un hébergeur proposant une mise en cache intégrée) et arrêtez-vous là.
- Optimiser les images manuellement, une seule fois. Les nouveaux fichiers mis en ligne annulent cette optimisation. Utilisez un plugin ou un pipeline qui convertit les images au format WebP et les redimensionne à chaque mise en ligne.
- À la poursuite des 100 dans Lighthouse. C'est un outil d'expérimentation. Ce sont le rapport de la Search Console et les données de terrain qui déterminent votre classement.
- Ajouter un plugin de performance sans s'attaquer à la cause du problème. Utiliser un minificateur en plus d'un générateur de code trop lourd n'est qu'un palliatif, pas une solution. Commencez par alléger le code.
Mesurez comme le fait Google
N'installez aucun outil qui se contente de fournir des scores issus de tests en laboratoire. Utilisez la section « sur le terrain » de PageSpeed Insights et le rapport « Core Web Vitals » de Search Console, qui s'appuient tous deux sur des données réelles provenant des utilisateurs. Après la mise en place d'une correction, il faut compter environ 28 jours pour que les données sur le terrain reflètent pleinement le changement ; ne paniquez donc pas si le score ne bouge pas dès le lendemain matin. Suivez la tendance sur plusieurs semaines, plutôt que le chiffre d'un jour donné, et ne considérez la correction comme effective qu'une fois que les données sur le terrain l'ont confirmée.