En août 2026, moins d’un site WordPress sur deux passait les Core Web Vitals sur mobile, selon les données du Chrome UX Report compilées par HTTP Archive. L’ensemble du web faisait un peu mieux. Et surtout, sur mobile, seul un site WordPress sur quatre environ répondait assez vite au premier octet, contre près d’un site sur deux pour l’ensemble du web.
Ce chiffre dit où se trouve le problème. WordPress n’est pas lent à réagir aux clics : sur ce terrain, il fait mieux que la moyenne. Il est lent à charger, d’abord côté serveur, puis sur l’image principale de la page. Les correctifs qui suivent sont classés dans cet ordre.
Notre sélection de plugins de vitesse existe déjà ; cette liste réunit des correctifs, chacun relié à la métrique qu’il améliore, à ce que WordPress fait déjà par lui-même, et à la façon de vérifier le résultat.
Les trois seuils et ce que Google en fait
Les Core Web Vitals sont trois mesures de l’expérience réelle des visiteurs. Le LCP (Largest Contentful Paint) mesure le temps d’affichage du plus grand élément visible : bon sous 2,5 secondes, mauvais au-delà de 4. L’INP (Interaction to Next Paint) mesure la réactivité aux clics et aux saisies : bon sous 200 millisecondes, mauvais au-delà de 500. Le CLS (Cumulative Layout Shift) mesure les sauts de mise en page : bon sous 0,1, mauvais au-delà de 0,25.
Ces seuils s’appliquent au 75e centile des visites, séparément sur mobile et sur ordinateur. L’INP a remplacé le FID le 12 mars 2024 : un article qui parle encore du FID est dépassé.
Google confirme que ses systèmes de classement utilisent ces mesures, mais précise qu’il n’existe pas de signal unique d’expérience de page et qu’il montrera toujours le contenu le plus pertinent, même si l’expérience de page est médiocre. Les Core Web Vitals servent surtout à départager des pages de pertinence comparable.
Comment nous les avons classés
Les données de terrain d’août 2026 montrent que les sites WordPress réussissent sur mobile mieux que la moyenne du web sur l’INP et le CLS, mais nettement moins bien sur le temps de réponse du serveur et sur le LCP. Nous commençons donc par le serveur et l’image principale, puis passons aux ressources, aux polices, à la stabilité et à la réactivité.
Le dernier porte sur la mesure, sans laquelle aucun des neuf autres ne peut être confirmé.
1. Un cache de page pour réduire le temps de réponse
Pourquoi c’est important
Le TTFB (Time to First Byte), le temps avant le premier octet de la réponse, n’est pas une Core Web Vital. Mais il consomme le budget du LCP : tant que le serveur n’a pas répondu, rien ne s’affiche. Google considère comme bon un TTFB inférieur à 0,8 seconde. C’est la principale faiblesse des sites WordPress, qui génèrent chaque page à la demande en PHP.
Comment faire
Un cache de page, au niveau du serveur ou d’un CDN, sert aux visiteurs anonymes une version déjà calculée de la page. Pour ce qui ne peut pas être mis en cache, l’administration, le panier ou les comptes clients, un cache objet persistant réduit le travail de la base de données. La qualité de votre hébergement WordPress fixe toutefois la limite de ce que le cache peut gagner.
Comment vérifier
Depuis WordPress 6.1, la Santé du site teste la présence d’un cache de page et compare le temps de réponse du serveur à un seuil de 600 millisecondes. Ce test n’apparaît que sur un site déclaré en environnement de production. Les en-têtes de réponse indiquent aussi si une page vient du cache. Le TTFB de terrain apparaît dans PageSpeed Insights.
2. Faire découvrir et prioriser l’image LCP
Pourquoi c’est important
Sur la plupart des pages, l’élément LCP est une image : la photo d’en-tête, la bannière, l’image à la une. Google observe qu’une part importante de ces images n’est pas découvrable dans le HTML initial, parce qu’elles sont chargées par JavaScript ou déclarées en arrière-plan CSS. Le navigateur les découvre trop tard.
Comment faire
Depuis WordPress 6.3, le cœur ajoute fetchpriority="high" à l’image qu’il juge la plus susceptible d’être l’élément LCP, à condition qu’elle mesure au moins 50 000 pixels carrés. Mais l’équipe performance a reconnu en 2023 que cette estimation ne tombait juste qu’environ une fois sur deux. Vérifiez votre modèle : dans un thème sur mesure, passez l’attribut explicitement.
echo wp_get_attachment_image( $image_id, 'full', false, array( 'fetchpriority' => 'high' ) );Pour une image d’arrière-plan CSS, que le navigateur ne voit pas dans le HTML, un préchargement avec priorité haute s’impose. Le filtre wp_preload_resources permet ce préchargement depuis WordPress 6.1, et la priorité haute, via la clé fetchpriority, depuis la 6.6. Le plugin Image Prioritizer de l’équipe performance va plus loin, en choisissant l’image à prioriser selon les données de vrais visiteurs, mais il est encore en version bêta et dépend du plugin Optimization Detective, qui collecte ces données.
Comment vérifier
PageSpeed Insights identifie l’élément LCP et signale s’il est découvert tardivement. Dans les outils de développement, la colonne de priorité de l’onglet Réseau indique si l’image est bien chargée en priorité haute.
3. Le chargement différé au bon endroit, jamais sur l’image LCP
Pourquoi c’est important
Le chargement différé, ou lazy loading, retarde les images situées sous la ligne de flottaison. Appliqué à l’image principale, il fait l’inverse de l’effet recherché : le navigateur attend de savoir si l’image est visible avant de la demander. Selon le Web Almanac 2025, environ une page sur six commet encore cette erreur.
Comment faire
WordPress exclut par défaut du chargement différé les trois premiers éléments médias du contenu, images ou iframes. Le risque vient surtout des thèmes, des constructeurs de pages et des plugins d’optimisation qui ajoutent leur propre chargement différé, soit avec l’attribut natif loading="lazy", soit en JavaScript avec des attributs comme data-src. Sur l’ensemble du web, l’attribut natif est d’ailleurs la cause la plus fréquente. Excluez-en l’image d’en-tête et, dans vos modèles, passez 'loading' => false à la fonction d’affichage de l’image.
Comment vérifier
Affichez le code source et cherchez l’attribut loading="lazy" sur l’image principale. PageSpeed Insights signale explicitement une image LCP chargée en différé.
Le cas réel : quand WordPress a dû corriger son propre chargement différé
L’histoire la plus instructive sur les Core Web Vitals de WordPress est celle d’une optimisation devenue un frein, puis corrigée grâce aux données de terrain. Elle est documentée pas à pas par Felix Arntz, puis par l’équipe performance du projet, sur le blog officiel des développeurs.
Une bonne idée appliquée partout
Le 11 août 2020, WordPress 5.5 active le chargement différé natif sur toutes les images qui ont une largeur et une hauteur. L’intention est bonne : économiser la bande passante sur les images que le visiteur ne verra peut-être jamais. Les iframes suivent avec WordPress 5.7, en mars 2021.
La mesure qui contredit le réglage
En juillet 2021, Felix Arntz, alors ingénieur chez Google, qui cofondera quelques mois plus tard l’équipe performance de WordPress, teste les 50 thèmes les plus populaires dans 200 scénarios. Le résultat est net : différer le chargement de la première image du contenu dégrade le LCP. Sans ce chargement différé, le LCP médian s’améliore d’environ 7 %, pour un poids d’images identique. Il propose de ne plus différer la première image, ce que fait WordPress 5.9 en janvier 2022.
De l’exclusion à la priorité
En 2023, l’équipe pousse la logique plus loin : puisque le cœur sait quelle image ne pas différer, il peut aussi la marquer comme prioritaire. WordPress 6.3, le 8 août 2023, ajoute fetchpriority="high" à l’image LCP présumée, porte à trois le nombre d’images exclues du chargement différé et corrige les images d’en-tête des thèmes classiques.
La validation sur 500 000 sites
En septembre 2023, l’équipe compare dans HTTP Archive et le Chrome UX Report plus de 500 000 pages d’accueil WordPress, avant et après la mise à jour. Le taux de réussite du LCP sur mobile progresse, et les sites qui ont cessé de différer leur image LCP tout en lui donnant la bonne priorité gagnent nettement plus que les autres. La part des sites qui différaient leur image LCP chute fortement.
L’équipe publie aussi ses limites : l’image priorisée n’est la bonne qu’environ une fois sur deux, et la part de sites au TTFB satisfaisant sur ordinateur a reculé d’environ 5 % pour les thèmes classiques et 9 % pour les thèmes de blocs. En fin d’année, elle estime que la version 6.3 a été la plus utile de 2023 pour le LCP mobile des sites WordPress.
Ce qu’il faut en retenir
Une optimisation appliquée sans regarder la page peut ralentir son élément le plus important. La correction est venue des données de terrain, pas d’un score de laboratoire. Et même les règles du cœur ne voient pas tout : un en-tête en arrière-plan CSS ou un diaporama en JavaScript leur échappe. Les deux attributs loading et fetchpriority de votre image principale restent la première chose à vérifier.
4. Formats modernes et images à la bonne taille
Pourquoi c’est important
Une image LCP plus légère arrive plus vite. WordPress accepte le WebP depuis la version 5.8, et l’AVIF depuis la 6.5. Selon les notes de développement officielles de WordPress, un WebP est en moyenne environ 30 % plus léger qu’un JPEG ou un PNG équivalent, et un AVIF jusqu’à 50 % plus léger qu’un JPEG à qualité égale. Pourtant, la grande majorité des images LCP du web restent en JPEG ou en PNG.
Comment faire
Point souvent mal compris : WordPress ne convertit pas vos JPEG en WebP ou en AVIF. Il accepte ces formats à l’envoi, c’est tout. La conversion passe par le filtre image_editor_output_format ou par un plugin. Le module Modern Image Formats de l’équipe performance génère de l’AVIF si le serveur le permet, sinon du WebP, pour les nouveaux envois. Notre comparatif des plugins d’optimisation d’images présente les autres options.
Comment vérifier
Dans l’onglet d’informations de la Santé du site, la rubrique sur la gestion des médias indique si votre serveur sait produire de l’AVIF. Dans l’onglet Réseau, le type de contenu de l’image LCP doit être image/avif ou image/webp. Les images déjà en ligne doivent être régénérées.
5. Retirer le CSS et le JavaScript inutiles
Pourquoi c’est important
Chaque feuille de style et chaque script bloquant retarde l’affichage. Sur un site WordPress, beaucoup de ces fichiers viennent de plugins qui chargent leurs ressources sur toutes les pages, même là où ils ne servent à rien : diaporamas, formulaires, boutons de partage.
Comment faire
WordPress a beaucoup progressé. Depuis la version 6.3, un script peut être chargé en defer ou async. Depuis la 6.9, les thèmes classiques ne chargent plus que les styles des blocs réellement présents sur la page, et les ressources des blocs masqués sont omises.
Selon le guide de la version 6.9, la page d’exemple des thèmes livrés avec WordPress embarque en moyenne 45 % de CSS en moins, une mesure de laboratoire. En contrepartie, le même guide prévient que la mise en mémoire tampon qui rend ce tri possible dégrade un peu le TTFB des thèmes classiques.
Côté propriétaire de site, faites l’inventaire des plugins qui chargent des ressources partout, et retirez-les des pages qui n’en ont pas besoin. Les fonctions de suppression du CSS inutilisé des plugins d’optimisation sont efficaces mais délicates : testez-les sur une copie, car elles cassent volontiers les menus et les fenêtres modales.
Comment vérifier
L’onglet Coverage des outils de développement de Chrome montre la part de code inutilisée. PageSpeed Insights liste les requêtes bloquantes et le JavaScript inutilisé.
6. Polices et font-display
Pourquoi c’est important
Une police web qui arrive en retard retarde le texte, ou le fait sauter au moment où elle remplace la police de secours. Le premier cas pèse sur le LCP quand l’élément principal est un titre, le second sur le CLS.
Comment faire
Limitez le nombre de familles et de graisses, hébergez les fichiers WOFF2 sur votre serveur et préchargez uniquement la police du texte principal. Depuis WordPress 6.5, la bibliothèque de polices télécharge les Google Fonts sur votre serveur au lieu de les appeler chez Google. Les polices déclarées dans le fichier theme.json utilisent par défaut font-display: fallback, un compromis raisonnable que vous pouvez modifier.
Pour supprimer le saut au remplacement, ajustez les dimensions de la police de secours avec size-adjust, comme le recommande Google, ou passez à font-display: optional si l’identité typographique n’est pas critique.
Comment vérifier
L’onglet Réseau montre le nombre de fichiers de police et leur priorité. Le panneau Performance signale les décalages de mise en page au moment du remplacement.
7. CLS : dimensions, publicités et contenus intégrés
Pourquoi c’est important
Un texte qui saute au moment où l’on va cliquer est la frustration que mesure le CLS. Les causes classiques sont connues : images sans dimensions, publicités et contenus intégrés qui se redimensionnent, bandeaux injectés en haut de page. Le CLS n’est pas la principale faiblesse de WordPress sur mobile, mais il reste plus fragile sur ordinateur.
Comment faire
Depuis la version 5.5, WordPress ajoute automatiquement largeur et hauteur aux images de la médiathèque insérées dans le contenu. Pour le reste, réservez l’espace : une hauteur minimale fixe pour les emplacements publicitaires, un ratio pour les vidéos intégrées, une bannière de cookies en superposition plutôt qu’en tête de page. Le plugin Embed Optimizer de l’équipe performance, encore en bêta, réserve aussi l’espace des contenus intégrés, à condition d’être associé au plugin Optimization Detective.
Comment vérifier
PageSpeed Insights liste les éléments responsables des décalages. Attention : un test de laboratoire ne voit pas les sauts qui surviennent après un défilement ou une interaction, que le CLS de terrain mesure pendant toute la visite.
8. INP : tâches longues et scripts tiers
Pourquoi c’est important
L’INP mesure le délai entre une action du visiteur et l’affichage de sa conséquence. Il se dégrade quand le navigateur est occupé par des tâches longues, de plus de 50 millisecondes, souvent dues à des scripts tiers : gestionnaires de balises, outils de discussion, publicités, filtres de boutique. En moyenne, WordPress s’en sort bien sur cette mesure, mais un site chargé de scripts peut échouer gravement.
Comment faire
Faites l’inventaire des scripts tiers, retirez les doublons, comme deux outils de statistiques ou des pixels publicitaires oubliés, et différez les scripts non essentiels jusqu’à la première interaction. Dans votre propre code, découpez les traitements lourds pour rendre la main au navigateur.
Le cas publié sur web.dev en janvier 2025 par des ingénieurs de QuintoAndar montre l’ampleur possible : cette plateforme immobilière brésilienne a réduit son INP de 80 % en une dizaine de mois, en 2024, en sortant ses pixels tiers du navigateur et en découpant ses tâches. Le site n’utilise pas WordPress, mais la méthode s’y transpose. Évitez en revanche le plugin Web Worker Offloading de l’équipe performance : sa propre page le dit expérimental et destiné à être abandonné.
Comment vérifier
L’INP ne se mesure vraiment que sur le terrain, avec les données du Chrome UX Report ou un outil de mesure des visiteurs réels. En laboratoire, Lighthouse utilise le temps de blocage total comme indicateur approché, qui ne capte pas les clics réels.
9. Chargement spéculatif et cache amélioré
Pourquoi c’est important
Ces deux techniques n’accélèrent pas la première page, mais rendent les suivantes presque instantanées. Le chargement spéculatif précharge la page qu’un visiteur s’apprête à ouvrir. Le cache amélioré (back/forward cache, ou bfcache), restitue immédiatement une page quand on utilise les boutons précédent et suivant, ce qui concerne une navigation sur dix sur ordinateur et une sur cinq sur mobile, selon Google.
Comment faire
Depuis WordPress 6.8, le cœur ajoute des règles de chargement spéculatif pour les visiteurs non connectés, sur les sites aux permaliens lisibles : un préchargement prudent, déclenché quand le visiteur commence à cliquer. WordPress 7.1 permet à un site ou à un hébergeur de changer ce réglage par défaut avec deux constantes, WP_SPECULATIVE_LOADING_DEFAULT_MODE et WP_SPECULATIVE_LOADING_DEFAULT_EAGERNESS. Le passage automatique à un déclenchement plus précoce (moderate) sur les sites dotés d’un cache de page et d’un cache objet, prévu dans la feuille de route de la 7.1, n’a pas été livré.
Pour aller plus loin sans code, le plugin Speculative Loading de l’équipe performance active par défaut un pré-rendu modéré. Pour désactiver la fonction du cœur, un filtre suffit :
add_filter( 'wp_speculation_rules_configuration', '__return_null' );Côté bfcache, WordPress envoie un en-tête no-store aux utilisateurs connectés, qui empêche historiquement cette mise en cache. La correction dans le cœur reste en attente ; le plugin Instant Back/Forward propose une solution en attendant.
Comment vérifier
Dans les outils de développement de Chrome, l’onglet Application montre les chargements spéculatifs et propose un test du cache amélioré. Déconnecté, ou en navigation privée, le code source doit contenir un bloc <script type="speculationrules">. Le chargement spéculatif ne fonctionne que dans les navigateurs basés sur Chromium. Le bfcache, lui, existe dans tous les navigateurs majeurs, Safari et Firefox compris.
10. Mesurer avec les données de terrain
Pourquoi c’est important
Un score de 100 dans Lighthouse ne signifie pas que vous passez les Core Web Vitals. Lighthouse est un test de laboratoire, sur un appareil simulé et un réseau unique. Google se fonde sur les données de terrain du Chrome UX Report, au 75e centile, sur les 28 derniers jours. Les deux peuvent diverger fortement, surtout pour l’INP, que le laboratoire ne mesure pas.
Comment faire
Dans la Search Console, le rapport Core Web Vitals regroupe les adresses semblables et classe chaque groupe selon sa plus mauvaise mesure. Après une correction, lancez une validation : elle suit l’évolution pendant 28 jours. PageSpeed Insights affiche les données de terrain en haut de page, et les résultats de laboratoire en dessous. Notre sélection de plugins de vitesse WordPress aide ensuite à appliquer les correctifs.
Les limites de la mesure
Le Chrome UX Report ne collecte que des données de Chrome sur ordinateur et Android : les visiteurs sur iPhone n’y figurent pas. Un site peu fréquenté peut n’avoir aucune donnée. Et la définition des mesures évolue avec les versions de Chrome, si bien qu’un score peut bouger sans que le site ait changé.
Par où commencer
Ouvrez le rapport Core Web Vitals de la Search Console, identifiez la mesure qui fait échouer vos groupes d’adresses, puis remontez au correctif correspondant. Un LCP lent renvoie aux correctifs 1 à 6, un CLS élevé aux correctifs 6 et 7, un INP médiocre aux correctifs 5 et 8.
Pour un site WordPress typique, l’ordre le plus rentable est presque toujours le même : un cache de page, puis l’image principale, puis le tri des scripts. Pour les pages que le cache ne peut pas servir, comme le panier ou l’espace client, un cache objet Redis prend le relais.
Tableau récapitulatif
| Correctif | Mesure | Ce que fait WordPress | Comment vérifier |
|---|---|---|---|
| Cache de page | TTFB, LCP | Test dans la Santé du site (6.1) | En-têtes, TTFB de terrain |
| Priorité de l’image LCP | LCP | fetchpriority automatique (6.3) | Colonne de priorité réseau |
| Chargement différé | LCP | Trois premières images exclues (6.3) | Code source de l’en-tête |
| WebP et AVIF | LCP | Formats acceptés, pas de conversion | Type de contenu de l’image |
| CSS et JS inutiles | LCP, INP | defer et async (6.3), styles à la demande (6.9) | Onglet Coverage |
| Polices | LCP, CLS | Polices hébergées localement (6.5) | Onglet Réseau |
| Dimensions et espaces réservés | CLS | Largeur et hauteur ajoutées (5.5) | Éléments responsables dans PageSpeed |
| Scripts tiers | INP | Rien, c’est à vous | Données de terrain uniquement |
| Chargement spéculatif | LCP des pages suivantes | Préchargement prudent (6.8) | Onglet Application |
| Mesure de terrain | Les trois | Sans objet | Search Console, 28 jours |
Questions fréquentes
Les Core Web Vitals influencent-ils le classement dans Google ?
Oui, mais sans primer sur la pertinence. Google les utilise dans ses systèmes de classement, tout en précisant que la pertinence du contenu passe avant et qu’un bon score ne garantit pas une bonne position. Ils comptent surtout entre des pages de pertinence comparable.
Pourquoi PageSpeed est-il vert et la Search Console rouge ?
Parce que l’un mesure en laboratoire et l’autre sur le terrain. Le score de PageSpeed vient d’un test simulé, la Search Console de 28 jours de visites réelles, sur des appareils et des réseaux souvent plus lents, avec des interactions que le test ne reproduit pas.
Combien de temps avant de voir l’effet d’une correction ?
Jusqu’à 28 jours, la durée de collecte des données de terrain. La validation de la Search Console suit cette même période. Les tests de laboratoire, eux, montrent l’effet immédiatement.
Faut-il activer le pré-rendu ?
Sur un site bien mis en cache, le pré-rendu modéré rend la navigation presque instantanée dans Chrome. Il charge toutefois des pages que le visiteur n’ouvrira pas toujours, ce qui augmente la charge du serveur et peut gonfler certaines statistiques. Testez-le, puis surveillez votre serveur.
Mon site n’a pas de données de terrain : que faire ?
Un site peu fréquenté peut ne pas figurer dans le Chrome UX Report. Travaillez alors avec les tests de laboratoire, en sachant qu’ils ne mesurent pas l’INP réel, ou installez un outil de mesure des visiteurs réels basé sur la bibliothèque web-vitals de Google.
Conclusion
Les sites WordPress ne souffrent pas d’abord de leur réactivité, mais de leur chargement : un serveur trop lent à répondre, puis une image principale découverte trop tard ou différée par erreur. Corriger ces deux points règle une bonne partie du problème, avant même de toucher aux scripts.
L’histoire du chargement différé rappelle enfin qu’une optimisation se vérifie sur le terrain, jamais sur un score. Mesurez, corrigez, puis attendez 28 jours avant de conclure. Et si votre site a d’autres fragilités invisibles, notre liste des erreurs WordPress à éviter vous aidera à les repérer.
Sources
- web.dev (31 octobre 2024). Web Vitals
- web.dev (4 septembre 2025). Largest Contentful Paint (LCP)
- web.dev (2 septembre 2025). Interaction to Next Paint (INP)
- web.dev. Cumulative Layout Shift (CLS)
- web.dev (12 mars 2024). Interaction to Next Paint is officially a Core Web Vital
- web.dev (31 octobre 2024). The most effective ways to improve Core Web Vitals
- web.dev (31 mars 2025). Optimize Largest Contentful Paint
- web.dev (28 novembre 2025). Time to First Byte (TTFB)
- web.dev (19 décembre 2024). Optimize long tasks
- web.dev (2 juillet 2026). Back/forward cache
- Google Search Central (22 septembre 2026). Understanding page experience in Google Search results
- Google Search Console Help. Core Web Vitals report
- Google for Developers. About PageSpeed Insights
- Chrome for Developers. CrUX methodology
- HTTP Archive (données d’août 2026). Technology Report, WordPress
- HTTP Archive (15 janvier 2026). Web Almanac 2025, Performance
- Make WordPress Core, Felix Arntz (15 juillet 2021). Refining WordPress core’s lazy-loading implementation
- Make WordPress Core, Felix Arntz (13 juillet 2023). Image performance enhancements in WordPress 6.3
- Make WordPress Core, Felix Arntz (19 septembre 2023). Analyzing the Core Web Vitals performance impact of WordPress 6.3 in the field
- Make WordPress Core, Felix Arntz (19 décembre 2023). WordPress performance impact on Core Web Vitals in 2023
- Make WordPress Core, Adam Silverstein (23 février 2024). WordPress 6.5 adds AVIF support
- Make WordPress Core, Felix Arntz (6 mars 2025). Speculative Loading in 6.8
- Make WordPress Core, Weston Ruter (18 novembre 2025). WordPress 6.9 Frontend Performance Field Guide
- WordPress Developer Resources. wp_get_speculation_rules_configuration()
- web.dev, Mari Viana et al. (22 janvier 2025). How QuintoAndar reduced INP by 80%
- WordPress.org. Web Worker Offloading
- Make WordPress Core, Adam Silverstein (7 juin 2021). WordPress 5.8 adds WebP support
- WordPress.org. Optimization Detective
LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, optimisation des performances comprise, et développe ses propres plugins. Parlons de votre projet WordPress.