Core Web Vitals : les trois mesures de vitesse et comment les améliorer

Le rapport de la Search Console affiche des pages « à améliorer », PageSpeed Insights parle de secondes, de millisecondes et d’un score sans unité, et le prestataire évoque la vitesse du site sans préciser laquelle. Les Core Web Vitals, ou signaux web essentiels, sont pourtant trois mesures bien définies, que l’on peut lire soi-même et corriger en grande partie sans toucher au code du site.

Quelles sont les trois mesures des Core Web Vitals et leurs seuils ?

Les Core Web Vitals sont le sous-ensemble des Web Vitals que tout propriétaire de site devrait mesurer : le LCP pour le chargement, l’INP pour l’interactivité et le CLS pour la stabilité visuelle. Les seuils ci-dessous sont ceux que publient web.dev et la documentation Search Central.

• Le LCP (Largest Contentful Paint) est le moment où le plus grand élément visible de la page, souvent une image ou un titre, s’affiche. Il doit intervenir dans les 2,5 premières secondes après le début du chargement.
• L’INP (Interaction to Next Paint) mesure la réactivité de la page : le délai entre une action du visiteur et la mise à jour visible de l’écran. Il doit être de 200 millisecondes ou moins.
• Le CLS (Cumulative Layout Shift) mesure les déplacements inattendus du contenu, par exemple un bouton qui descend au moment où l’on clique. Il doit être de 0,1 ou moins. C’est un score sans unité, et non une durée.

Pour que le résultat vaille pour la plupart des visiteurs, web.dev recommande de mesurer le 75e centile des chargements de page, séparément sur mobile et sur ordinateur.

Mesure	Bon	À améliorer	Mauvais	Cause courante sur un petit site
LCP	2,5 s ou moins	de 2,5 s à 4 s	plus de 4 s	Image principale lourde ou chargée tardivement, serveur lent à répondre
INP	200 ms ou moins	de 200 à 500 ms	plus de 500 ms	Scripts d’extensions, de chat ou de suivi qui occupent le navigateur
CLS	0,1 ou moins	de 0,1 à 0,25	plus de 0,25	Images sans dimensions, polices web, bannières insérées après coup

Où voir les Core Web Vitals de son site ?

Deux outils gratuits les affichent : le rapport Core Web Vitals de la Search Console et PageSpeed Insights, qui s’ouvre dans le navigateur sans compte.

Dans la Search Console, le rapport présente, pour le mobile et pour l’ordinateur, les groupes de pages classés « Médiocre », « Amélioration nécessaire » ou « Bon ». L’état d’un groupe de pages similaires s’applique à toutes ses pages. Seules les adresses indexées peuvent y figurer, et un groupe sans volume minimal de données pour le LCP et le CLS est omis.

PageSpeed Insights affiche jusqu’à quatre jeux de données de visiteurs réels : mobile et ordinateur, pour l’adresse saisie et pour l’ensemble du site. Lorsque la page n’a pas assez de visites, l’outil bascule sur les données de l’ensemble du site.

Les deux outils s’appuient sur le Chrome UX Report, une base de données anonymes de visiteurs réels de Chrome. Un site très peu fréquenté peut n’avoir aucune donnée de terrain. web.dev précise que, si les deux divergent, les données de terrain donnent probablement une image plus juste de l’expérience des visiteurs. Les pages lentes se repèrent aussi au taux de rebond.

Pourquoi le LCP est-il mauvais et comment le corriger ?

Le LCP est le plus souvent mauvais parce que l’image principale démarre son chargement trop tard ou arrive trop lourde, ou parce que le serveur met trop de temps à répondre. web.dev découpe le LCP en quatre parties : environ 40 % du temps pour le premier octet de la page, moins de 10 % avant que l’image commence à charger, environ 40 % pour son téléchargement et moins de 10 % pour son affichage.

La marche à suivre :

1. Dans PageSpeed Insights, ouvrez la section Lighthouse et repérez le diagnostic « Largest Contentful Paint element » : il indique quel élément de la page est concerné.
2. Vérifiez que cette image n’a pas l’attribut loading="lazy". web.dev explique que le chargement différé retarde l’image tant que la mise en page n’a pas confirmé qu’elle est visible.
3. Ajoutez fetchpriority="high" à cette image : <img fetchpriority="high" src="images/principale.webp">. Réservez-la à une ou deux images, sinon la consigne perd son effet.
4. Si l’image n’est appelée que par une feuille de style ou un script, elle doit être préchargée : <link rel="preload" fetchpriority="high" as="image" href="images/principale.webp">.
5. Si le premier octet arrive tard, cherchez les redirections en cascade et les pages que le cache ne peut pas servir. Un TTFB élevé peut rendre un LCP de 2,5 secondes très difficile à atteindre.

Pourquoi le CLS est-il mauvais et comment le corriger ?

Le CLS est mauvais quand des éléments apparaissent sans que la page ait réservé leur place, et web.dev en retient quatre causes principales : les images sans dimensions, les publicités, intégrations et cadres sans dimensions, les contenus insérés dynamiquement, et les polices web.

