Core Web Vitals + INP — impact réel sur le ranking en 2026

En mars 2024, Google a retiré le FID (First Input Delay) de ses signaux de classement et l’a remplacé par l’INP (Interaction to Next Paint). Ce changement est passé relativement inaperçu dans beaucoup d’équipes marketing, mais il a bouleversé la manière dont on diagnostique et améliore la performance d’un site. Deux ans plus tard, en 2026, les Core Web Vitals sont bien ancrés dans l’algorithme — et comprendre exactement ce qu’ils mesurent, comment les lire et comment les corriger est devenu une compétence SEO de base. Dans cet article, je vous explique tout, sans jargon superflu.

Les trois métriques Core Web Vitals — en clair

Google mesure l’expérience utilisateur à travers trois métriques principales. Chacune capture un aspect différent de la qualité perçue d’une page. Elles ne mesurent pas les performances en laboratoire, mais les données réelles collectées sur de vraies connexions, via le Chrome User Experience Report (CrUX).

LCP (Largest Contentful Paint) — le chargement

Le LCP mesure le temps nécessaire pour que l’élément visuel le plus grand visible à l’écran au moment du chargement soit rendu. Il s’agit le plus souvent d’une image hero, d’un bloc de titre volumineux ou d’une vidéo. C’est la métrique qui traduit le mieux la perception qu’a l’utilisateur de la vitesse de chargement : si le contenu principal met du temps à apparaître, la page semble lente, même si d’autres éléments secondaires se sont chargés rapidement.

INP (Interaction to Next Paint) — la réactivité (remplace FID depuis mars 2024)

L’INP est la nouveauté structurante de 2024. Là où le FID ne mesurait que le délai avant la première interaction, l’INP capture la latence de toutes les interactions significatives pendant la durée de vie de la page — clics, touches, saisies clavier. Il retient le 98e percentile de ces interactions, ce qui en fait un indicateur bien plus exigeant. Une page peut avoir un bon FID et un INP catastrophique si des scripts tiers alourdissent le fil JavaScript au fil de la navigation.

CLS (Cumulative Layout Shift) — la stabilité visuelle

Le CLS quantifie les déplacements visuels inattendus pendant le chargement — le texte qui saute quand une publicité s’insère, le bouton qui se déplace juste au moment où l’utilisateur va cliquer dessus. C’est une expérience frustrante que tout le monde a vécue, et Google la pénalise. Le score est calculé à partir du rapport entre la zone déplacée et la taille de la fenêtre, multiplié par la distance de déplacement.

Seuils 2026 et impact sur le ranking

Google publie trois zones pour chaque métrique. Les voici avec les valeurs actuelles :

Sur l’impact ranking, soyons précis : Google applique le signal à l’échelle de l’URL, pas du domaine. Une page qui passe dans la zone verte ne « booste » pas les autres pages du site. L’effet est donc granulaire. En pratique, sur des requêtes très compétitives où les pages en lice ont des profils éditoriaux proches, les Core Web Vitals peuvent faire basculer le classement. Sur des requêtes moins disputées, l’effet est moindre — mais l’expérience utilisateur, elle, s’améliore toujours, ce qui réduit le taux de rebond et augmente le temps passé, deux signaux comportementaux que Google observe.

Comment je mesure les Core Web Vitals

Quatre outils constituent ma boîte à outils standard, et je les utilise en combinaison — chacun apporte une couche d’information différente.

PageSpeed Insights est mon point de départ. Il combine données de terrain (CrUX, issues de Chrome sur de vraies connexions) et données de laboratoire (Lighthouse). C’est l’outil officiel de Google, accessible sans installation, et il donne une lecture mobile + desktop distincte. Je commence toujours par la version mobile, qui est celle que Google utilise pour l’indexation.

CrUX (Chrome User Experience Report) est la source brute des données de terrain. On peut l’interroger directement via l’API CrUX ou via la Search Console, onglet « Expérience de la page ». Il agrège les données sur 28 jours glissants — utile pour suivre l’évolution après une correction, à condition d’attendre ce délai avant de tirer des conclusions.

Lighthouse est l’outil de diagnostic en laboratoire, intégré dans Chrome DevTools. Il simule une connexion lente sur mobile (4G lent), ce qui permet de reproduire des conditions proches du pire cas. Je l’utilise pour identifier les causes racines d’un mauvais score — il liste les opportunités d’amélioration avec un gain estimé en secondes.

