Comment améliorer ses Core Web Vitals sur WordPress en 2026 : guide complet

Vous avez reçu une alerte dans Google Search Console indiquant des URL avec une expérience médiocre ? 🤔Votre score PageSpeed Insights varie d’un test à l’autre ? Ou vous constatez une baisse de trafic sans comprendre si la vitesse de votre site WordPress est en cause ? Les Core Web Vitals WordPress sont souvent au cœur du problème. 🎉Ces indicateurs permettent d’évaluer trois aspects essentiels de l’expérience utilisateur : la vitesse de chargement, la réactivité et la stabilité visuelle d’une page.

En 2026, les propriétaires de sites WordPress ne peuvent plus se contenter d’un site “joli” ou “fonctionnel” : il doit aussi être rapide, stable et agréable à utiliser sur mobile. ✨Bonne nouvelle : avec les bons outils et une méthode claire, il est possible d’identifier les problèmes et de les corriger progressivement.

Objectif

L’objectif de ce guide est simple : vous aider à comprendre, diagnostiquer et améliorer vos Core Web Vitals sur WordPress sans vous perdre dans des termes trop techniques. 🚀Vous allez découvrir ce que signifient concrètement le LCP, l’INP et le CLS, comment savoir quelle métrique pose problème sur votre site, puis quelles actions appliquer selon le diagnostic. ⚡Nous verrons notamment comment optimiser les images, le cache, les fichiers JavaScript et CSS, les polices web, l’hébergement et certains éléments qui provoquent des décalages visuels. 😊Notre guide présentera également le rôle de LWS Optimize, une extension gratuite qui regroupe plusieurs optimisations utiles pour les performances WordPress, comme le cache, le Lazy Loading, le Critical CSS ou la conversion WebP/AVIF.

Les trois métriques : comprendre avant de corriger

Avant de modifier votre site, il faut comprendre ce que mesurent les Core Web Vitals. Google les présente comme un ensemble de métriques destinées à évaluer l’expérience réelle des visiteurs sur trois dimensions :

• le chargement,
• l’interactivité,
• la stabilité visuelle,

La première métrique est le LCP, ou Largest Contentful Paint. Elle mesure le temps nécessaire pour afficher le plus grand élément visible dans la partie principale de la page. Sur WordPress, il s’agit souvent d’une grande image d’en-tête, d’une bannière, d’un bloc hero ou parfois du titre principal. Un bon LCP doit être inférieur ou égal à 2,5 secondes.

La deuxième métrique est l’INP, ou Interaction to Next Paint. Elle mesure la réactivité d’une page lorsqu’un visiteur interagit avec elle : clic sur un bouton, ouverture d’un menu, saisie dans un formulaire, ajout au panier, etc. L’INP a remplacé le FID comme Core Web Vital en mars 2024, afin de mieux évaluer la réactivité pendant toute la session de navigation.

La troisième métrique est le CLS, ou Cumulative Layout Shift. Elle mesure les décalages visuels inattendus. Par exemple, un bouton qui descend brusquement parce qu’une image vient de charger, une publicité qui pousse le contenu vers le bas ou un bandeau RGPD qui modifie la mise en page.

Un point est essentiel : un bon score Lighthouse ne garantit pas automatiquement de bons Core Web Vitals dans Google Search Console. Lighthouse réalise un test en conditions simulées, tandis que Search Console s’appuie sur des données issues d’utilisateurs réels, lorsque celles-ci sont disponibles. C’est pourquoi il faut toujours croiser les résultats plutôt que de se fier à un seul outil.

Besoin d’un hébergement WordPress rapide et de qualité ?

Profitez de l'offre exclusive de LWS : hébergement WordPress en France à -42% ! Démarrez dès maintenant à partir de 3,49€/mois au lieu de 5,99€. Performance 🚀 et support exceptionnel garantis ! 😊

Découvrir l’offre

Diagnostiquer ses Core Web Vitals : les outils

Pour améliorer vos Core Web Vitals WordPress, ne commencez pas par installer plusieurs plugins au hasard. La bonne méthode consiste d’abord à identifier la ou les métriques en échec. Un problème de LCP ne se corrige pas comme un problème d’INP ou de CLS. Le LCP demande souvent d’optimiser les images, le cache ou le temps de réponse serveur. L’INP est plutôt lié au JavaScript, aux scripts tiers ou aux extensions trop lourdes. Le CLS, lui, concerne surtout la structure visuelle de la page.

Trois outils sont particulièrement utiles : Google Search Console, PageSpeed Insights et Chrome DevTools.

Google Search Console (données terrain — priorité)

Google Search Console doit être votre première source d’analyse, car elle affiche les problèmes détectés sur des groupes d’URL à partir de données réelles. Pour y accéder, ouvrez votre propriété dans Search Console, puis rendez-vous dans la section « Expérience > Core Web vitals ».

Vous y trouverez une vue d’ensemble des URL classées comme bonnes, à améliorer ou médiocres. Le rapport distingue généralement les performances mobiles et desktop. Il est recommandé de commencer par le mobile, car Google utilise principalement la version mobile d’un site pour l’indexation et le classement.

La première action consiste à repérer les groupes d’URL médiocres, puis à regarder quelle métrique est concernée. Par exemple, si plusieurs articles de blog échouent à cause du LCP, le problème peut venir d’une image mise en avant trop lourde, d’un cache absent ou d’un serveur trop lent. Si la métrique en cause est l’INP, il faudra plutôt examiner les scripts JavaScript, les extensions ou les éléments interactifs. Si le CLS est élevé, il faudra chercher les éléments qui provoquent des sauts de mise en page.

Search Console ne sert donc pas uniquement à constater un problème : elle aide à prioriser les corrections. Vous évitez ainsi de passer du temps sur des optimisations inutiles.

