Core Web Vitals : comprendre et corriger LCP, INP et CLS

Les Core Web Vitals sont trois mesures par lesquelles Google évalue l’expérience réelle de tes visiteurs : la vitesse d’affichage du contenu principal (LCP), la réactivité aux clics (INP) et la stabilité visuelle de la page (CLS). Elles ne sont pas calculées sur un test de laboratoire mais sur les visites réelles des utilisateurs de Chrome, ce qui change tout dans la façon de les corriger.

Ce guide explique ce que chaque mesure représente concrètement, quels seuils tenir, et par quoi commencer selon ce que ton site affiche aujourd’hui.

Ce que Google mesure exactement

Les Core Web Vitals sont un sous-ensemble des signaux d’expérience sur la page. Google en documente la définition complète et les seuils sur web.dev, sa ressource officielle sur les Web Vitals.

Trois mesures composent l’ensemble aujourd’hui, et elles répondent à trois questions que se pose un visiteur sans les formuler.

Est-ce que ça s’affiche ? C’est le LCP, Largest Contentful Paint.

Est-ce que ça réagit quand je touche ? C’est l’INP, Interaction to Next Paint.

Est-ce que ça arrête de bouger ? C’est le CLS, Cumulative Layout Shift.

Le point qui échappe à la plupart des gens : ces mesures viennent des visites réelles, collectées auprès des utilisateurs de Chrome qui ont accepté le partage de statistiques. Ce ne sont pas des tests simulés. Le score sur 100 que t’affiche un outil de test est une estimation en laboratoire, utile pour diagnostiquer, mais ce n’est pas ce que Google utilise pour évaluer ta page.

Les seuils à tenir, et la règle des 75 %

Mesure	Bon	À améliorer	Mauvais
LCP (affichage)	≤ 2,5 s	2,5 s à 4 s	> 4 s
INP (réactivité)	≤ 200 ms	200 ms à 500 ms	> 500 ms
CLS (stabilité)	≤ 0,1	0,1 à 0,25	> 0,25

Ces valeurs sont évaluées au 75ᵉ centile des visites, sur une fenêtre glissante de 28 jours. Autrement dit : il faut que trois visiteurs sur quatre soient sous le seuil pour que la page soit considérée comme bonne.

Ce choix n’est pas anodin. Une moyenne aurait masqué les visiteurs les plus mal servis, ceux sur téléphone d’entrée de gamme et connexion mobile encombrée. Au Maroc, où la navigation est massivement mobile, cette population n’est pas une marge : c’est souvent la majorité de ton trafic.

Un corollaire concret : optimiser pour ton propre ordinateur en fibre ne t’apprend rien. Il faut regarder les données de terrain, segment mobile.

LCP : le temps avant que le contenu principal s’affiche

Le LCP mesure le moment où le plus grand élément visible de la page finit de s’afficher. Dans neuf cas sur dix, cet élément est une image de couverture ou un grand titre.

Le seuil est de 2,5 secondes. Au-delà de 4 secondes, la page est classée mauvaise, et à ce stade tu perds déjà une part importante de tes visiteurs avant qu’ils aient vu quoi que ce soit.

Les causes que je rencontre, par ordre de fréquence.

Une image de couverture non optimisée. Le cas d’école : une photo exportée depuis un appareil ou une banque d’images, pesant plusieurs mégaoctets, affichée dans un bloc de 1 200 pixels de large. Le navigateur télécharge tout, puis réduit. La correction est immédiate : redimensionner à la taille réelle d’affichage et convertir en WebP. Sur un site de client, ce seul geste a fait passer une couverture de 3,4 Mo à 78 Ko.

Une image de couverture chargée en différé. Le chargement différé est excellent pour les images sous la ligne de flottaison, et catastrophique pour celle qui est visible d’emblée : elle est justement l’élément mesuré par le LCP. La première image doit être chargée en priorité, jamais en loading="lazy".

Un serveur lent à répondre. Si le serveur met une seconde à envoyer le premier octet, le LCP part avec une seconde de retard qu’aucune optimisation d’image ne rattrapera. C’est un sujet d’hébergement, traité dans le comparatif des hébergements web au Maroc.

Des polices web bloquantes. Une police chargée sans stratégie d’affichage retarde le rendu du texte. La parade tient en une propriété CSS, font-display: swap, qui affiche immédiatement une police de secours.

INP : la réactivité, et pourquoi c’est plus sévère qu’avant

L’INP a remplacé le FID en mars 2024, et le changement est bien plus profond qu’un renommage.

