Core Web Vitals : améliorer LCP, CLS et INP sans tout refaire

Un score PageSpeed de 38 sur mobile, trois indicateurs au rouge dans la Search Console, et un client qui demande pourquoi son concurrent se positionne mieux avec un contenu moins riche. C’est le scénario que je rencontre au moins deux fois par mois. La bonne nouvelle : dans la majorité des cas, on passe au vert sur les trois Core Web Vitals en quelques interventions ciblées, sans refonte complète du site.

Comprendre les trois métriques en 2026

Google évalue l’expérience utilisateur de chaque page à travers trois signaux regroupés sous le nom de Core Web Vitals. Depuis mars 2024, la métrique INP (Interaction to Next Paint) a remplacé le FID (First Input Delay). Ces trois indicateurs sont intégrés au système de classement de Google, comme le confirme la documentation officielle de Google Search Central.

Le LCP (Largest Contentful Paint) mesure le temps nécessaire pour afficher le plus grand élément visible dans la fenêtre : souvent une image hero, une vidéo ou un bloc de texte principal. Le seuil à respecter est 2,5 secondes maximum.

Le CLS (Cumulative Layout Shift) quantifie les décalages visuels inattendus pendant le chargement. Une publicité qui pousse le texte, une police web qui arrive en retard et modifie la taille des lignes, une image sans dimensions explicites : chaque saut compte. Le seuil acceptable est 0,1 maximum.

L’INP mesure la latence entre une interaction utilisateur (clic, pression de touche, appui tactile) et la mise à jour visuelle suivante. Contrairement au FID qui ne regardait que la première interaction, l’INP prend en compte toutes les interactions de la session et retient la pire (au 98e percentile). Le seuil est de 200 millisecondes maximum.

Pour qu’une page soit considérée comme ayant de bons Core Web Vitals, elle doit atteindre le seuil « bon » sur les trois métriques simultanément, pour au moins 75 % des visites réelles.

Mesurer avant d’agir : les bons outils et les bons chiffres

Avant de toucher une seule ligne de code, il faut savoir exactement où le site échoue. Deux types de données existent et ne racontent pas la même histoire.

Les données de laboratoire (Lighthouse, PageSpeed Insights en mode labo, WebPageTest) simulent un chargement sur un appareil et une connexion standardisés. Elles sont reproductibles, pratiques pour tester un correctif, mais elles ne reflètent pas la diversité des appareils réels. L’INP, par exemple, n’apparaît pas en labo puisqu’il nécessite de vraies interactions.

Les données terrain (Chrome User Experience Report, abrégé CrUX) agrègent les mesures de vrais utilisateurs Chrome sur 28 jours glissants. Ce sont ces données que Google utilise pour le classement. Si le rapport d’expérience utilisateur de la Search Console affiche « Évaluation Core Web Vitals : échec », c’est le CrUX qui parle.

Mon flux de travail habituel :

1. Ouvrir le rapport Core Web Vitals dans la Google Search Console pour identifier les URL ou groupes d’URL problématiques
2. Passer chaque URL critique dans PageSpeed Insights pour lire les données CrUX (section « Découvrez l’expérience de vos utilisateurs réels ») et les recommandations Lighthouse
3. Utiliser l’onglet Performance des DevTools Chrome pour enregistrer un profil de chargement et repérer les tâches longues qui bloquent le thread principal
4. Installer l’extension Web Vitals pour Chrome afin de voir les métriques en temps réel pendant la navigation

L’erreur classique est de se focaliser uniquement sur le score Lighthouse global. Ce score est un indice utile, mais un site peut afficher 92/100 en labo et échouer sur le terrain parce que 30 % de son audience navigue sur des smartphones d’entrée de gamme avec une connexion 4G instable. C’est la raison pour laquelle je consulte toujours les données CrUX avant de prioriser les corrections. Pour aller plus loin sur la lecture des données Search Console, j’ai détaillé la méthode dans mon guide sur la détection de cannibalisation dans la Search Console.

Améliorer le LCP : charger l’élément principal plus vite