PageSpeed Insights (diagnostic instantané)

PageSpeed Insights est l’outil le plus accessible pour obtenir un diagnostic rapide d’une page précise. Il suffit de saisir l’URL à tester pour obtenir deux types d’informations : les données terrain, si elles sont disponibles, et une analyse Lighthouse réalisée en laboratoire.

L’onglet « Mobile » doit être étudié en priorité. Sur un site WordPress, il révèle souvent les problèmes les plus visibles : image principale trop lourde, JavaScript inutilisé, CSS bloquant le rendu, absence de cache, temps de réponse serveur élevé ou ressources externes trop nombreuses.

Les sections « Opportunités et Diagnostics » sont particulièrement utiles. Elles indiquent les fichiers, images ou scripts qui ralentissent l’affichage de la page. Par exemple, si PageSpeed Insights signale une image trop volumineuse comme élément LCP, vous savez que l’optimisation doit commencer par cette image, et non par la base de données ou le thème.

Chrome DevTools (diagnostic approfondi)

Chrome DevTools est plus technique, mais très utile lorsque PageSpeed Insights ne suffit pas. Il permet d’observer ce qui se passe réellement pendant le chargement et l’utilisation de la page.

Pour l’utiliser, ouvrez votre page dans Chrome, puis appuyez sur F12 ou faites un clic droit et choisissez l’option « Inspecter ».

Allez ensuite dans l’onglet « Performance », lancez un enregistrement, naviguez quelques secondes sur la page, puis arrêtez l’analyse.

Cet outil permet notamment d’identifier l’élément LCP exact, les scripts qui occupent le thread principal, les longues tâches JavaScript et les moments où la page devient moins réactive.

Il est donc très pratique pour comprendre un mauvais INP. Par exemple, si un menu, un slider ou un module de page builder provoque un délai visible au clic, DevTools peut aider à repérer le script responsable.

Pour un diagnostic plus simple au quotidien, vous pouvez aussi utiliser une extension Chrome dédiée aux Web Vitals. Elle affiche les principales métriques pendant que vous naviguez sur votre site, ce qui permet de repérer rapidement les pages ou interactions problématiques.

Améliorer le LCP (Largest Contentful Paint)

Le LCP, ou Largest Contentful Paint, mesure le temps nécessaire pour afficher le plus grand élément visible dans la fenêtre du navigateur. Sur WordPress, cet élément correspond souvent à l’image principale d’un article, à une bannière hero, à un visuel de page d’accueil ou à un gros bloc de texte situé au-dessus de la ligne de flottaison. Pour offrir une bonne expérience utilisateur, Google recommande un LCP inférieur ou égal à 2,5 secondes.

Un mauvais LCP donne une impression de lenteur dès les premières secondes. Même si le reste de la page finit par se charger correctement, l’utilisateur peut avoir l’impression que le site est lourd, peu fiable ou mal optimisé. C’est particulièrement problématique sur mobile, où la connexion peut être moins stable et l’écran plus petit.

Sur WordPress, les causes d’un LCP élevé sont souvent les mêmes : images trop lourdes, absence de cache, fichiers JavaScript ou CSS bloquants, polices web mal chargées ou temps de réponse serveur trop long. L’objectif n’est donc pas d’appliquer toutes les optimisations possibles au hasard, mais d’identifier ce qui ralentit l’affichage de l’élément principal.

Images non optimisées (cause n°1)

Les images sont l’une des causes les plus fréquentes d’un mauvais LCP sur WordPress. Une image d’en-tête trop lourde, un fichier PNG non compressé ou une photo importée en 3000 pixels de large pour un affichage réel de 800 pixels peuvent fortement ralentir le rendu de la page.

La première étape consiste à vérifier l’image principale de chaque page stratégique : accueil, pages services, fiches produits, articles générant du trafic SEO. Si cette image est détectée comme élément LCP dans PageSpeed Insights, elle doit être optimisée en priorité.

Plusieurs bonnes pratiques permettent d’améliorer rapidement la situation :

• convertir les images en formats modernes comme WebP ou AVIF ;
• compresser les fichiers sans perte visible de qualité ;
• redimensionner les images avant ou pendant leur intégration ;
• éviter d’utiliser une image beaucoup plus grande que son emplacement réel ;
• charger en priorité l’image principale visible au-dessus de la ligne de flottaison.

Avec LWS Optimize, il est possible de convertir les images WordPress en WebP/AVIF, d’activer le Lazy Loading et d’utiliser plusieurs options d’optimisation depuis une seule extension.

Notre extension intègre notamment du cache, de la conversion WebP/AVIF, du Critical CSS, du Lazy Loading, de l’intégration Cloudflare CDN et d’un test PageSpeed intégré.

Attention toutefois à un piège courant : le Lazy Loading ne doit pas retarder l’image LCP.

Le chargement différé est très utile pour les images situées plus bas dans la page, mais l’image hero doit généralement être chargée immédiatement.

Si votre image principale est placée en Lazy Loading, le navigateur attendra avant de la récupérer, ce qui peut dégrader le LCP au lieu de l’améliorer.

Dans LWS Optimize, il est donc recommandé d’activer le Lazy Loading pour les images secondaires, tout en excluant l’image principale lorsque cela est nécessaire. Cette exclusion peut se faire via un sélecteur CSS correspondant à l’image hero, par exemple une classe comme .hero-image ou un identifiant comme #featured-img.

Absence de cache page (cause majeure)

Un site WordPress fonctionne avec PHP, une base de données MySQL et plusieurs fichiers chargés dynamiquement. Sans cache, le serveur doit reconstruire la page à chaque visite : il exécute WordPress, interroge la base de données, charge le thème, les extensions, puis génère le HTML final. Ce processus peut prendre du temps, surtout si le site contient beaucoup de plugins ou reçoit plusieurs visiteurs en même temps.