Le FID ne mesurait que le délai de la première interaction, et seulement le délai avant traitement. Un site pouvait afficher un FID excellent tout en étant pénible à utiliser dix secondes plus tard. L’INP mesure la latence de toutes les interactions de la visite, du clic jusqu’à l’affichage de la réponse à l’écran, et retient la pire. Beaucoup de sites qui affichaient un FID vert ont découvert un INP orange.

Google détaille la mesure et les méthodes de diagnostic dans sa documentation sur l’INP.

Le seuil est de 200 millisecondes. Au-delà, l’utilisateur perçoit un décalage entre son geste et la réaction de l’interface.

Les causes principales sont presque toujours du JavaScript.

Trop de scripts tiers. Chaque outil ajouté, mesure d’audience, chat en ligne, pixel publicitaire, bandeau de consentement, occupe le fil d’exécution principal du navigateur. Pendant qu’il travaille, l’interface ne répond pas. La question à se poser pour chaque script est simple : est-ce que je saurais dire ce qu’il m’apporte ce mois-ci ?

Des extensions WordPress qui font trop. Un constructeur de pages lourd charge son moteur d’animation sur toutes les pages, y compris celles qui n’en ont aucune.

Des traitements longs au clic. Un filtre de catalogue qui recalcule tout à chaque frappe, une galerie qui redimensionne des images en JavaScript.

Sur téléphone, ces coûts sont multipliés. Un appareil d’entrée de gamme met plusieurs fois plus de temps à exécuter le même code qu’un ordinateur récent, et c’est exactement le profil de la majorité des visiteurs au Maroc.

Comment identifier le script fautif

La méthode que j’utilise tient en quatre étapes, et elle marche sans outil payant.

Ouvre la page dans Chrome, en navigation privée pour écarter les extensions du navigateur, qui faussent complètement la mesure. Ouvre les outils de développement, onglet Performance, et active la limitation du processeur à quatre ou six fois plus lent : tu simules ainsi un téléphone moyen depuis ton ordinateur.

Lance l’enregistrement, puis interagis normalement avec la page : ouvre le menu, clique sur un filtre, fais défiler. Arrête l’enregistrement.

Cherche ensuite les longues barres jaunes dans la piste principale. Chaque barre est une tâche qui a monopolisé le fil d’exécution. Au-dessus de 50 millisecondes, une tâche est déjà longue. Clique dessus : Chrome te dit quel fichier JavaScript l’a déclenchée.

Neuf fois sur dix, le nom du fichier révèle immédiatement le coupable, et c’est presque toujours un outil ajouté par quelqu’un qui n’est plus là.

CLS : la stabilité visuelle, le plus facile à corriger

Le CLS mesure de combien les éléments de la page se déplacent pendant le chargement. Tu connais l’expérience : tu vas cliquer sur un lien, une bannière s’insère au-dessus, et ton doigt atterrit sur autre chose.

C’est un score sans unité, et le seuil est de 0,1. C’est aussi, de très loin, la mesure la plus simple à corriger, et la plus souvent laissée en l’état.

Les images sans dimensions déclarées sont la première cause. Si le HTML ne dit pas quelle taille fait l’image, le navigateur ne peut pas réserver la place : il affiche le texte, télécharge l’image, puis pousse tout vers le bas. La correction consiste à écrire les attributs width et height sur chaque balise img. Le navigateur calcule alors le ratio et réserve le bon espace avant même d’avoir l’image.

C’est un travail fastidieux à la main, et c’est pour ça qu’il n’est jamais fait. Sur ce site, je l’ai résolu au build : un greffon lit la taille réelle de chaque image au moment de la génération et pose les attributs automatiquement. Trente-trois images ont été corrigées d’un coup, et les articles futurs sont couverts sans que j’aie à y penser. C’est le genre d’automatisation qui vaut mieux qu’une checklist qu’on oubliera.

Les bandeaux insérés après coup viennent ensuite : bandeau cookies, message promotionnel, barre d’annonce. Insérés en haut de page après le chargement, ils décalent tout le contenu. La bonne pratique est de les afficher en superposition, sans déplacer le flux, ou de réserver leur hauteur dès le départ.

Les polices web provoquent un décalage plus discret : le texte s’affiche dans une police de secours, puis bascule vers la police finale qui n’a ni la même largeur ni la même hauteur de ligne. Choisir une police de secours aux métriques proches réduit fortement l’effet.

Les publicités et contenus embarqués de taille variable, enfin, doivent avoir un conteneur de hauteur fixe.

