Core Web Vitals

Glossaire – Métrique

Les Core Web Vitals sont les trois mesures par lesquelles Google juge l’expérience réelle d’une page : le temps d’affichage du contenu principal (LCP), le délai de réaction à une action du visiteur (INP) et la stabilité de la mise en page (CLS), relevés chez les vrais visiteurs de Chrome.

Ces mesures ne sortent pas d’un test de laboratoire. Google les tire du Chrome User Experience Report, le CrUX, qui agrège les chargements de pages vécus par les utilisateurs de Chrome sur 28 jours glissants. Une page « passe » quand au moins 75 % de ses visites respectent le seuil de chacune des trois mesures.

Le relevé que B-Strong a fait le 24/10/2026 sur ces mêmes données donne l’échelle : en septembre 2026, 62,6 % des sites visités depuis la France passent les trois seuils sur mobile. Les boutiques WooCommerce tombent à 46,6 %, les boutiques PrestaShop montent à 71,7 %. Six ans plus tôt, en janvier 2020, la moyenne française était de 26,2 %.

Ce que couvre cette fiche :

• Les trois seuils, et pourquoi Google regarde le 75e centile
• Ce que passent les sites français, outil par outil
• De l’annonce de 2020 au remplacement du FID en 2024
• Ce que Google dit de leur poids dans le classement
• Où lire vos chiffres, et lesquels croire
• Pourquoi une correction met jusqu’à 28 jours à se voir
• Par où commencer selon la mesure en échec
• Questions fréquentes

Les seuils

Les trois seuils, et pourquoi Google regarde le 75e centile

Chaque mesure a deux bornes, publiées par Google sur web.dev. Sous la première, l’expérience est jugée bonne ; au-delà de la seconde, mauvaise ; entre les deux, à améliorer.

Le point qui change la lecture d’un rapport, c’est le centile. Google ne regarde ni la moyenne ni la meilleure visite : il prend la valeur sous laquelle se situent 75 % des visites. Un LCP « à 2,1 s » signifie que trois visites sur quatre ont vu le contenu principal en 2,1 secondes ou moins, et qu’une sur quatre a attendu davantage. Google justifie ce choix dans sa note méthodologique : un centile assez haut pour que la majorité des visiteurs soit bien servie, assez bas pour qu’une poignée de connexions défaillantes ne décide pas du verdict.

Conséquence pratique : pour qu’une page passe, il suffit que 25 % de ses visites au plus dépassent le seuil. C’est cette part, et non un score sur 100, qu’il faut faire baisser.

Relevé B-Strong

Ce que passent les sites français, outil par outil

Le rapport technologique de HTTP Archive croise chaque mois deux sources : les données CrUX par pays, et la détection de l’outil qui fait tourner chaque site (CMS, solution e-commerce, constructeur de pages). B-Strong en a extrait le 24/10/2026 la dernière période publiée, septembre 2026, pour les sites visités depuis la France, sur mobile.

Le chiffre qui compte pour un e-commerçant n’est pas la moyenne. Sur la même période, PrestaShop (71,7 %) fait jeu égal avec Shopify (72,8 %), alors qu’une boutique WooCommerce échoue plus d’une fois sur deux. L’écart ne tient pas à l’INP : WooCommerce réussit l’INP sur 93,6 % de ses sites, mieux que Shopify (79,9 %). Il tient presque entièrement au LCP, bon sur 51,1 % des boutiques WooCommerce seulement.

WordPress perd ses points au chargement. Sur 126 754 sites WordPress, l’INP et le CLS sont bons à plus de 90 %, le LCP à 67,3 %. Les sites construits avec Elementor descendent à 54,5 % de LCP réussi. Quand un site WordPress échoue, la première piste est donc le poids de ce qui s’affiche en haut de page : visuel d’en-tête, polices, feuilles de style et scripts chargés avant le contenu.

Shopify est le seul outil du relevé dont le maillon faible est l’INP. Sa plateforme sert vite les pages (88,1 % de LCP réussi), mais les applications et scripts ajoutés par les marchands ralentissent la réaction aux clics. Sur une boutique Shopify, l’audit commence par la liste des applications installées.