Le cache permet de conserver une version déjà générée de la page. Lorsqu’un internaute revient sur une page ou lorsqu’un nouveau visiteur consulte une page identique, le serveur peut lui envoyer une version prête à l’emploi. Résultat : le temps de réponse diminue, la page commence à s’afficher plus vite et le LCP peut s’améliorer.

Sur les hébergements LWS compatibles, LWS Cache permet d’utiliser un cache configuré au niveau serveur avec des mécanismes avancés basés sur NGINX. Cet outil est un système conçu pour optimiser les performances de chargement grâce à un cache serveur avancé.

Pour un site WordPress hébergé chez LWS, l’approche recommandée consiste à activer le cache disponible côté hébergement, puis à utiliser l’extension prévue pour gérer la purge lorsque le contenu change.

Le plugin LWSCache permet notamment de gérer et purger automatiquement le cache lors des modifications de contenus, lorsqu’il est utilisé sur un serveur compatible avec le système LWSCache.

LWS Optimize propose également un cache de fichiers directement intégré à l’extension. Cette solution peut être utile pour accélérer un site WordPress sans multiplier les plugins de performance.

Une règle importante : évitez d’activer plusieurs plugins de cache en même temps. Deux systèmes de cache concurrents peuvent créer des conflits, afficher d’anciennes versions de vos pages ou provoquer des erreurs difficiles à diagnostiquer.

JavaScript et CSS bloquant le rendu

Même avec de bonnes images et un cache actif, le LCP peut rester mauvais si la page charge trop de fichiers CSS ou JavaScript avant d’afficher son contenu principal. Ces fichiers peuvent bloquer le rendu : le navigateur doit les télécharger, les lire et parfois les exécuter avant de pouvoir afficher correctement la partie visible de la page.

Sur WordPress, ce problème vient souvent :

• d’un thème trop chargé ;
• d’un page builder qui ajoute beaucoup de fichiers ;
• de plugins qui chargent leurs scripts sur toutes les pages ;
• de fichiers CSS volumineux ;
• de JavaScript non critique placé trop tôt dans le chargement.

La première action consiste à analyser les recommandations de PageSpeed Insights. Si l’outil indique des ressources qui bloquent le rendu ou du JavaScript inutilisé, il faut identifier les fichiers concernés. Il peut s’agir d’un slider, d’un formulaire, d’un outil d’analytics, d’un module e-commerce ou d’une extension qui charge ses scripts même sur les pages où elle n’est pas utilisée.

LWS Optimize peut aider à réduire cet impact grâce à plusieurs réglages : minification CSS, minification JavaScript, génération du Critical CSS et différé du JavaScript non critique. Ces fonctionnalités visent à alléger les fichiers et à permettre au navigateur d’afficher plus vite le contenu important.

Le Critical CSS est particulièrement utile pour le LCP. Il consiste à charger en priorité uniquement les styles nécessaires à l’affichage de la partie visible de la page. Le reste du CSS est chargé ensuite, de manière moins bloquante. Le visiteur voit donc plus vite le contenu principal, même si certains styles secondaires continuent de se charger en arrière-plan.

Le différé JavaScript doit toutefois être appliqué avec prudence. Certains scripts sont nécessaires au bon fonctionnement d’un menu, d’un formulaire, d’un panier WooCommerce ou d’un module interactif. Après chaque optimisation, testez les pages importantes : navigation mobile, formulaire de contact, bouton d’ajout au panier, tunnel de commande et pop-up éventuelle.

Polices web (Google Fonts) mal chargées

Les polices web peuvent aussi ralentir le LCP, surtout lorsqu’elles sont chargées depuis un service externe comme Google Fonts. Avant d’afficher le texte avec la bonne typographie, le navigateur doit établir une connexion avec un domaine tiers, télécharger les fichiers de police, puis les appliquer à la page. Sur une connexion mobile moyenne, ce délai peut suffire à retarder l’affichage du contenu principal.

Le problème est encore plus visible lorsque le titre principal ou le bloc hero utilise une police personnalisée. Si ce texte fait partie de l’élément LCP, le chargement de la police peut directement impacter le score.

La première solution consiste à héberger les polices localement. Depuis WordPress 6.5, la bibliothèque de polices permet de gérer des polices directement dans WordPress, notamment en installant des polices locales ou Google Fonts selon le thème utilisé.

La documentation WordPress précise également que les polices Google Fonts installées via cette bibliothèque sont hébergées localement sur le serveur WordPress.

Sur un site LWS, vous pouvez aussi passer par LWS Optimize pour l’optimisation ou l’hébergement local des polices dans votre configuration.

L’intérêt est double : réduire les connexions externes et limiter les variations d’affichage pendant le chargement.

Il est également recommandé d’utiliser la règle CSS font-display: swap. Elle permet d’afficher rapidement une police de secours, puis de remplacer celle-ci par la police finale dès qu’elle est disponible. Cela évite que le texte reste invisible pendant le chargement.

Exemple :

@font-face {
    font-family: "MaPolice";
    src: url("/wp-content/uploads/fonts/ma-police.woff2") format("woff2");
    font-display: swap;
}

Hébergement lent (TTFB élevé)

Même avec des images optimisées, un cache actif et des fichiers allégés, un site WordPress peut rester lent si le serveur répond trop tard. Le TTFB, ou Time to First Byte, correspond au temps nécessaire pour recevoir le premier octet de réponse du serveur. Plus ce délai est élevé, plus le navigateur attend avant de commencer à afficher la page.