Où lire tes vrais chiffres

Trois outils, trois usages différents, et il faut savoir lequel dit quoi.

PageSpeed Insights est le point d’entrée. Il affiche en haut les données de terrain si ton site a assez de trafic, et en dessous l’analyse en laboratoire avec les recommandations. Tu le trouves sur pagespeed.web.dev. Regarde d’abord le bloc du haut.

Search Console, dans son rapport « Signaux Web essentiels », montre l’évolution sur l’ensemble du site, regroupée par types de pages similaires. C’est là qu’on voit si une correction a produit son effet, et c’est le seul endroit qui donne une vue globale plutôt que page par page. Le fonctionnement de l’outil est détaillé dans le guide complet de Google Search Console.

Les outils de développement de Chrome, onglet Performance, servent au diagnostic fin quand on sait déjà quoi chercher. C’est là qu’on identifie le script précis qui bloque le fil principal.

Un site récent ou à faible trafic n’aura pas de données de terrain. Dans ce cas, tu travailles sur les mesures de laboratoire en sachant qu’elles sont indicatives, et tu attends d’avoir du trafic pour valider.

Les mesures qu’on confond avec les Core Web Vitals

Les outils affichent une dizaine de valeurs, et trois d’entre elles sont régulièrement prises pour des Core Web Vitals alors qu’elles n’en sont pas. Elles restent utiles au diagnostic, mais elles ne comptent pas pour Google.

Le TTFB, ou Time To First Byte, mesure le délai avant que le serveur envoie le premier octet de la page. Ce n’est pas un Core Web Vital, mais c’est le socle du LCP : tout retard ici se répercute intégralement. Un TTFB supérieur à 800 millisecondes signale un problème d’hébergement, de base de données ou de cache, jamais un problème d’image.

Le FCP, ou First Contentful Paint, marque le moment où le tout premier élément s’affiche, souvent un simple titre. Il rassure sur la perception de rapidité, mais il ne dit rien de l’utilisabilité : une page peut afficher un titre en une demi-seconde et rester vide pendant trois secondes de plus.

Le TBT, ou Total Blocking Time, additionne le temps pendant lequel le fil principal est resté bloqué au chargement. Il n’est mesuré qu’en laboratoire, jamais sur les visites réelles, mais il est le meilleur substitut à l’INP quand tu n’as pas encore de données de terrain. Un TBT élevé annonce presque toujours un INP dégradé.

En pratique, je les utilise dans cet ordre : le TTFB pour savoir si le problème est côté serveur, le TBT pour savoir si le problème est côté JavaScript, et les trois vraies mesures pour savoir où j’en suis vraiment.

L’ordre dans lequel je corrige

Après un certain nombre d’audits, j’ai fini par toujours procéder dans le même ordre, parce que c’est celui du meilleur rapport effort sur résultat.

1. Le CLS d’abord. Les corrections sont mécaniques, le risque de casser quelque chose est faible, et le gain est immédiat. Dimensions sur les images, hauteur réservée pour les bandeaux.
2. L’image de couverture ensuite. Redimensionner, convertir en WebP, retirer le chargement différé sur la première image. C’est souvent l’essentiel du LCP.
3. Le tri des scripts tiers. Lister tout ce qui se charge, et supprimer ce dont personne ne se sert. J’ai déjà retiré d’un site un outil de mesure d’audience installé trois ans plus tôt et que plus personne ne consultait.
4. L’hébergement, si le temps de réponse serveur reste élevé. C’est le changement le plus lourd, donc le dernier.
5. Les polices, en dernier, parce que le gain est réel mais modeste.

Si tu es sur WordPress et que ton site est en production avec du trafic, ne touche pas aux extensions de cache et d’optimisation au hasard : c’est la source d’ennuis la plus fréquente que je répare. Une sauvegarde avant, une modification à la fois, et une mesure entre chaque. Le diagnostic complet d’un site WordPress lent détaille la procédure pas à pas.

Le cas WordPress : ce qui plombe les mesures

WordPress n’est pas lent par nature. Ce qui le rend lent, c’est l’accumulation, et elle suit toujours le même scénario.

Le constructeur de pages charge son moteur complet sur chaque page, y compris celles construites en blocs natifs. C’est souvent le premier poste de JavaScript d’un site WordPress, et il pèse directement sur l’INP.

Les extensions oubliées. Sur un site que j’ai repris, dix-neuf extensions étaient actives ; sept servaient réellement. Chaque extension inactive mais installée ne coûte rien, mais chaque extension active charge ses fichiers sur toutes les pages, même celles qui n’utilisent pas la fonctionnalité.