Une limite à garder en tête : ces chiffres comptent des sites, pas des visites, et ils mesurent l’ensemble du site à partir de son outil détecté. Ils disent où se situe votre solution, pas où se situe votre boutique. Pour cela, il faut vos propres données, décrites plus bas. L’écart entre mobile et ordinateur n’est d’ailleurs pas une règle : 62,6 % contre 69,5 % pour l’ensemble, mais 46,6 % contre 46,9 % pour WooCommerce, et Drupal fait mieux sur mobile.

Histoire

De l’annonce de 2020 au remplacement du FID en 2024

Google a présenté le programme Web Vitals le 5 mai 2020 sur le blog Chromium, avec trois mesures : LCP, FID (First Input Delay, le délai avant la première interaction) et CLS. Le 28 mai 2020, Google Search annonçait qu’elles entreraient dans le classement au sein d’un ensemble appelé page experience. Le déploiement mobile a commencé le 15 juin 2021 et s’est achevé fin août 2021 ; l’ordinateur a suivi entre le 22 février et la fin mars 2022.

Le FID ne mesurait que le délai avant la toute première interaction, et presque tous les sites le réussissaient. L’INP, introduit comme mesure expérimentale en mai 2022, mesure toutes les interactions d’une visite. Il a remplacé le FID le 12 mars 2024. Le relevé français montre ce que ce changement a coûté.

Six points perdus en un mois, sans qu’aucun site n’ait changé : c’est la règle qui avait bougé. WordPress est passé de 48,4 % à 44,8 %, Shopify de 68,9 % à 62,7 %, Wix de 71,6 % à 64,2 %. Il a fallu six mois pour que la moyenne française retrouve son niveau d’avant : 55,3 % en septembre 2024. Si votre rapport Search Console a viré au rouge au printemps 2024 sans mise en production de votre côté, l’explication est là.

Classement

Ce que Google dit de leur poids dans le classement

La documentation de Google Search est explicite sur deux points. D’abord, les Core Web Vitals « sont utilisés par nos systèmes de classement ». Ensuite, ils ne garantissent rien : de bons résultats dans le rapport Search Console « ne garantissent pas » que vos pages se classent en tête, et viser un score parfait pour le seul SEO « n’est peut-être pas le meilleur usage de votre temps ». Google précise qu’il cherche toujours à montrer le contenu le plus pertinent, même quand l’expérience de la page est médiocre, et que l’expérience compte surtout quand beaucoup de contenus utiles se valent sur une même requête.

En avril 2023, Google a aussi corrigé une idée reçue : il n’existe pas de « signal page experience » unique, et la mise à jour de 2021 n’était pas un système de classement séparé. La même page répond à une autre croyance tenace : une bonne expérience de page n’est pas une condition pour apparaître dans le carrousel « À la une ». Une fiche qui vous promet un bond de positions après une optimisation de vitesse vous vend donc ce que Google ne promet pas.

Le vrai motif de s’en occuper est commercial. Dans un test A/B publié par Google sur web.dev le 17/03/2021, Vodafone a comparé deux versions d’une même page d’atterrissage, identiques en dehors de la performance : la version au LCP amélioré de 31 % a produit 8 % de ventes en plus. C’est un cas mis en avant par Google, sur un trafic payant, à lire comme un ordre de grandeur et non comme une loi. Il rejoint ce que montre le taux de conversion : une page qui tarde à s’afficher perd des acheteurs avant même d’avoir été lue.

Côté indexation, Google évalue la version mobile des pages depuis le passage au mobile-first indexing. Les Core Web Vitals sont toutefois mesurés séparément sur mobile et sur ordinateur, et chaque version est jugée sur ses propres visiteurs.

Diagnostic

Où lire vos chiffres, et lesquels croire