Un TTFB trop long peut venir de plusieurs causes : hébergement sous-dimensionné, version PHP obsolète, base de données trop lourde, extensions trop nombreuses, absence de cache serveur ou trafic supérieur aux ressources disponibles. Sur WordPress, ce problème est fréquent lorsque le site a évolué au fil du temps sans nettoyage ni optimisation technique.

Pour vérifier ce point, lancez un test PageSpeed Insights et regardez si l’outil signale un temps de réponse serveur trop élevé. Vous pouvez aussi utiliser l’onglet « Network » de Chrome DevTools pour observer le délai de réponse du document HTML principal.

Plusieurs actions peuvent améliorer la situation :

• activer un cache page ou un cache serveur ;
• utiliser une version récente de PHP compatible avec votre site ;
• supprimer les plugins inutiles ;
• nettoyer la base de données ;
• vérifier que le thème n’exécute pas trop de requêtes ;
• choisir une offre d’hébergement adaptée au trafic réel.

PHP 8.3 a introduit de nouvelles fonctionnalités, des corrections et des améliorations de performance, tandis que PHP 8.4 bénéficie encore d’un support actif en 2026 selon le calendrier officiel de PHP. Le bon choix dépend toutefois de la compatibilité de votre thème, de vos extensions et de votre environnement d’hébergement.

Chez LWS, l’activation de LWS Cache peut réduire fortement le temps de génération des pages lorsque l’offre est compatible. Vous pouvez activer et configurer LWS Cache depuis LWS Panel en suivant ce guide.

Pour les sites plus exigeants, comme un WooCommerce avec beaucoup de produits ou un média à fort trafic, il peut être utile d’envisager une offre WordPress plus performante ou un VPS KVM LWS.

L’essentiel est de ne pas traiter le TTFB comme un simple détail technique. Si le serveur met trop de temps à répondre, toutes les optimisations front-end auront un effet limité sur le LCP.

Besoin d’un hébergement WordPress rapide et de qualité ?

Profitez de l'offre exclusive de LWS : hébergement WordPress en France à -42% ! Démarrez dès maintenant à partir de 3,49€/mois au lieu de 5,99€. Performance 🚀 et support exceptionnel garantis ! 😊

Découvrir l’offre

Améliorer l’INP (Interaction to Next Paint)

L’INP, ou Interaction to Next Paint, mesure la réactivité d’une page lorsqu’un utilisateur interagit avec elle. Il peut s’agir d’un clic sur un bouton, de l’ouverture d’un menu, d’une saisie dans un formulaire, d’un changement de variante produit ou d’un ajout au panier. Contrairement au FID, qui mesurait uniquement la première interaction, l’INP évalue les interactions tout au long de la session.

Un mauvais INP se traduit par une sensation de lenteur au moment d’agir. La page semble chargée, mais elle répond avec retard. L’utilisateur clique sur un menu et rien ne se passe immédiatement. Il appuie sur “Ajouter au panier” et le bouton reste figé. Il ouvre un accordéon ou un filtre produit, mais l’interface met du temps à réagir.

Sur WordPress, cette métrique est souvent plus difficile à corriger que le LCP, car elle dépend beaucoup du JavaScript exécuté côté navigateur. Les principales causes sont généralement :

• trop de JavaScript chargé dès l’ouverture de la page ;
• des scripts tiers trop nombreux ;
• un thème ou un page builder lourd ;
• des plugins qui chargent leurs fichiers partout ;
• des animations ou effets visuels inutiles ;
• des fonctionnalités interactives mal optimisées.

Pour améliorer l’INP, il faut donc réduire le travail imposé au navigateur, surtout sur mobile. L’objectif n’est pas de supprimer tout le JavaScript, car cela casserait souvent le site, mais de charger uniquement ce qui est utile, au bon moment, sur les bonnes pages.

LWS Optimize peut aider en différant certains scripts non critiques et en minifiant les fichiers JavaScript. L’extension met en avant plusieurs fonctionnalités de performance, dont le cache, la minification, le Critical CSS, le Lazy Loading, le CDN et l’optimisation des Core Web Vitals.

JavaScript excessif au chargement de page

Le JavaScript excessif est l’une des causes les plus courantes d’un mauvais INP. Lorsqu’une page WordPress charge trop de scripts au démarrage, le navigateur doit les télécharger, les analyser et les exécuter. Pendant ce temps, le thread principal peut être occupé. Résultat : les interactions de l’utilisateur attendent leur tour.

Ce problème concerne souvent les sites qui utilisent beaucoup d’extensions : sliders, pop-ups, formulaires avancés, outils marketing, boutons de partage, cartes interactives, animations, systèmes de réservation ou modules WooCommerce. Chaque plugin peut ajouter ses propres fichiers JavaScript, parfois même sur des pages où ils ne sont pas nécessaires.

La première étape consiste à analyser la page avec PageSpeed Insights. Si l’outil signale du JavaScript inutilisé, observez les fichiers concernés. Vous pourrez souvent identifier une extension précise ou un module de thème responsable.

Ensuite, plusieurs solutions sont possibles :

• désactiver les plugins inutiles ;
• remplacer les extensions lourdes par des alternatives plus légères ;
• éviter les sliders et animations complexes au-dessus de la ligne de flottaison ;
• différer le JavaScript non critique ;
• charger certains scripts uniquement sur les pages où ils sont nécessaires ;
• tester le site après chaque modification.

Avec LWS Optimize, vous pouvez commencer par activer la minification JavaScript et le différé du JavaScript non critique. Ces réglages peuvent réduire le blocage initial et améliorer la réactivité perçue.

Pour un diagnostic plus avancé, un plugin comme Query Monitor peut aider à repérer les extensions qui sollicitent fortement WordPress côté serveur. Pour le JavaScript côté navigateur, Chrome DevTools reste l’outil le plus précis : l’onglet « Performance » permet de repérer les longues tâches qui bloquent les interactions.