Les sliders et carrousels de la page d’accueil. Trois images en plein écran qui défilent automatiquement, c’est trois fois le poids d’une image de couverture, plus une bibliothèque d’animation. Le LCP est mécaniquement mauvais, et personne ne regarde les diapositives 2 et 3.

Les polices multipliées. Un thème charge trois polices, le constructeur en ajoute deux, une extension une sixième. Chaque police est un téléchargement bloquant.

Les images téléversées telles quelles. Une photo de 4 000 pixels de large affichée dans une colonne de 400 pixels reste une photo de 4 000 pixels à télécharger si la génération des tailles intermédiaires est mal configurée.

La bonne nouvelle est que ces cinq points se corrigent sans toucher au code, et qu’ils représentent l’essentiel du gain sur un site WordPress classique.

Faut-il un CDN quand tes visiteurs sont au Maroc ?

La question revient systématiquement, et la réponse dépend d’où sont réellement tes visiteurs.

Un réseau de diffusion de contenu, ou CDN, sert tes fichiers depuis un serveur proche du visiteur plutôt que depuis ton serveur d’origine. Le gain est un temps de latence réduit, donc un LCP plus rapide.

Si ton site est hébergé en Europe et que tes visiteurs sont au Maroc, la distance ajoute un délai à chaque requête. Un CDN avec un point de présence proche réduit ce délai de façon mesurable sur les images et les fichiers statiques.

Si ton site est hébergé au Maroc et que tes visiteurs sont au Maroc, le gain est beaucoup plus faible, et parfois nul.

Le point que peu de gens vérifient : un CDN accélère les fichiers statiques, pas la génération de la page. Si ton serveur met une seconde à produire le HTML parce que la base de données est lente, aucun CDN ne le rattrapera. Regarde d’abord ton temps de réponse serveur, et ne prends un CDN qu’une fois ce point réglé.

Ce que les Core Web Vitals ne feront jamais pour toi

Il faut être honnête sur le poids réel de ces mesures, parce que beaucoup de prestataires les vendent comme la solution au référencement.

Google intègre les signaux d’expérience sur la page à son classement, et le documente dans ses consignes sur l’expérience sur la page. Mais il précise lui-même que la pertinence du contenu prime. Une page excellente sur les trois mesures avec un contenu creux ne dépassera pas une page moyenne techniquement avec un contenu de référence.

Les Core Web Vitals servent de départage entre des pages comparables. C’est un avantage réel, mais marginal.

Le vrai bénéfice est ailleurs, et il est plus grand que le référencement : un visiteur qui attend s’en va. Sur un site marchand, chaque seconde de chargement supplémentaire coûte des commandes. Sur un site de services, elle coûte des demandes de devis. Ce n’est pas Google que tu optimises, ce sont tes revenus.

Les erreurs qui font perdre du temps

Courir après le score sur 100. Passer de 60 à 90 change l’expérience. Passer de 90 à 100 coûte souvent autant d’effort pour un gain que personne ne perçoit.

Tester une seule page. La page d’accueil est rarement représentative. Teste aussi une fiche produit, un article, une page de catégorie : ce sont elles qui reçoivent le trafic de recherche.

Empiler les extensions d’optimisation. Deux extensions de cache qui tournent en même temps se marchent dessus et produisent des bugs difficiles à diagnostiquer. Une seule, bien réglée.

Mesurer trop tôt après une correction. La fenêtre est de 28 jours. Modifier tous les deux jours revient à ne jamais savoir ce qui a marché.

Ignorer la colonne mobile. C’est celle qui compte pour l’indexation, et c’est presque toujours la plus mauvaise.

Par où commencer aujourd’hui

Ouvre PageSpeed Insights, entre l’adresse d’une page qui reçoit du trafic, et regarde uniquement le bloc de données de terrain, colonne mobile. Note les trois valeurs.

Si le CLS dépasse 0,1, commence par là : c’est une demi-journée de travail pour un site classique, et le résultat est visible. Si le LCP dépasse 2,5 secondes, regarde le poids de ton image de couverture avant toute autre chose.

Et si les trois mesures sont dans le rouge sur un site qui tourne déjà avec des clients, il vaut mieux établir un ordre de priorité plutôt que de tout ouvrir en même temps. Décris-moi ta situation, je regarde les données de terrain de ton site et je te dis lesquels des trois chantiers valent réellement l’effort dans ton cas.