WebPageTest offre les tests les plus détaillés : waterfall de chargement, comparaison multi-navigateurs, tests depuis différentes localisations géographiques (y compris depuis des serveurs en Afrique). Je l’utilise quand je cherche à comprendre un problème de LCP lié à l’hébergement ou au CDN.

LCP — les 5 leviers d’amélioration les plus efficaces

Le LCP est souvent le plus actionnable des trois métriques. Voici les cinq interventions qui produisent les gains les plus rapides.

1. Convertir les images en WebP (ou AVIF). Une image JPEG de 400 Ko peut descendre à 80 Ko en WebP sans perte de qualité perceptible. Sur mobile, cela représente facilement 1 à 2 secondes de LCP en moins. WordPress génère désormais du WebP nativement depuis la version 6.1 ; sinon, le plugin ShortPixel ou Imagify font le travail.

2. Ajouter fetchpriority="high" et rel="preload" sur l’image LCP. Par défaut, le navigateur ne sait pas quelle image est la plus importante. En lui signalant explicitement l’élément LCP, on déclenche son téléchargement dès que possible, avant même que le CSS soit entièrement analysé.

3. Éliminer le CSS bloquant le rendu. Chaque feuille de style chargée en <link rel="stylesheet"> dans le <head> bloque l’affichage jusqu’à son téléchargement complet. Extraire le CSS critique (above-the-fold) et le placer inline, puis charger le reste de manière asynchrone, peut gagner plusieurs dixièmes de seconde.

4. Activer un cache serveur efficace. Un site WordPress sans cache génère une page HTML dynamiquement à chaque requête. Avec un plugin comme WP Rocket ou LiteSpeed Cache (si l’hébergeur tourne sur LiteSpeed), le HTML est mis en cache et servi directement — le temps de réponse serveur passe souvent de 600 ms à moins de 80 ms.

5. Utiliser un CDN avec edge nodes proches des utilisateurs. Si votre hébergeur est en Europe et vos visiteurs sont au Maroc, chaque requête traverse plusieurs milliers de kilomètres. Cloudflare gratuit suffit pour rapprocher les assets statiques. Pour aller plus loin, voir la section sur l’hébergement Maroc plus bas.

INP — pourquoi c’est devenu critique

L’INP est la métrique la moins bien comprise, et pourtant celle qui est la plus souvent dans la zone rouge sur les sites que j’audite. Le problème central est le main thread JavaScript blocking : quand le fil d’exécution principal du navigateur est occupé à traiter un script, il ne peut pas répondre aux interactions de l’utilisateur. Le délai visible s’accumule.

JavaScript bloat. Les sites qui ont accumulé des plugins, des widgets, des bibliothèques tierces sur plusieurs années se retrouvent avec 2 à 5 Mo de JavaScript à parser au chargement. Chaque kilooctet de JS coûte du temps de parsing CPU — et les appareils mobiles bas de gamme, très répandus au Maroc, sont particulièrement sensibles à cela. Un audit du bundle avec Chrome DevTools (onglet Coverage) permet d’identifier le code non utilisé — souvent 40 à 60 % du total.

Scripts tiers. Chatbots, pixels de conversion, scripts de A/B testing, widgets réseaux sociaux — chacun se charge indépendamment et peut déclencher de longs tasks sur le main thread. La règle que j’applique : charger les scripts tiers non critiques avec defer ou async, et décaler les moins urgents (widget de chat, scripts de heatmap) via un setTimeout ou une interaction utilisateur.

Choix de framework. React, Vue, Angular peuvent produire d’excellents INP ou de catastrophiques, selon la manière dont ils sont utilisés. L’hydratation côté client d’une application React volumineuse peut monopoliser le main thread pendant 3 à 5 secondes après le chargement. Les frameworks récents (Astro, Qwik, les React Server Components) ont été conçus précisément pour limiter ce phénomène via la partial hydration ou le streaming.

CLS — pièges fréquents

Le CLS est souvent le plus facile à corriger une fois les coupables identifiés. Les trois sources les plus communes :

Images sans dimensions explicites. Quand une image n’a pas d’attributs width et height dans le HTML, le navigateur ne peut pas réserver l’espace avant que l’image soit téléchargée. Le contenu sous l’image est repoussé vers le bas au moment du chargement. La correction est d’une ligne : ajouter width="800" height="450" (ou les dimensions réelles) à chaque balise <img>. WordPress le fait automatiquement depuis la version 5.5 pour les images insérées via l’éditeur — mais les thèmes anciens ou les constructeurs de pages peuvent contourner ce comportement.