Third-party scripts (Google Analytics, publicités, chats)

Les scripts tiers sont des fichiers chargés depuis des services externes à votre site WordPress. Ils peuvent venir de Google Analytics, Google Tag Manager, Meta Pixel, d’un outil de chat en ligne, d’une régie publicitaire, d’un widget de réseaux sociaux, d’un outil A/B testing ou encore d’un service de personnalisation marketing.

Ces scripts sont pratiques, mais ils peuvent fortement dégrader l’INP lorsqu’ils exécutent beaucoup de JavaScript côté navigateur. Le problème est simple : même si votre page semble chargée, le navigateur peut rester occupé à traiter des scripts externes. Pendant ce temps, les clics, ouvertures de menus ou saisies dans un formulaire peuvent être retardés.

Sur WordPress, ce problème apparaît souvent lorsque plusieurs outils marketing ont été ajoutés au fil du temps sans audit régulier. Un site peut charger un tag analytics, un pixel publicitaire, un chatbot, un outil de heatmap et des boutons de partage social sur toutes les pages, y compris celles où ces scripts n’apportent aucune valeur.

La première étape consiste à faire l’inventaire. Listez les scripts réellement utiles, puis supprimez ceux qui ne servent plus. Un ancien pixel publicitaire, un widget social inutilisé ou un outil de tracking jamais consulté peuvent ralentir inutilement le site.

Ensuite, chargez les scripts restants de manière plus intelligente :

• différer les scripts non essentiels ;
• déclencher certains outils après interaction ;
• limiter les tags aux pages où ils sont nécessaires ;
• éviter les widgets sociaux lourds ;
• remplacer certains services par des alternatives plus légères ;
• tester l’impact de chaque ajout dans PageSpeed Insights.

LWS Optimize peut aider en différant certains fichiers JavaScript non critiques. Cette optimisation doit cependant être testée avec soin. Un script de chat, un outil de consentement RGPD ou un module de suivi e-commerce peut cesser de fonctionner correctement s’il est chargé trop tard.

Pour les sites WooCommerce, soyez particulièrement prudent. Les scripts liés au panier, au paiement, au suivi des conversions ou aux moyens de paiement ne doivent pas être désactivés sans test complet. L’objectif est d’alléger le site, pas de casser le parcours d’achat.

Thème ou page builder lourd

Le thème WordPress et le page builder jouent un rôle important dans l’INP. Un thème très riche en animations, effets visuels, sliders, menus complexes et modules dynamiques peut générer beaucoup de JavaScript. Même chose pour certains constructeurs de pages lorsqu’ils chargent de nombreux fichiers sur chaque page.

Ce n’est pas forcément le page builder en lui-même qui pose problème, mais la manière dont il est utilisé. Une page construite avec plusieurs sections animées, carrousels, compteurs, pop-ups, accordéons, onglets et effets au scroll demandera plus d’efforts au navigateur qu’une page simple, structurée et légère.

Pour améliorer l’INP, commencez par analyser les pages les plus importantes : page d’accueil, pages commerciales, articles SEO, fiches produits et tunnel de commande. Demandez-vous si chaque élément interactif est réellement utile. Un slider automatique en haut de page, par exemple, apporte rarement autant de valeur qu’une image statique bien optimisée et un message clair.

Si vous utilisez Elementor, vérifiez les options de performance disponibles dans votre version. Elementor documente notamment la fonctionnalité Improved Asset Loading, qui vise à charger uniquement les fonctionnalités nécessaires sur chaque page afin de réduire le volume de code chargé côté visiteur.

Elementor propose également plusieurs fonctionnalités de performance destinées à réduire le code, optimiser le DOM et améliorer la vitesse des pages. Ces réglages peuvent être utiles, mais doivent être testés après activation, surtout sur les pages contenant des formulaires, des menus personnalisés ou des widgets dynamiques.

De manière générale, privilégiez :

• un thème léger et maintenu ;
• des blocs simples plutôt que des effets complexes ;
• peu d’animations au chargement ;
• des pages construites avec une hiérarchie claire ;
• des extensions réellement nécessaires ;
• des modèles de page cohérents et faciles à maintenir.

Pour les sites récents, un thème compatible avec l’édition complète du site peut être une bonne base, à condition de rester sobre dans la mise en page. Pour les sites existants, il n’est pas toujours nécessaire de tout reconstruire. Commencez par alléger les pages les plus stratégiques, supprimer les modules inutiles et tester l’impact sur l’INP.

Améliorer le CLS (Cumulative Layout Shift)

Le CLS, ou Cumulative Layout Shift, mesure la stabilité visuelle d’une page. Il détecte les mouvements inattendus d’éléments pendant le chargement. Un bon CLS doit rester inférieur ou égal à 0,1 selon les recommandations de Google.

Concrètement, un mauvais CLS se manifeste par une page qui “saute”. Vous commencez à lire un paragraphe, puis une image se charge et pousse le texte vers le bas. Vous voulez cliquer sur un bouton, mais une publicité apparaît et déplace l’élément. Vous ouvrez une page sur mobile, puis un bandeau vient modifier la hauteur du contenu.

Ce type de problème est frustrant pour l’utilisateur, car il donne une impression d’instabilité. Il peut aussi provoquer des clics involontaires, notamment sur mobile. Pour un site vitrine, cela nuit à la crédibilité. Pour une boutique WooCommerce, cela peut perturber le parcours d’achat, surtout si les décalages apparaissent sur une fiche produit ou une page panier.

Sur WordPress, les causes les plus fréquentes de CLS sont généralement :

• des images sans dimensions déclarées ;
• des publicités ou iframes sans espace réservé ;
• des polices web qui changent l’apparence du texte après chargement ;
• des bandeaux RGPD mal positionnés ;
• des contenus injectés dynamiquement au-dessus du contenu principal ;
• des modules de page builder qui se redimensionnent après coup.