Deux familles de chiffres circulent, et seule la première reflète ce que Google mesure. Les données de terrain viennent du CrUX : ce sont les visites réelles des 28 derniers jours. Les données de laboratoire viennent d’un test simulé, comme Lighthouse : un chargement unique, depuis une machine et une connexion choisies. Le score de 0 à 100 de PageSpeed Insights est un score Lighthouse. Il sert à trouver des causes, pas à juger un site.

Le rapport Core Web Vitals de la Search Console

Dans la Search Console, menu Expérience › Core Web Vitals, Google classe vos URL en « Bon », « Amélioration nécessaire » et « Médiocre », séparément pour mobile et ordinateur. Trois particularités changent la façon de le lire : les URL sont regroupées par pages semblables (toutes vos fiches produit, par exemple), l’état d’un groupe est celui de sa plus mauvaise mesure, et seules les URL indexées qui ont assez de données sur le LCP et le CLS y figurent. Un petit site peut donc n’y voir aucune ligne.

PageSpeed Insights

Sur pagespeed.web.dev, le bloc des données réelles, en haut du rapport, affiche les données CrUX de l’URL testée, ou de l’ensemble du site si l’URL n’a pas assez de visites. Pour chaque mesure, la barre donne la répartition des visites entre bon, à améliorer et mauvais : c’est la donnée dont vous aurez besoin pour le calculateur plus bas. Testez une fiche produit et une page catégorie, pas seulement l’accueil : c’est là que se fait l’achat, et c’est rarement la page la plus légère.

Chrome DevTools

Depuis Chrome 129, le panneau Performance des outils de développement affiche en direct le LCP, le CLS et l’INP de votre propre navigation, à côté des valeurs CrUX de la page. C’est l’outil qui désigne l’élément exact retenu comme LCP, ou l’interaction qui dépasse 200 ms.

Le CrUX n’inclut que les pages et sites qui reçoivent assez de visites, selon un seuil que Google ne publie pas. Sans données de terrain, la seule mesure fiable est celle que vous installez vous-même : une bibliothèque de mesure sur vos pages, ou un outil de suivi des visites réelles.

Calculateur

Pourquoi une correction met jusqu’à 28 jours à se voir

Le CrUX agrège 28 jours de visites. Le lendemain d’une mise en production, 27 jours sur 28 de la fenêtre datent encore de l’ancienne version. Le statut bascule quand la part des visites lentes, mélange d’ancien et de nouveau, repasse sous 25 %. La validation proposée par la Search Console suit la même logique : elle surveille vos URL pendant 28 jours avant de déclarer un problème résolu.

Le calcul a une conséquence que peu de rapports expliquent : selon l’ampleur de la correction, le statut peut basculer en deux semaines, ou jamais. Entrez la part de visites au-dessus du seuil « bon » (la somme des parts orange et rouge dans PageSpeed Insights) avant la correction, et celle que vous visez ou constatez après.

Leviers

Par où commencer selon la mesure en échec

Le bon levier dépend de la mesure qui échoue et du type de page. Les pistes ci-dessous sont celles que documente Google sur web.dev ; leur effet se vérifie dans vos données de terrain, pas dans un score.

Un LCP trop lent vient presque toujours de l’élément principal lui-même : une image d’en-tête trop lourde, découverte tard par le navigateur, ou chargée en différé alors qu’elle est visible dès l’arrivée. Servez-la dans un format compressé (WebP, AVIF) et à la bonne taille, ne lui appliquez pas le chargement différé (lazy loading), et signalez-la comme prioritaire avec l’attribut fetchpriority="high". Un serveur lent à répondre retarde tout le reste : sur WordPress, le cache de page et l’hébergement passent avant les réglages fins.

Un INP trop élevé signale un navigateur occupé au moment du clic. Les coupables habituels sont les tâches JavaScript de plus de 50 millisecondes, que Google appelle tâches longues, et les scripts tiers : outils de mesure, conversation en direct, pixels publicitaires, applications de boutique. Retirez ceux qui ne servent plus, chargez les autres après le contenu, et fractionnez les traitements lourds. Les sites qui construisent leurs pages côté navigateur y sont plus exposés, voir la fiche JavaScript SEO.