Publicités et emplacements dynamiques. Les espaces publicitaires dont la taille n’est pas réservée à l’avance provoquent des shifts importants quand le réseau publicitaire répond. La solution est de définir une hauteur fixe minimale pour chaque emplacement via CSS, même si l’annonce n’est pas encore chargée.

Polices web avec substitution tardive (FOUT/FOLS). Quand une police personnalisée remplace une police système après le chargement, le rendu des textes peut changer de dimensions et déplacer le contenu. L’attribut font-display: optional ou swap combiné à un préchargement de la police via <link rel="preload"> limite ce phénomène. L’outil web.dev/cls donne les détails techniques complets.

Cas — comment on a passé un site WordPress de 2,8 s à 1,4 s de LCP

Un client dans le secteur des services professionnels à Casablanca m’a contacté après avoir constaté une dégradation de son trafic organique sans changement de contenu. PageSpeed Insights affichait un LCP de 2,8 s sur mobile — dans la zone orange — et un CLS de 0,18, légèrement au-dessus du seuil acceptable.

L’audit Lighthouse a identifié trois problèmes principaux : une image hero de 1,2 Mo en JPEG sans preload, un CSS bloquant le rendu provenant de deux plugins désactivés mais pas supprimés, et un widget de chat chargé en synchrone dès le démarrage de la page.

Les corrections ont pris une journée de travail. Compression WebP de l’image hero (passée à 180 Ko), ajout du fetchpriority="high", suppression des plugins orphelins et chargement différé du widget de chat via une interaction utilisateur. Résultat mesuré 28 jours après les corrections sur les données CrUX réelles : LCP à 1,4 s, CLS à 0,06. Le trafic organique a progressé de 14 % sur les deux mois suivants — difficile d’isoler l’effet CWV pur, mais la corrélation est nette.

Outils dev pour les Core Web Vitals

Chrome DevTools — onglet Performance. C’est l’outil de diagnostic le plus précis disponible sans installation supplémentaire. Il affiche le waterfall complet, les Long Tasks (tâches JavaScript bloquant le main thread plus de 50 ms), le moment exact du LCP et les sources de CLS. Pour l’INP, l’onglet Performance Insights (disponible depuis Chrome 98) identifie les interactions lentes et les scripts responsables.

web-vitals.js. Cette bibliothèque JavaScript open source, maintenue par l’équipe Chrome, permet de mesurer les Core Web Vitals directement sur les utilisateurs réels de votre site — et d’envoyer les données vers votre analytics (Google Analytics 4, Datadog, un endpoint custom). C’est ainsi que les équipes produit suivent l’évolution de leur INP en production, là où les outils de lab ne peuvent pas aller. La documentation complète est disponible sur web.dev/vitals.

Hébergement Maroc — impact direct sur les Core Web Vitals

La latence réseau entre le serveur et l’utilisateur a un impact direct sur le LCP, notamment le Time to First Byte (TTFB) — le temps que met le serveur à commencer à répondre. Sur un hébergement mutualisé en France avec un utilisateur à Casablanca, le TTFB seul peut atteindre 400 à 600 ms. C’est déjà une grande partie du budget LCP consommée avant même que le navigateur commence à rendre quoi que ce soit.

LiteSpeed. Les hébergeurs qui utilisent LiteSpeed Web Server (au lieu d’Apache ou Nginx) offrent nativement HTTP/3, une gestion du cache plus efficace et une meilleure compression. Le plugin LiteSpeed Cache pour WordPress est l’un des plus performants du marché — et gratuit. Si votre hébergeur marocain tourne sur LiteSpeed, c’est un avantage concret.

Cloudflare. Activer Cloudflare (plan gratuit) place un réseau de nœuds entre vos visiteurs et votre serveur. Les assets statiques (images, CSS, JS) sont mis en cache au niveau du nœud Cloudflare le plus proche — pour un visiteur à Marrakech, ce sera probablement un nœud en Europe du Sud ou en Afrique de l’Est selon la configuration. Le gain sur le LCP est mesurable et souvent significatif sans aucun changement de code.

CDN local. Pour les sites à trafic marocain majoritaire, un CDN avec des points de présence au Maghreb (Bunny CDN dispose de nœuds à Casablanca) réduit la latence de manière plus agressive que Cloudflare seul. Le coût est marginal (quelques euros par mois selon le trafic) et le gain en LCP peut atteindre 0,5 à 1 seconde sur mobile.

Pour aller plus loin sur l’audit technique complet de votre site, consultez ma page dédiée à l’audit SEO technique. Et pour comprendre le vocabulaire utilisé dans cet article, le lexique SEO donne les définitions de référence.

FAQ Core Web Vitals