La correction du CLS demande donc moins de “vitesse brute” que de rigueur dans la structure de la page. Il faut aider le navigateur à réserver l’espace nécessaire avant que les éléments ne soient entièrement chargés.

Images sans dimensions déclarées

Les images sans dimensions déclarées sont une cause classique de CLS. Lorsqu’une image ne possède pas d’attributs width et height, le navigateur ne connaît pas sa taille avant de l’avoir chargée. Il ne peut donc pas réserver correctement l’espace dans la page. Résultat : le contenu situé en dessous peut être poussé vers le bas au moment où l’image apparaît.

Ce problème concerne surtout les anciennes images, les images ajoutées manuellement dans du code HTML, certains blocs personnalisés ou des contenus générés par des extensions. Il peut aussi apparaître avec des logos, icônes, bannières, images de fond mal gérées ou visuels insérés dans des modèles de page builder.

Dans un contenu WordPress classique, les versions récentes de WordPress gèrent mieux les dimensions des images insérées via l’éditeur. WordPress 5.5 a notamment introduit le Lazy Loading natif des images, en s’appuyant sur l’attribut HTML loading, ce qui a contribué à améliorer la gestion des médias côté navigateur.

Pour corriger ce problème, commencez par identifier les images concernées dans PageSpeed Insights ou Chrome DevTools. Si un rapport signale des éléments sans largeur ni hauteur explicites, vérifiez le HTML généré. Une image correctement déclarée doit contenir des dimensions ou être encadrée par un conteneur dont l’espace est réservé.

Exemple de balisage à privilégier :

<img
    src="/wp-content/uploads/image-exemple.webp"
    width="800"
    height="450"
    alt="Exemple d’image optimisée pour WordPress">

Si votre site contient beaucoup d’anciennes images, vous pouvez aussi régénérer les miniatures depuis WordPress ou depuis les outils proposés par votre hébergement lorsque cette option est disponible. Dans LWS Optimize, c’est facile à faire.

L’objectif est de s’assurer que WordPress dispose de versions adaptées aux différents formats d’affichage : mobile, tablette, desktop, image mise en avant, miniature, bannière, etc.

Publicités et iframes sans espace réservé

Les publicités, vidéos intégrées, cartes Google Maps, modules de réservation ou iframes externes peuvent provoquer un mauvais CLS lorsqu’ils se chargent après le reste du contenu. Le problème vient souvent du fait que le navigateur ne connaît pas leur taille à l’avance. Il affiche donc la page, puis insère l’élément externe au moment où celui-ci devient disponible, ce qui pousse le contenu vers le bas.

Ce cas est fréquent sur les sites WordPress qui utilisent :

• des blocs publicitaires ;
• des vidéos YouTube intégrées ;
• des cartes Google Maps ;
• des widgets de réseaux sociaux ;
• des systèmes de réservation ;
• des formulaires externes ;
• des comparateurs ou modules d’affiliation.

Pour éviter les décalages, il faut réserver un espace fixe ou minimum avant le chargement de l’élément. Le navigateur sait ainsi qu’un bloc doit apparaître à cet endroit et conserve la place nécessaire.

Exemple pour un bloc publicitaire :

.ad-container {
    min-height: 250px;
}

Pour une vidéo intégrée, il est préférable d’utiliser un conteneur responsive qui conserve le bon ratio d’affichage :

.video-wrapper {
aspect-ratio: 16 / 9;
width: 100%;
background: #f3f3f3;
}

.video-wrapper iframe {
width: 100%;
height: 100%;
border: 0;
}

Ce code réserve un espace au format 16:9 avant même que la vidéo ne soit chargée. Le fond gris peut aussi servir d’espace temporaire, afin que l’utilisateur comprenne qu’un contenu va apparaître.

Sur WordPress, vérifiez particulièrement les pages contenant de la publicité, des vidéos ou des modules externes placés au-dessus ou au milieu du contenu. Ce sont souvent ces éléments qui dégradent le CLS sans que le propriétaire du site ne s’en rende compte immédiatement.

Polices web qui causent un FOUT/FOIT

Les polices web peuvent provoquer des décalages visuels lorsqu’elles se chargent après le texte. Deux phénomènes sont fréquents : le FOUT et le FOIT.

Le FOUT, ou Flash Of Unstyled Text, se produit lorsque le navigateur affiche d’abord le texte avec une police système, puis le remplace par la police web une fois celle-ci chargée. Si les deux polices n’ont pas les mêmes proportions, les lignes peuvent changer de hauteur ou de largeur, ce qui déplace certains éléments.

Le FOIT, ou Flash Of Invisible Text, se produit lorsque le texte reste invisible pendant le chargement de la police. Dans ce cas, l’utilisateur peut voir apparaître brutalement un bloc de texte après quelques instants, ce qui nuit à la perception de vitesse et peut également modifier la mise en page.

Pour limiter ces problèmes, plusieurs actions sont recommandées :

• héberger les polices localement plutôt que de multiplier les connexions externes ;
• limiter le nombre de familles et de graisses utilisées ;
• éviter de charger des variantes inutiles ;
• utiliser font-display: swap ;
• choisir une police de secours proche de la police finale ;
• tester le rendu sur mobile.

Voici un exemple simple :

@font-face {
    font-family: "Inter";
    src: url("/wp-content/uploads/fonts/inter.woff2") format("woff2");
    font-display: swap;
}

Pour réduire encore les risques de décalage, choisissez une police de secours proche :

body {
    font-family: "Inter", Arial, sans-serif;
}

Avec WordPress, l’idéal est de garder une stratégie typographique simple : une police pour les titres, une police pour le texte, et seulement les graisses réellement nécessaires. Plus vous chargez de variantes, plus vous augmentez les risques de lenteur et de variations d’affichage.

