Core Web Vitals WordPress : diagnostic et corrections (LCP, INP, CLS)

Pour améliorer les Core Web Vitals d’un site WordPress, identifiez d’abord quelle métrique échoue (LCP, INP ou CLS) et sur quel type de page, grâce aux données de terrain de PageSpeed Insights et de la Search Console. Décomposez ensuite le problème avec les outils de Chrome, corrigez la cause précise (serveur, image principale, JavaScript, mise en page), puis validez sur 28 jours. Chaque métrique a ses causes typiques sous WordPress : ce guide les passe en revue une par une.

Guide à jour au 15 octobre 2026, vérifié sur WordPress 7.1 et la documentation de Google publiée sur web.dev.

Que sont les Core Web Vitals et pourquoi comptent-ils ?

Les Core Web Vitals sont trois mesures de l’expérience réelle des visiteurs définies par Google : le LCP (vitesse d’affichage du contenu principal), l’INP (réactivité aux interactions) et le CLS (stabilité visuelle). Ils sont collectés auprès des utilisateurs de Chrome et utilisés, parmi d’autres signaux, par les systèmes de classement de Google.

Selon la documentation de Google sur l’expérience sur la page, les Core Web Vitals sont utilisés par ses systèmes de classement, mais il n’existe pas de signal unique d’« expérience sur la page » et de bons scores ne garantissent pas une première place. Ils comptent d’abord pour vos visiteurs.

Où trouver vos données Core Web Vitals ?

Commencez par les données de terrain, celles de vos vrais visiteurs : PageSpeed Insights pour une URL précise, le rapport « Signaux Web essentiels » de la Search Console pour l’ensemble du site. Les mesures de laboratoire (Lighthouse) servent ensuite à reproduire et à diagnostiquer, mais ne remplacent pas le terrain.

Voici les outils officiels et ce qu’ils vous apprennent :

Deux pièges fréquents : la Search Console attribue à chaque groupe d’URL le statut de sa pire métrique (un groupe « Mauvais » à cause du CLS peut avoir un excellent LCP), et un petit site n’a pas toujours assez de trafic pour des données par URL ; PageSpeed Insights affiche alors celles de l’origine entière.

Comment diagnostiquer un LCP trop lent ?

Identifiez l’élément LCP (souvent l’image à la une, une bannière ou le titre principal), puis mesurez ses quatre sous-parties : temps de réponse du serveur, délai avant le début du chargement de la ressource, durée de ce chargement, et délai de rendu. La sous-partie la plus longue vous indique la correction à faire.

Google décrit cette méthode dans son guide Optimize LCP, avec une répartition indicative pour un LCP sain :

Pour obtenir ces chiffres, ouvrez DevTools > Performance dans Chrome : les métriques en direct affichent le LCP local et son élément, et un enregistrement du chargement détaille les sous-parties.

1. TTFB élevé : corrigez le serveur d’abord

Si le TTFB dépasse à lui seul la moitié de votre budget, aucune optimisation côté navigateur ne suffira. Vérifiez qu’un cache de page sert bien vos pages (sur un serveur LiteSpeed, l’extension LiteSpeed Cache pilote le cache intégré : voir notre guide pour configurer LiteSpeed Cache), que la version de PHP est récente et qu’aucune redirection inutile ne précède la page (http vers https, puis sans www vers www, par exemple). Le choix du serveur web joue aussi : nous l’avons détaillé dans notre comparatif LiteSpeed, Nginx ou Apache pour WordPress.

# Mesurer le TTFB d'une page (en secondes), cache chaud : lancez la commande deux fois
curl -s -o /dev/null -w "TTFB : %{time_starttransfer}\n" https://www.example.com/

2. Délai de chargement : rendez l’image LCP découvrable et prioritaire

L’image LCP doit apparaître dans le HTML initial, sans attribut loading="lazy", idéalement avec fetchpriority="high". Depuis WordPress 6.3, le cœur ajoute automatiquement cette priorité à l’image qu’il estime être l’élément LCP et ne charge pas en différé les premières images du contenu, comme l’explique la note technique officielle. Les problèmes viennent donc souvent d’un thème, d’un constructeur de pages ou d’une extension d’optimisation qui réapplique le chargement différé à toutes les images.