Un CLS trop haut se corrige en réservant la place de ce qui arrive après le texte. Donnez une largeur et une hauteur à chaque image et à chaque vidéo intégrée, réservez un emplacement fixe aux bannières et aux encarts, et évitez qu’une police web ne remplace brutalement la police de secours avec des dimensions différentes.

Sur une boutique, la priorité suit le chiffre d’affaires : la fiche produit et la page catégorie avant l’accueil, le mobile avant l’ordinateur si c’est là que se fait le trafic. C’est ce tri que B-Strong applique dans ses missions de SEO technique et d’agence SEO e-commerce, avant de toucher au moindre réglage.

Questions fréquentes

Les Core Web Vitals sont-ils un facteur de classement Google ?
Oui. Google écrit qu’ils « sont utilisés par nos systèmes de classement », depuis le déploiement mobile de juin à août 2021 et sur ordinateur depuis mars 2022. Google précise aussi qu’un bon résultat ne garantit pas une bonne position : la pertinence du contenu passe d’abord, et l’expérience de la page compte surtout quand plusieurs contenus utiles se valent.

Un score de 90 dans PageSpeed Insights suffit-il ?
Non. Ce score vient de Lighthouse, un test de laboratoire réalisé en un seul chargement. Google classe à partir des visites réelles du CrUX. Un site peut afficher 95 en laboratoire et échouer sur le terrain, parce que ses visiteurs utilisent des téléphones plus lents que la machine de test, ou parce qu’un script tiers ne se déclenche qu’en conditions réelles.

Pourquoi mon site n’apparaît-il pas dans le rapport Core Web Vitals ?
Le CrUX ne retient que les pages et les sites qui ont assez de visites, selon un seuil que Google ne publie pas, et le rapport n’affiche que des URL indexées disposant de données suffisantes sur le LCP et le CLS. Sur un petit site, l’absence de données est normale. Dans ce cas, installez une mesure sur vos propres pages pour connaître les valeurs réelles.

Faut-il refaire son site pour passer les Core Web Vitals ?
Rarement. Le relevé de septembre 2026 montre que les sites WordPress échouent surtout sur le LCP, une mesure qui se corrige souvent par l’image d’en-tête, le cache et le tri des extensions. Changer d’outil se justifie quand l’échec vient de l’architecture elle-même, ce qu’un audit SEO établit avant toute décision.

Sources citées

1. Google Search Central : Understanding Core Web Vitals and Google search results
2. Google Search Central : Understanding page experience in Google Search results
3. Chromium Blog, 05/05/2020 : Introducing Web Vitals
4. Google Search Central, 28/05/2020 : Evaluating page experience for a better web
5. Google Search Central, 19/04/2021 : More time, tools, and details on the page experience update
6. Google Search Central, 04/11/2021 : Timing for bringing page experience to desktop
7. Google Search Central, 19/04/2023 : Our guidance on page experience
8. web.dev : Web Vitals (seuils des trois mesures)
9. web.dev : Defining the Core Web Vitals metrics thresholds (choix du 75e centile)
10. web.dev : Interaction to Next Paint becomes a Core Web Vital on March 12
11. Chrome for Developers : CrUX methodology (critères d’inclusion)
12. Aide Search Console : rapport Core Web Vitals
13. web.dev : Optimize Largest Contentful Paint
14. Chrome for Developers : What’s new in DevTools (Chrome 129)
15. web.dev, 17/03/2021 : Vodafone, a 31% improvement in LCP increased sales by 8%
16. HTTP Archive : Core Web Vitals Technology Report
17. Rick Viscomi, HTTP Archive, 24/06/2021 : Introducing the Core Web Vitals Technology Report (méthode)

Relevé B-Strong du 24/10/2026 : 12 séries mensuelles du rapport technologique HTTP Archive (France, mobile et ordinateur, janvier 2020 à septembre 2026). Fiche mise à jour le 24/10/2026.

Terme lié à connaître : le Google Search Console.