Bandeau RGPD mal configuré

Le bandeau RGPD est un autre élément souvent responsable d’un mauvais CLS. Sur de nombreux sites WordPress, il est ajouté via une extension de consentement aux cookies. S’il est mal configuré, il peut apparaître après le chargement de la page et pousser le contenu vers le haut ou vers le bas.

Le problème est particulièrement visible sur mobile. L’utilisateur commence à lire le contenu, puis le bandeau apparaît, modifie la hauteur de la page et déplace les boutons ou les paragraphes. Cela donne une impression de site instable et peut provoquer des clics accidentels.

Pour éviter cela, le bandeau doit être positionné sans modifier le flux normal du document. En pratique, il vaut mieux utiliser une position fixed ou sticky plutôt qu’un bloc inséré directement entre deux sections de contenu.

Exemple :

.cookie-banner {
    position: fixed;
    left: 0;
    right: 0;
    bottom: 0;
    z-index: 9999;
}

Il faut toutefois veiller à ne pas masquer des éléments importants, comme un bouton d’ajout au panier, un bouton de contact ou une barre de navigation mobile. Sur WooCommerce, testez toujours l’affichage du bandeau sur les pages produit, panier et commande.

Voici quelques bonnes pratiques :

• éviter les bandeaux qui s’insèrent au milieu du contenu ;
• privilégier un affichage fixe en bas ou en overlay ;
• tester le comportement sur mobile ;
• vérifier que les boutons restent accessibles ;
• limiter la hauteur du bandeau ;
• éviter les animations d’apparition trop longues.

Un bandeau RGPD bien configuré peut rester conforme et visible sans dégrader l’expérience utilisateur. L’objectif n’est pas de le cacher, mais de l’intégrer proprement dans la page.

LWS Optimize : configuration complète pour les Core Web Vitals

Après avoir identifié les problèmes liés au LCP, à l’INP et au CLS, vous pouvez centraliser une grande partie des optimisations avec LWS Optimize. Cette extension gratuite développée par LWS regroupe plusieurs fonctionnalités utiles pour améliorer les performances WordPress : cache, minification, optimisation des images, Lazy Loading, Critical CSS, CDN Cloudflare et test PageSpeed intégré.

L’intérêt de LWS Optimize est de proposer une approche progressive. Vous n’avez pas besoin d’activer tous les réglages en une seule fois. Au contraire, il est préférable d’activer les optimisations étape par étape, puis de tester le site après chaque changement. Cela permet d’éviter les conflits avec le thème, les plugins, WooCommerce ou certains scripts spécifiques.

Pour un site WordPress classique, vous pouvez commencer par les réglages suivants :

La première priorité est généralement le cache. Un cache actif réduit le temps de génération des pages et peut améliorer le LCP, surtout si le serveur devait auparavant reconstruire chaque page à chaque visite.

La deuxième priorité concerne les images. La conversion en WebP ou AVIF, la compression et le redimensionnement permettent de réduire le poids des visuels. Sur les pages où l’image principale est l’élément LCP, cette optimisation peut avoir un effet direct.

La troisième priorité porte sur les fichiers CSS et JavaScript. La minification réduit leur poids, tandis que le Critical CSS aide à afficher plus vite la partie visible de la page. Le différé JavaScript peut améliorer le LCP et l’INP, à condition de ne pas retarder les scripts essentiels.

La quatrième priorité concerne les polices et les ressources externes. Héberger les polices localement, réduire les appels à des domaines tiers et limiter les scripts marketing inutiles permet de stabiliser le chargement et d’améliorer l’expérience mobile.

Pour approfondir sur ce sujet, consultez notre guide : comment héberger vos polices localement avec la Font Library de WordPress 7.0.

Pour aller plus loin dans la configuration, vous pouvez apprendre à configurer LWS Optimize en détail. Dans le cadre de ce guide, l’important est de comprendre que LWS Optimize n’est pas seulement un plugin de cache : c’est une boîte à outils qui permet d’agir sur plusieurs causes des Core Web Vitals.

Avant de valider définitivement vos réglages, testez toujours :

• la page d’accueil ;
• un article de blog ;
• une page commerciale ;
• une fiche produit si vous utilisez WooCommerce ;
• le panier ;
• la page de commande ;
• un formulaire de contact ;
• le menu mobile.

Si tout fonctionne correctement, vous pouvez ensuite mesurer les résultats dans PageSpeed Insights, puis surveiller l’évolution dans Google Search Console sur les semaines suivantes.

Besoin d’un hébergement WordPress rapide et de qualité ?

Profitez de l'offre exclusive de LWS : hébergement WordPress en France à -42% ! Démarrez dès maintenant à partir de 3,49€/mois au lieu de 5,99€. Performance 🚀 et support exceptionnel garantis ! 😊

Découvrir l’offre

Vérifier les résultats et monitorer

Une fois les optimisations appliquées, il faut mesurer les résultats avec méthode. Les Core Web Vitals ne se corrigent pas uniquement en visant un score PageSpeed élevé : Google Search Console s’appuie sur des données réelles d’utilisation, aussi appelées données terrain. Elles reflètent donc l’expérience de vrais visiteurs, sur différents appareils, connexions et navigateurs.

Commencez par tester les pages les plus importantes : page d’accueil, articles SEO générant du trafic, pages commerciales, fiches produits WooCommerce, panier, commande et formulaires. Il est inutile d’optimiser uniquement une page secondaire si les URL les plus visitées restent lentes.

Après une correction, PageSpeed Insights permet d’obtenir un premier retour rapide. Si l’image LCP est mieux compressée, si le cache est actif ou si un script bloquant a été différé, vous devriez constater une amélioration dans les données de laboratoire. Mais ce n’est pas suffisant pour valider définitivement le résultat.