Le LCP est la métrique la plus intuitive : le visiteur voit-il rapidement le contenu principal ? En pratique, l’élément LCP est presque toujours une image hero, une bannière vidéo ou, sur les pages de blog, le premier gros bloc de texte visible.

Identifier l’élément LCP

Dans les DevTools Chrome, onglet Performance, lancez un enregistrement de chargement puis cherchez le marqueur « LCP » dans la timeline. Cliquez dessus pour voir quel élément DOM est concerné. Sur un site e-commerce, c’est souvent la photo produit. Sur une landing page, le visuel d’en-tête.

Les quatre leviers principaux

1. Optimiser l’image LCP. Convertissez-la en WebP ou AVIF (gain de 25 à 50 % par rapport au JPEG). Servez des tailles adaptées via l’attribut srcset. Sur WordPress, des extensions comme Imagify ou ShortPixel automatisent la conversion. Sur un site sur mesure, un pipeline de build avec Sharp ou squoosh-cli fait le travail.

2. Précharger la ressource critique. Ajoutez un <link rel="preload"> dans le <head> pour l’image LCP. Cela indique au navigateur de la télécharger en priorité, avant même que le parser CSS ne la découvre :

<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">

L’attribut fetchpriority="high" renforce encore la priorité. Pour les images au-dessous de la ligne de flottaison, utilisez au contraire loading="lazy" afin de ne pas voler de la bande passante à l’élément LCP.

3. Réduire le temps serveur (TTFB). Un LCP ne peut pas être bon si le serveur met déjà 1,5 seconde à répondre. Vérifiez votre Time To First Byte : s’il dépasse 800 ms, regardez du côté du cache serveur, de la configuration PHP (OPcache, version 8.2+), ou du choix d’hébergement. J’ai comparé les différences concrètes entre plateformes dans l’article sur WordPress ou développement sur mesure.

4. Supprimer les ressources bloquantes. Les fichiers CSS et JavaScript synchrones dans le <head> empêchent le rendu tant qu’ils ne sont pas téléchargés et exécutés. Inlinez le CSS critique (celui nécessaire au contenu au-dessus de la ligne de flottaison) et différez le reste avec media="print" onload="this.media='all'". Pour le JavaScript, utilisez defer ou async selon le cas.

Sur un projet client récent (site vitrine WordPress avec un thème custom), ces quatre actions ont fait passer le LCP mobile de 4,8 s à 1,9 s en trois jours de travail.

Réduire le CLS : stabiliser la mise en page

Le CLS est souvent la métrique la plus frustrante parce que ses causes sont invisibles en labo et n’apparaissent que sur le terrain. Un score CLS de 0,35 ne signifie pas que la page est lente : il signifie qu’elle bouge pendant que le visiteur essaie de lire ou de cliquer.

Les causes les plus courantes

Images et vidéos sans dimensions. Si le navigateur ne connaît pas la taille d’une image avant de la charger, il réserve 0 pixel de hauteur, puis redessine la page quand l’image arrive. La solution est triviale : ajoutez toujours width et height dans la balise <img>, ou utilisez la propriété CSS aspect-ratio.

Polices web (FOUT/FOIT). Quand une police Google Fonts ou auto-hébergée arrive après le texte, le navigateur recalcule la mise en page. Utilisez font-display: swap pour afficher immédiatement une police de remplacement, et préchargez la police critique :

<link rel="preload" as="font" href="/fonts/inter.woff2" type="font/woff2" crossorigin>

Publicités et iframes sans espace réservé. Les bannières publicitaires injectées dynamiquement sont responsables d’une part importante du CLS sur les sites éditoriaux. Réservez un conteneur de taille fixe avec min-height avant le chargement de l’ad.

Contenu injecté dynamiquement. Les bandeaux cookies, les barres de notification, les pop-ins de chat : tout élément qui apparaît en poussant le contenu vers le bas génère du CLS. Préférez les overlays (position fixe) qui se superposent sans déplacer le reste de la page.

Pour diagnostiquer précisément les décalages, l’onglet Performance des DevTools affiche chaque « Layout Shift » avec un score et l’élément DOM responsable. La documentation web.dev sur le CLS détaille également les méthodes de débogage avancées.

Optimiser l’INP : rendre chaque interaction fluide

