Un client potentiel ouvre votre site sur son téléphone. La photo d'accueil tarde à apparaître, le bouton « Appeler » ne réagit pas au premier essai, puis le texte descend au moment où il voulait toucher un lien. Google mesure ces trois désagréments avec trois indicateurs, les Core Web Vitals (parfois traduits par « signaux web essentiels ») : le LCP, l'INP et le CLS.
La réponse courte : le LCP mesure l'affichage du contenu principal, l'INP la réactivité aux clics et le CLS la stabilité de la page. Google les considère comme bons jusqu'à 2,5 secondes, 200 millisecondes et 0,1, mesurés sur de vrais visiteurs. Vous pouvez vérifier les vôtres gratuitement avec PageSpeed Insights et la Search Console.
Ce que mesurent le LCP, l'INP et le CLS
LCP : l'affichage du contenu principal
Le Largest Contentful Paint indique le moment où le plus grand élément visible à l'écran a fini de s'afficher : souvent l'image d'accueil, une vidéo ou un grand bloc de texte. Pensez à une boutique le matin : l'enseigne allumée ne suffit pas, le client attend que le rideau soit levé pour voir la vitrine. Le LCP chronomètre la levée du rideau.
INP : la réactivité aux clics
L'Interaction to Next Paint mesure le délai entre une action du visiteur (clic, pression sur l'écran, touche du clavier) et la réponse visible de la page. Il observe toutes les interactions de la visite et retient en général la plus lente ; le défilement ne compte pas. Il a remplacé l'ancien indicateur FID le 12 mars 2024. L'analogie : le bouton d'un ascenseur doit s'allumer dès que vous appuyez, même si la cabine tarde ; sinon, vous appuyez de nouveau.
CLS : la stabilité de la page
Le Cumulative Layout Shift mesure les déplacements inattendus du contenu. C'est un score sans unité : plus il est élevé, plus la page bouge. Les décalages survenant juste après un clic du visiteur ne comptent pas. Imaginez un serveur qui glisse une autre carte sous votre doigt au moment où vous désignez un plat : vous commandez autre chose.
Les seuils officiels et la règle du 75e percentile
Google classe chaque mesure en trois catégories, que la Search Console appelle « Bon », « Amélioration nécessaire » et « Médiocre ». Les seuils publiés sur web.dev sont les suivants :
- LCP : bon jusqu'à 2,5 secondes, médiocre au-delà de 4 secondes.
- INP : bon jusqu'à 200 millisecondes, médiocre au-delà de 500 millisecondes.
- CLS : bon jusqu'à 0,1, médiocre au-delà de 0,25.
Entre les deux, la mesure est « à améliorer ». Ces seuils s'appliquent au 75e percentile des visites, séparément pour le mobile et l'ordinateur : pour un LCP jugé bon, au moins trois visites sur quatre doivent afficher le contenu principal en 2,5 secondes ou moins. Google explique que ce choix reflète l'expérience de la majorité sans dépendre de quelques visites sur un réseau défaillant. Une page réussit l'évaluation si les trois indicateurs sont bons ; faute de données sur l'INP, PageSpeed Insights se fonde sur le LCP et le CLS. Certains blogs annoncent des seuils plus sévères en 2026 : la documentation officielle affiche toujours ces valeurs.
Données terrain et données de laboratoire
Sur PageSpeed Insights, le rapport se divise en deux parties distinctes.
La partie haute présente les données terrain, issues du Chrome User Experience Report (CrUX) : l'expérience réelle des utilisateurs de Chrome qui partagent leurs statistiques d'usage, sur ordinateur et Android. Chrome sur iPhone, Safari et Edge n'y figurent pas. Safari et Firefox savent mesurer le LCP et l'INP depuis décembre 2025, mais CrUX restera limité à Chrome. Les chiffres couvrent les 28 derniers jours, et c'est cette partie qui porte l'évaluation des Core Web Vitals.
La partie basse présente les données de laboratoire : Lighthouse charge la page une fois en simulant un téléphone de milieu de gamme sur réseau mobile. La note sur 100 en découle, une moyenne pondérée de cinq mesures. Elle sert à diagnostiquer et n'est pas un Core Web Vital. Lighthouse ne peut pas mesurer l'INP, faute de clics pendant le test, et le remplace par le Total Blocking Time.
Et si votre site n'a pas assez de visiteurs ?
Une page n'entre dans CrUX qu'au-delà d'un nombre minimal de visiteurs, non communiqué par Google. PageSpeed Insights affiche alors les données de tout le site (l'« origine »), ou aucune donnée réelle si le site entier manque de trafic (la Search Console indique dans ce cas « Aucune donnée disponible »). Ce n'est pas une sanction : appuyez-vous sur les données de laboratoire.
Mesurer vos Core Web Vitals étape par étape
1. PageSpeed Insights, page par page
- Ouvrez pagespeed.web.dev et testez votre page d'accueil, puis celle qui génère le plus de demandes.
- Consultez l'onglet mobile en premier, puis l'onglet ordinateur.
- Lisez la partie haute : évaluation réussie ou non et valeur de chaque indicateur.
- Dans le diagnostic, notez l'élément retenu comme LCP et les corrections suggérées pour la personne qui gère votre site.
2. La Search Console, pour tout le site
Si votre site est déclaré dans la Search Console (voir notre guide de la Google Search Console pour débutants), ouvrez le rapport « Core Web Vitals » dans le menu de gauche. Selon l'aide de Google, il utilise les mêmes données CrUX, regroupe les pages similaires et donne à chaque groupe le statut de son indicateur le moins bon. Seules les pages indexées y figurent. Après une correction, « Démarrer le suivi » lance une surveillance de 28 jours.
3. Chrome DevTools et Lighthouse, pour comprendre
Dans Chrome sur ordinateur, faites un clic droit puis « Inspecter » (ou F12) et ouvrez l'onglet « Performance » : le panneau affiche aussitôt le LCP et le CLS mesurés chez vous, et l'INP dès que vous cliquez. L'onglet « Lighthouse » lance un test de laboratoire. Votre machine étant sans doute plus rapide que celle de vos clients, simulez un appareil plus lent avec les réglages du panneau.
Ce qui dégrade le plus souvent les scores d'un site de PME
Voici les causes classiques décrites par la documentation de Google, avec l'indicateur touché.
- Image d'accueil lourde ou diaporama (LCP, CLS). L'image d'en-tête est souvent l'élément LCP. Trop lourde, dans un format ancien plutôt qu'en WebP ou AVIF, ou chargée en différé, elle allonge le LCP : Google conseille de ne jamais différer l'image LCP. Les grands carrousels en haut de page contiennent souvent l'élément LCP, et leurs animations mal conçues peuvent dégrader le CLS.
- Trop d'extensions et de scripts (INP, LCP). Beaucoup d'extensions WordPress et de thèmes « tout-en-un » ajoutent des fichiers que le téléphone doit exécuter, ce qui ralentit la réaction aux clics. Le choix de la technologie compte : voir WordPress, Astro ou Next.js et, pour une boutique, Shopify, WordPress ou Next.js pour l'e-commerce.
- Widgets de chat, traceurs et outils tiers (INP, LCP). Selon web.dev, si votre site reste lent malgré un code optimisé, c'est probablement la faute des scripts tiers. Pour un chat, une « façade » affiche une simple image et ne charge le vrai script qu'au clic.
- Polices web (LCP, CLS). Une police téléchargée peut retarder l'affichage du texte ou en changer la taille une fois chargée. Limitez le nombre de polices et gardez le texte visible pendant leur chargement.
- Images sans dimensions (CLS). Sans largeur ni hauteur déclarées, l'image ne réserve pas sa place et le texte descend à son arrivée. Même effet avec une publicité ou une carte intégrée, selon le guide de web.dev sur le CLS.
- Bandeau cookies (CLS, parfois LCP). Les bandeaux de consentement sont une source très fréquente de décalages et peuvent, sur mobile, devenir l'élément LCP. Affichez-les par-dessus la page, sans la pousser.
- Hébergement lent (LCP). Le délai avant le premier octet envoyé par le serveur (TTFB) n'est pas un Core Web Vital, mais il fait partie du LCP. Web.dev retient 0,8 seconde ou moins comme repère et conseille d'examiner l'hébergement en premier : un mutualisé convient à un petit site surtout statique, moins à un site dynamique.
Quel poids dans le classement Google ?
Sur sa page consacrée à l'expérience sur la page, Google écrit que « les Core Web Vitals sont utilisés par nos systèmes de classement » (traduction libre, comme la suivante). Mais il ajoute que la recherche Google « cherche toujours à afficher le contenu le plus pertinent, même si l'expérience sur la page est médiocre ». Une bonne expérience peut aider lorsque beaucoup de contenus utiles répondent à la même requête, et de bons résultats dans la Search Console ne garantissent pas la première place.
Une page lente qui répond parfaitement à la question peut donc devancer une page rapide mais vague. Les Core Web Vitals peuvent aider à départager des pages comparables ; ils ne compensent pas un contenu faible. Leur effet le plus direct reste commercial : un visiteur qui attend ou touche le mauvais bouton peut partir chez un concurrent.
Penser d'abord au mobile
Selon l'observatoire de l'ANRT, 38,1 millions des 41,1 millions d'abonnements à internet recensés au Maroc fin mars 2026 étaient des abonnements à l'internet mobile. Jugez donc votre site d'abord sur l'onglet mobile, puis testez-le vous-même sur un téléphone modeste, en 4G, hors du Wi-Fi du bureau. Notez aussi que le rapport de la Search Console combine les visites de tous les pays.
Corriger ou reconstruire ?
Commencez par les pages qui comptent (accueil, services, contact) et par l'indicateur le plus mauvais sur mobile. Exemple fictif : un cabinet d'architectes à Tanger dont l'accueil s'ouvre sur un diaporama de cinq photos en pleine résolution, avec un chat et un bandeau cookies qui pousse la page. Une seule image compressée, un chat chargé au clic et un bandeau en surimpression règlent déjà l'essentiel.
Parfois, ces rustines ne suffisent pas : thème surchargé, constructeur de pages au code très lourd, extensions qui dépendent les unes des autres. Quand les corrections coûtent plus qu'un site neuf, mieux vaut repartir sur un site conçu pour la performance dès le départ que colmater sans fin.
Questions fréquentes
Mon site obtient 55 sur 100 sur mobile : est-il pénalisé par Google ?
Pas forcément. Cette note vient du test de laboratoire et n'est pas un Core Web Vital. Si le LCP, l'INP et le CLS de vos visiteurs réels sont bons, la page réussit l'évaluation.
Pourquoi ma note change-t-elle à chaque test ?
Le test dépend des conditions du moment : réseau, publicités, extensions du navigateur, antivirus. Selon la documentation de Lighthouse, l'essentiel de ces écarts ne vient pas de l'outil. Lancez plusieurs tests et suivez la tendance.
Combien de temps pour voir l'effet d'une correction ?
Le test de laboratoire réagit tout de suite. Les données terrain portant sur 28 jours, l'amélioration n'est complète qu'au bout de quatre semaines environ, comme le suivi de la Search Console.
Faut-il viser 100 sur 100 ?
Non. Visez trois indicateurs « Bon » pour vos visiteurs réels, sur mobile comme sur ordinateur. Les derniers points du test de laboratoire coûtent cher pour un gain que vos clients ne verront pas.
Les seuils, outils et citations de cet article reflètent la documentation de Google (web.dev, Search Central, Chrome for Developers) et les données de l'ANRT disponibles au 7 novembre 2026.