La validation SEO doit se faire dans Google Search Console. Les rapports Core Web Vitals y regroupent les URL par niveau de qualité et par problème détecté. Les métriques sont évaluées sur des données réelles, et les outils Core Web Vitals s’appuient généralement sur le 75e percentile pour déterminer si l’expérience est bonne pour la majorité des visiteurs.

Il faut donc patienter avant de tirer une conclusion. Une amélioration visible dans PageSpeed Insights peut mettre du temps à se refléter dans Search Console, car les données terrain doivent se renouveler. Surveillez l’évolution progressivement plutôt que de modifier tous les réglages chaque jour.

Erreurs fréquentes

Même avec de bons outils, certaines erreurs peuvent ralentir ou déstabiliser un site WordPress. Elles viennent souvent d’optimisations activées trop vite, sans test complet.

La plus grande erreur consiste à chercher un score parfait au lieu de corriger le vrai problème utilisateur. Un site peut afficher un score PageSpeed correct, mais rester désagréable si un menu répond lentement, si un bandeau décale le contenu ou si une image principale apparaît trop tard.

À l’inverse, il ne faut pas casser l’expérience pour gagner quelques points. Supprimer tous les scripts peut améliorer artificiellement un test, mais rendre un formulaire inutilisable ou empêcher un panier WooCommerce de fonctionner. L’objectif est d’obtenir un site rapide, stable et fonctionnel.

Pour éviter les mauvaises surprises, appliquez les optimisations une par une. Activez un réglage dans LWS Optimize, videz le cache, testez les pages importantes, puis passez au réglage suivant. Cette méthode demande un peu plus de rigueur, mais elle permet d’identifier rapidement l’origine d’un éventuel problème.

FAQ

Les Core Web Vitals sont-ils un facteur de classement Google en 2026 ?

Oui. Google indique que les Core Web Vitals sont utilisés par ses systèmes de classement et recommande aux propriétaires de sites d’obtenir de bons résultats pour améliorer l’expérience utilisateur et favoriser leur réussite dans la recherche. Il faut toutefois retenir qu’un bon score Core Web Vitals ne garantit pas à lui seul une première position : la pertinence du contenu, la qualité globale de la page, l’intention de recherche et l’autorité du site restent essentielles.

Quelle est la différence entre le LCP, l’INP et le CLS ?

Le LCP mesure la vitesse d’affichage du plus grand élément visible de la page. L’objectif est de charger cet élément en moins de 2,5 secondes. L’INP mesure la réactivité de la page lorsqu’un utilisateur interagit avec elle, avec un objectif inférieur ou égal à 200 ms. Le CLS mesure les décalages visuels inattendus, avec un bon score inférieur ou égal à 0,1.

LWS Optimize améliore-t-il les Core Web Vitals sur tous les hébergements ?

LWS Optimize peut aider à améliorer les Core Web Vitals sur un site WordPress grâce à ses fonctionnalités de cache, minification, optimisation d’images, Lazy Loading, Critical CSS et test PageSpeed intégré. Sur un hébergement LWS, il peut être complété par les optimisations serveur disponibles selon l’offre, notamment LWS Cache lorsque celui-ci est compatible.

Pourquoi mon score PageSpeed Insights est bon mais Search Console signale des URL médiocres ?

PageSpeed Insights peut afficher des données de laboratoire et, lorsque disponibles, des données terrain. Search Console, de son côté, s’appuie sur des données réelles d’utilisation regroupées par URL. Un bon résultat lors d’un test ponctuel ne signifie donc pas forcément que la majorité des visiteurs vivent la même expérience, notamment sur mobile ou avec une connexion plus lente.

Combien de temps faut-il pour voir les améliorations Core Web Vitals dans Search Console ?

Les effets peuvent être visibles rapidement dans PageSpeed Insights après une correction, mais Google Search Console demande davantage de recul, car elle se base sur des données terrain collectées auprès des utilisateurs. Il faut donc surveiller l’évolution sur plusieurs semaines avant de conclure qu’une correction est pleinement prise en compte.

Peut-on améliorer les Core Web Vitals sans plugin de cache ?

Oui, mais les gains seront souvent limités. Vous pouvez déjà optimiser les images, réduire les scripts tiers, corriger les décalages visuels, héberger les polices localement et alléger votre thème. Cependant, le cache reste l’un des leviers les plus efficaces pour améliorer le LCP, car il réduit le temps nécessaire pour générer et servir les pages WordPress.

Conclusion

Améliorer ses Core Web Vitals WordPress demande une méthode claire : comprendre les métriques, diagnostiquer les pages concernées, puis appliquer les bonnes corrections. ✨Le LCP se travaille surtout avec les images, le cache, le CSS critique et la qualité de l’hébergement. L’INP dépend principalement du JavaScript, des scripts tiers et du poids du thème ou du page builder. Le CLS se corrige en stabilisant la mise en page : dimensions d’images, espaces réservés, polices bien chargées et bandeaux correctement positionnés. ⚡Avec LWS Optimize, LWS Cache et un hébergement WordPress adapté, vous disposez d’une base solide pour accélérer votre site, améliorer l’expérience mobile et suivre vos progrès dans Google Search Console.

Besoin d’un hébergement WordPress rapide et de qualité ?

Profitez de l'offre exclusive de LWS : hébergement WordPress en France à -42% ! Démarrez dès maintenant à partir de 3,49€/mois au lieu de 5,99€. Performance 🚀 et support exceptionnel garantis ! 😊

Découvrir l’offre

Vous avez des questions ou des ajouts sur la façon d’optimiser vos Core web vitals ? N’hésitez pas à nous contacter dans la section Commentaires.