L’INP est la métrique la moins bien comprise parce qu’elle est la plus récente. Elle mesure le délai entre le moment où l’utilisateur interagit (clic, touche, appui) et le moment où le navigateur peint la réponse visuelle. Un INP supérieur à 200 ms donne une sensation de lenteur perceptible.

Ce qui bloque le thread principal

Le navigateur exécute JavaScript et met à jour l’interface sur un seul thread. Toute tâche JavaScript qui dure plus de 50 ms est considérée comme une « tâche longue » et bloque les interactions en attente. Les coupables habituels :

• Les scripts tiers (analytics, chat en direct, pixels publicitaires) qui s’exécutent au chargement et monopolisent le thread
• Les gestionnaires d’événements lourds : un onclick qui recalcule un tableau de 500 lignes côté client
• Les hydratations massives sur les frameworks JavaScript (React, Vue, Next.js) qui rendent toute la page interactive d’un coup

Les correctifs qui fonctionnent

Différer les scripts tiers. Chargez les scripts non essentiels après l’interaction initiale. Un gestionnaire de tags (Google Tag Manager) bien configuré permet de retarder le déclenchement des balises non critiques de 3 à 5 secondes après le chargement.

Découper les tâches longues. Utilisez requestIdleCallback ou scheduler.yield() (API Scheduler) pour fractionner un traitement lourd en morceaux de moins de 50 ms. Le thread principal reste disponible entre chaque morceau pour traiter les interactions.

Réduire la taille du DOM. Un DOM de 3 000 nœuds rend chaque recalcul de mise en page plus coûteux. Supprimez les <div> inutiles, simplifiez les composants imbriqués. Sur WordPress, certains constructeurs de pages (Elementor, Divi) génèrent des DOM de 5 000 à 8 000 nœuds : c’est un frein direct à l’INP.

Utiliser le rendu côté serveur ou les îlots d’interactivité. Sur les frameworks modernes, des approches comme les Server Components (Next.js) ou les « islands » (Astro) permettent de n’hydrater que les composants réellement interactifs, au lieu de l’arbre entier.

L’INP est aussi la métrique qui bénéficie le plus d’une bonne structure de page. Un maillage interne bien pensé réduit le nombre de scripts nécessaires par page : j’explique la logique de structure en silo pour le maillage interne dans un article dédié.

Les erreurs fréquentes qui plombent les scores

Après avoir audité plus de 80 sites sur ces métriques, voici les erreurs que je retrouve le plus souvent :

Tout miser sur un plugin de cache. Un plugin de cache (WP Rocket, W3 Total Cache) améliore le TTFB et aide le LCP, mais il ne corrige ni le CLS ni l’INP. J’ai vu des sites avec WP Rocket activé et un CLS de 0,42 parce que les images n’avaient pas de dimensions. Le cache est nécessaire mais insuffisant seul.

Lazy-loader l’image LCP. Mettre loading="lazy" sur l’image hero est contre-productif : le navigateur retarde son chargement au lieu de le prioriser. L’image au-dessus de la ligne de flottaison doit être chargée en priorité, pas différée.

Ignorer le mobile. Les Core Web Vitals sont évalués séparément pour mobile et desktop. Or, Google utilise l’indexation mobile-first. Un LCP de 2 s sur desktop et 5 s sur mobile signifie que la page échoue pour le classement. Testez toujours en priorité sur un profil mobile (Moto G Power, 4G lente).

Empiler les scripts tiers. Google Analytics, Google Tag Manager, un pixel Facebook, un chat Intercom, un outil de heatmap, un bandeau cookie, un widget d’avis : chaque script ajoute du travail au thread principal. Sur un site vitrine, trois ou quatre scripts suffisent. La question à se poser avant d’ajouter un script : « Est-ce que je consulte réellement ces données chaque semaine ? »

Optimiser en labo sans vérifier le terrain. Les scores Lighthouse sont satisfaisants, mais le rapport CrUX reste au rouge. Cela arrive quand le labo teste sur une connexion rapide et un appareil puissant, alors que l’audience réelle est sur mobile bas de gamme. Le choix d’un CMS ou d’une plateforme adaptée joue aussi un rôle dans la performance de base.