Dans un thème, si l’image principale est affichée par votre propre code, vous pouvez forcer le bon comportement :

// Image à la une du haut de page : jamais en différé, priorité haute.
echo wp_get_attachment_image(
	get_post_thumbnail_id(),
	'large',
	false,
	array(
		'loading'       => false,
		'fetchpriority' => 'high',
	)
);

Avec LiteSpeed Cache, excluez le logo et l’image d’en-tête du chargement différé, ou activez les images de la fenêtre d’affichage (VPI). Évitez les sliders en haut de page : leur première image, souvent insérée par JavaScript, est découverte tard.

3. Durée de chargement : allégez l’image

Servez l’image à la taille réellement affichée (WordPress génère plusieurs tailles et un attribut srcset pour cela), compressée et dans un format moderne comme WebP ou AVIF.

4. Délai de rendu : libérez le chemin d’affichage

Si l’image est téléchargée mais s’affiche tard, cherchez ce qui bloque le rendu : fichiers CSS volumineux dans le <head>, scripts synchrones, animation d’apparition au défilement appliquée au bloc du haut, ou titre LCP qui attend une police web. Minifiez et chargez le JavaScript en différé, et réservez les animations aux éléments situés plus bas.

Comment corriger un INP trop élevé ?

Un INP élevé signifie que le navigateur met trop de temps à réagir à un clic, une saisie ou un appui. Trouvez l’interaction lente, mesurez ses trois phases (délai d’entrée, traitement, présentation), puis réduisez le JavaScript qui occupe le fil principal : extensions et constructeurs lourds, scripts tiers, gestionnaires d’événements coûteux.

L’INP retient l’interaction la plus lente de la visite (en ignorant la pire pour chaque tranche de 50 interactions sur les pages très interactives). Selon le guide Optimize INP, chaque interaction se décompose ainsi :

Pour trouver l’interaction coupable, ouvrez DevTools > Performance, puis interagissez avec la page : le journal des interactions affiche la durée de chacune et ses phases. Sur mobile, activez la limitation du processeur pour vous rapprocher d’un téléphone d’entrée de gamme. Pour savoir ce que vivent vos vrais visiteurs, la bibliothèque officielle web-vitals peut remonter la cause de chaque interaction lente :

import { onINP } from 'web-vitals/attribution';

onINP( ( metric ) => {
	// metric.value : durée en ms ; metric.attribution : élément ciblé et durée de chaque phase.
	console.log( 'INP', metric.value, metric.attribution );
} );

Toute tâche JavaScript de plus de 50 ms est une « tâche longue » qui bloque les interactions. Si vous développez votre thème, rendez la main au navigateur entre deux étapes d’un traitement long (scheduler.yield() quand il est pris en charge, sinon setTimeout). Avec des extensions du marché, le gain viendra surtout du tri.

Attention à l’option « retarder tout le JavaScript jusqu’à l’interaction » : elle flatte le score de laboratoire, mais peut concentrer le chargement des scripts sur le premier clic et dégrader l’INP réel. Testez-la page par page.

Comment éliminer les décalages de mise en page (CLS) ?

Le CLS mesure les éléments qui bougent sans action de l’utilisateur. Réservez la place de tout ce qui arrive après le premier affichage : dimensions des images et des iframes, hauteur des emplacements publicitaires et des bannières, polices dont les métriques sont proches de la police de secours. N’insérez jamais de contenu au-dessus de ce que le visiteur lit déjà.

Les causes typiques sous WordPress, d’après le guide Optimize CLS :

• Images et vidéos sans width et height : fréquent avec du HTML collé à la main ou certains blocs de constructeurs. WordPress ajoute les dimensions des images de la médiathèque ; LiteSpeed Cache propose « Ajouter les dimensions manquantes ».
• Bannière de cookies, barre d’annonce ou notification insérée en haut de page après le chargement. Affichez-la en superposition (position fixe) plutôt que de pousser le contenu.
• Publicités et intégrations (vidéos, cartes, publications de réseaux sociaux) : réservez leur hauteur en CSS avec min-height ou aspect-ratio.
• Polices web qui remplacent la police de secours avec une taille différente : utilisez size-adjust et les propriétés de surcharge des métriques, ou font-display: optional pour les polices non essentielles.
• Animations de propriétés de mise en page (top, height, margin) : préférez transform, qui ne provoque pas de décalage.