1. Donnez à chaque image et à chaque vidéo des attributs width et height, sans unité : <img src="boutique.jpg" width="640" height="360" alt="…">. Le navigateur réserve alors la zone avant le téléchargement.
2. Réservez un emplacement de taille fixe pour les bannières, vidéos intégrées et modules tiers (avis, cartes, chat).
3. Pour les polices, précisez toujours une police de secours dans font-family : sans elle, Chrome affiche sa police par défaut, à empattements, souvent éloignée de la police choisie.
4. Chargez en priorité la police critique avec <link rel="preload">. Avec font-display: optional, la police web n’est utilisée que si elle est disponible à l’affichage initial, ce qui évite un second calcul de mise en page.

Les déplacements déclenchés par un clic sont ignorés du score lorsqu’ils surviennent dans les 500 millisecondes. En revanche, un contenu chargé à retardement pendant le défilement compte.

Comment améliorer l’INP sur un site de petite entreprise ?

Pour améliorer l’INP, il faut réduire le travail que le navigateur exécute quand le visiteur agit, c’est-à-dire surtout les scripts. web.dev décompose chaque interaction en trois temps : le délai avant que le traitement commence, la durée du traitement, puis le délai avant l’affichage de l’image suivante.

Le premier temps s’allonge quand le navigateur est occupé à charger, analyser et exécuter des scripts. Sur un site construit avec des extensions, la démarche consiste à relever les scripts chargés, puis à désactiver une extension à la fois sur une copie de test pour mesurer son effet.

Le deuxième temps dépend du code qui s’exécute au clic. web.dev recommande de découper les longs traitements en tâches plus courtes, ce qui laisse le navigateur répondre aux autres actions. Un petit site sans développeur n’écrit généralement pas ce code : la question à poser à l’éditeur d’une extension est « quelles tâches bloquent le navigateur au moment du clic ? ».

Les Core Web Vitals pèsent-ils dans le classement ?

Oui, les Core Web Vitals sont utilisées par les systèmes de classement du moteur, mais elles ne remplacent pas la pertinence du contenu. La documentation Search Central indique que le moteur s’efforce de toujours afficher le contenu le plus pertinent, même si l’expérience sur la page est décevante.

Elle ajoute que, pour de nombreuses requêtes, il existe beaucoup de contenus utiles : une bonne expérience sur la page peut alors contribuer à la réussite. Elle précise aussi que de bons résultats dans le rapport de la Search Console ne garantissent pas une place en haut des résultats, et que viser un score parfait pour le seul référencement n’est pas forcément pertinent.

La priorité est donc de sortir de l’état « Médiocre » sur les pages qui comptent.

Questions fréquentes

Les Core Web Vitals sont-ils les mêmes sur mobile et sur ordinateur ?

Les seuils sont identiques, mais les résultats diffèrent, car les appareils et les connexions ne sont pas les mêmes. La Search Console et PageSpeed Insights les présentent séparément. Un site peut être « Bon » sur ordinateur et « Médiocre » sur mobile.

Pourquoi ma page n’a-t-elle aucune donnée dans le rapport ?

La Search Console n’affiche que des adresses indexées et omet les groupes sans volume minimal de données. Une page peu visitée peut donc rester vide. PageSpeed Insights affiche alors, à défaut, les données de l’ensemble du site.

Que signifie le 75e centile ?

Le résultat annoncé est celui que 75 % des visites atteignent ou améliorent. Si le LCP d’un groupe est de 2,3 secondes, trois visites sur quatre ont affiché leur élément principal en 2,3 secondes ou moins, et la dernière a été plus lente.

Une correction apparaît-elle tout de suite dans la Search Console ?

Non, les données du rapport proviennent de visites réelles cumulées et ne se mettent pas à jour instantanément après une modification. Après une correction, contrôlez d’abord PageSpeed Insights, puis laissez passer du temps et des visites avant de juger l’état du groupe de pages.

Le test simulé peut-il différer du rapport de la Search Console ?

Oui : le test simulé charge la page une fois dans des conditions fixes, le rapport reflète de vrais visiteurs. web.dev conseille de s’appuyer sur les données de terrain en cas de désaccord.

Sources

Sources consultées le 24 octobre 2026, présentées sans liens cliquables.

• Search Central, « Comprendre les signaux Web essentiels et les résultats de recherche », documentation. Adresse : https://developers.google.com/search/docs/appearance/core-web-vitals?hl=fr
• Search Central, « Comprendre l’expérience sur la page dans les résultats de recherche », documentation. Adresse : https://developers.google.com/search/docs/appearance/page-experience?hl=fr
• Aide de la Search Console, « Rapport Core Web Vitals ». Adresse : https://support.google.com/webmasters/answer/9205520?hl=fr
• web.dev, « Web Vitals », mis à jour le 31 octobre 2024. Adresse : https://web.dev/articles/vitals
• web.dev, « Optimize Largest Contentful Paint », mis à jour le 31 mars 2025. Adresse : https://web.dev/articles/optimize-lcp
• web.dev, « Optimize Cumulative Layout Shift », mis à jour le 7 février 2025. Adresse : https://web.dev/articles/optimize-cls
• web.dev, « Optimize Interaction to Next Paint ». Adresse : https://web.dev/articles/optimize-inp