Plan d’action concret en cinq étapes

Voici l’ordre dans lequel j’interviens sur un site dont les Core Web Vitals sont au rouge. Cet ordre est important : chaque étape prépare la suivante.

Étape 1 : auditer avec les données terrain. Ouvrez la Search Console, section « Expérience », puis « Core Web Vitals ». Notez combien d’URL sont en « Mauvais » et « À améliorer » pour mobile et desktop. Croisez avec PageSpeed Insights pour avoir le détail par métrique. Cela prend 30 minutes et donne la feuille de route.

Étape 2 : traiter le LCP en priorité. C’est la métrique qui a le plus d’impact perçu par l’utilisateur et la plus facile à corriger. Convertissez les images en WebP, ajoutez le preload pour l’image hero, activez le cache serveur, inlinez le CSS critique. Comptez 2 à 4 heures sur un site WordPress, une journée sur un site custom.

Étape 3 : stabiliser le CLS. Ajoutez les dimensions à toutes les images et vidéos, préchargez la police principale, réservez l’espace des publicités. Passez les bandeaux cookies et notifications en position fixe (overlay). Comptez 1 à 3 heures.

Étape 4 : réduire l’INP. Auditez les scripts tiers, différez tout ce qui n’est pas critique, découpez les tâches longues. Si le site utilise un constructeur de pages lourd, envisagez de migrer les pages clés vers du HTML plus léger. Comptez une demi-journée à deux jours selon la complexité.

Étape 5 : surveiller pendant 28 jours. Les données CrUX se mettent à jour sur une fenêtre glissante de 28 jours. Après vos corrections, il faut attendre ce délai pour voir l’impact dans la Search Console. Pendant cette période, surveillez avec l’extension Web Vitals et PageSpeed Insights pour vérifier que les corrections tiennent.

Ce processus complet correspond à ce que je recommande quand on structure un chantier SEO depuis zéro. J’ai détaillé l’ordre global des priorités dans mon guide SEO pour ceux qui partent de zéro.

Impact SEO réel des Core Web Vitals

Il faut être honnête : les Core Web Vitals sont un signal de classement parmi d’autres, et pas le plus puissant. Google l’a dit explicitement : la pertinence du contenu reste le facteur dominant. Un article parfaitement optimisé pour le LCP ne rattrapera jamais un contenu médiocre face à un concurrent qui répond mieux à l’intention de recherche.

Cela dit, les Core Web Vitals font la différence dans deux situations précises :

Quand deux pages sont à égalité de pertinence. Sur des requêtes concurrentielles où plusieurs résultats ont un contenu de qualité comparable, les signaux d’expérience de page (dont les Core Web Vitals) servent de départage. C’est là que passer de « mauvais » à « bon » peut faire gagner une ou deux positions.

Quand le taux de rebond explose. Un LCP de 6 secondes sur mobile fait fuir 40 à 50 % des visiteurs avant même qu’ils voient le contenu. Le signal indirect (rebond, temps passé, pogo-sticking) pénalise davantage que le signal technique direct. En améliorant la vitesse, on retient les visiteurs, ce qui améliore les signaux comportementaux.

Sur un site e-commerce dont j’ai optimisé les Core Web Vitals début 2025, le passage des trois métriques au vert a coïncidé avec une hausse de 12 % du taux de conversion mobile et une amélioration moyenne de 3 positions sur les requêtes produit. Corrélation ou causalité ? Difficile à isoler, mais la tendance est constante sur les projets que j’accompagne.

En parallèle, un bon title et une meta description bien rédigés maximisent le taux de clic une fois la position acquise. Les Core Web Vitals vous aident à monter ; les balises title et description vous aident à capter le clic.

Si vous envisagez une refonte pour résoudre des problèmes de performance, assurez-vous de suivre la checklist des redirections pour ne pas perdre votre trafic. Et si vous hésitez à refondre, consultez d’abord les signaux qui montrent qu’il est temps de refondre : dans beaucoup de cas, une optimisation ciblée des Core Web Vitals suffit à repousser la refonte de deux ou trois ans.