/* Réserver la place d'une intégration vidéo 16:9 (si votre thème ne le fait pas déjà) */
.wp-block-embed__wrapper {
	aspect-ratio: 16 / 9;
}

/* Police de secours ajustée pour limiter le décalage au chargement de la police web */
@font-face {
	font-family: "Inter Fallback";
	src: local("Arial");
	size-adjust: 107%;
}
body {
	font-family: "Inter", "Inter Fallback", sans-serif;
}

La valeur de size-adjust dépend de votre couple de polices. Pensez aussi au cache arrière/avant (bfcache) : une page restaurée depuis ce cache s’affiche sans décalage. Un gestionnaire unload ou un en-tête Cache-Control: no-store l’en empêchent ; vérifiez l’éligibilité dans DevTools > Application > Back/forward cache.

Quels réglages WordPress aident déjà les Core Web Vitals ?

Une installation à jour fait déjà beaucoup : chargement différé natif, priorité haute pour l’image LCP probable, sizes="auto" sur les images différées et chargement spéculatif des pages suivantes. Votre travail consiste surtout à ne pas défaire ces optimisations.

Pour aller plus loin sans code, l’extension officielle Performance Lab, maintenue par l’équipe performance de WordPress, propose des fonctions en test : formats d’image modernes ou Image Prioritizer (en bêta), qui priorise le véritable élément LCP à partir de mesures réalisées chez de vrais visiteurs. N’activez que les modules utiles.

Le chargement spéculatif se règle par un filtre. Par défaut, WordPress précharge prudemment ; sur un site bien mis en cache, vous pouvez tester un mode plus ambitieux, qui rend la page suivante quasi instantanée au prix de requêtes supplémentaires vers le serveur :

// functions.php d'un thème enfant ou extension maison
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
	if ( is_array( $config ) ) {
		$config['mode']      = 'prerender';
		$config['eagerness'] = 'moderate';
	}
	return $config;
} );

Comment vérifier que vos corrections ont fonctionné ?

Contrôlez d’abord en laboratoire et avec les métriques en direct de DevTools, sur les mêmes pages et dans les mêmes conditions qu’au départ. Puis, dans la Search Console, cliquez sur « Valider la correction » : Google surveille les URL concernées pendant 28 jours, le temps que les données de terrain se renouvellent.

Suivez cette checklist pour chaque correction :

1. Notez la valeur de départ de la métrique (terrain et laboratoire), sur mobile, pour un modèle de page précis (accueil, article, fiche produit).
2. Faites une seule modification à la fois et notez sa date.
3. Videz les caches (extension, serveur, CDN) puis rechargez deux fois la page pour mesurer en cache chaud.
4. Vérifiez visuellement la page (menu, formulaires, panier).
5. Lancez la validation dans la Search Console pour le groupe d’URL concerné.
6. Revenez quatre semaines plus tard et comparez les données de terrain dans PageSpeed Insights ou CrUX Vis.

Pour une liste plus large d’actions de vitesse, du cache aux tâches planifiées, consultez notre guide pour accélérer un site WordPress en 15 actions.

Le rôle de l’hébergement dans vos Core Web Vitals

Le TTFB représente à lui seul une large part du LCP, et il dépend d’abord du serveur. Chez Hosterwise, toutes les offres tournent sur des serveurs LiteSpeed avec le cache LSCache, HTTP/3 et des certificats SSL gratuits : les pages en cache sont servies sans exécuter PHP. Les offres Premium et Boost ajoutent des ressources pour les sites dynamiques comme les boutiques WooCommerce. Comparez les offres sur la page tarifs de l’hébergement WordPress.

Votre site est hébergé ailleurs ? Nous pouvons le transférer pour vous grâce à la migration gratuite, puis vous mesurez la différence sur vos propres Core Web Vitals.