Guide des Core Web Vitals

En bref — Les Core Web Vitals sont trois mesures utilisées par Google pour évaluer l’expérience réelle : vitesse d’affichage du contenu principal (LCP), rapidité de réponse après une interaction (INP) et stabilité visuelle pendant le chargement (CLS). Une valeur « bonne » correspond à un LCP inférieur ou égal à 2,5 secondes, un INP inférieur ou égal à 200 millisecondes et un CLS inférieur ou égal à 0,1. Elles influencent un peu le classement, mais la pertinence du contenu compte davantage.

Que sont les Core Web Vitals ?

Google cherche à récompenser les pages agréables à utiliser et résume l’expérience de page en trois dimensions mesurables, appelées Core Web Vitals ou CWV :

• Largest Contentful Paint (LCP) — chargement. Temps nécessaire à l’affichage du plus grand élément visible, souvent une image principale ou un titre. Bon : ≤ 2,5 secondes.
• Interaction to Next Paint (INP) — réactivité. Délai entre un clic, toucher ou saisie et la réaction visuelle de la page. Bon : ≤ 200 millisecondes.
• Cumulative Layout Shift (CLS) — stabilité visuelle. Ampleur des déplacements inattendus pendant le chargement. Bon : ≤ 0,1.

Origine des mesures

Les valeurs utilisées par Google proviennent de personnes réelles visitant le site dans Chrome, pas d’un test isolé. Google juge une page selon l’expérience du 75e centile : au moins 75 % des visiteurs doivent bénéficier d’une bonne expérience. Un seul résultat rapide sur votre machine ne suffit pas. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

C’est pourquoi un score parfait dans un outil de vitesse ne garantit pas la réussite. Les outils tels que PageSpeed Insights et Lighthouse exécutent un test de laboratoire unique sur un téléphone simulé : ils sont excellents pour diagnostiquer, mais ne fournissent pas les valeurs de terrain prises en compte par Google.

Influencent-elles le classement ?

Oui, dans une certaine mesure. Google dit que ses systèmes utilisent les Core Web Vitals, sans publier de poids ni de pourcentage. Il précise qu’un contenu pertinent peut dépasser une page dont l’expérience est médiocre. Sans pertinence, la vitesse et la stabilité ne suffisent pas. John Mueller l’a résumé ainsi : “it’s not going to make your site’s rankings jump up.” (traduction) « cela ne fera pas bondir le classement de votre site ».

Mon avis après des années sur ce sujet : la plupart des sites ne gagneront pas beaucoup de classement en poursuivant ces chiffres. Améliorer vitesse et stabilité reste utile aux visiteurs et aux conversions, même sans effet visible dans les résultats.

Une confusion fréquente

Ancien nom : vous rencontrerez encore FID (First Input Delay) comme Core Web Vital. Il a disparu : INP a remplacé FID le 12 mars 2024. Un outil ou article qui recommande encore d’optimiser FID est dépassé.

Vous voulez les seuils exacts, la différence entre terrain et laboratoire, la nuance de classement et le bon outil pour chaque usage ? Passez à l’onglet Avancé.

En bref — Les Core Web Vitals sont trois mesures UX de terrain : LCP — chargement, bon ≤ 2,5 s —, INP — réactivité, ≤ 200 ms — et CLS — stabilité visuelle, ≤ 0,1. Chacune est évaluée au 75e centile des utilisateurs Chrome réels dans CrUX sur une fenêtre glissante de 28 jours. Les seuils sont identiques sur mobile et ordinateur, mais chaque catégorie est évaluée séparément, et les trois mesures doivent être bonnes. INP a remplacé FID le 12 mars 2024. Google indique que ses systèmes de classement utilisent les CWV, sans poids officiel ni pourcentage de « départage ». Un bon score ne garantit pas un meilleur classement et la pertinence peut l’emporter. Les scores de laboratoire — Lighthouse ou PSI — servent au diagnostic et diffèrent souvent des données de terrain. TTFB et FCP sont d’autres Web Vitals de diagnostic ; TBT et Speed Index sont des approximations de laboratoire.

Ce qui constitue une Core Web Vital

Google les définit comme “the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (traduction) « le sous-ensemble des Web Vitals applicable à toutes les pages, que tous les propriétaires de sites doivent mesurer et que tous les outils Google présenteront ». Il en existe exactement trois, chacune couvrant une dimension de l’expérience.

Google évalue les seuils « bons » au 75e centile : LCP à 2,5 secondes, INP à 200 millisecondes et CLS à 0,1. Une page n’est globalement « bonne » que si les trois franchissent leur seuil au p75. Les seuils sont identiques sur mobile et ordinateur, mais Google évalue et rapporte chaque appareil séparément.

TTFB, FCP, TBT et Speed Index ne sont pas des Core Web Vitals. Ils sont détaillés plus loin.

LCP — chargement

LCP “reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (traduction) « indique le temps de rendu de la plus grande image, du plus grand bloc de texte ou de la vidéo visible dans la fenêtre, par rapport au début de la navigation ». L’élément LCP est souvent l’image principale, une grande image d’arrière-plan ou le titre. Il s’agit du plus grand élément visible ; des fenêtres différentes peuvent produire des éléments LCP différents, ce qui explique certains écarts terrain-laboratoire.

INP — réactivité

INP “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (traduction) « évalue la réactivité globale d’une page en observant la latence de toutes les interactions par clic, toucher ou clavier durant la visite ». Il couvre l’ensemble de l’interaction : délai d’entrée → traitement des gestionnaires → affichage de l’image suivante.

C’est l’amélioration principale par rapport à FID. INP observe toutes les interactions, alors que FID ne mesurait que le délai de la première. INP est devenu une Core Web Vital le 12 mars 2024, en remplacement de First Input Delay (FID). Evidence for this claim INP became a Core Web Vital and replaced FID on March 12, 2024. Scope: Chrome and Google tooling transition from FID to INP. Confidence: high · Verified: 2026-07-14 web.dev: INP launch FID a été retiré de Search Console le même jour. Il est complètement abandonné.

Nuance importante : INP n’est pas la pire interaction isolée, mais un centile élevé de l’ensemble. Un clic lent unique ne condamne pas une page autrement bonne.

CLS — stabilité visuelle

CLS “is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (traduction) « mesure la plus grande rafale de scores de décalage pour chaque déplacement inattendu durant toute la vie de la page ». La rafale, ou fenêtre de session, regroupe les décalages espacés de moins d’une seconde pendant au plus cinq secondes. Google cite comme causes : “images or videos with unknown dimensions,” (traduction) « images ou vidéos aux dimensions inconnues », “fonts that render larger or smaller than its initial fallback,” (traduction) « polices rendues plus grandes ou petites que la police de secours », et “third-party ads or widgets that dynamically resize themselves.” (traduction) « publicités ou widgets tiers qui se redimensionnent dynamiquement ».

Données de terrain et de laboratoire — mesure et diagnostic

Cette distinction crée le plus de confusion ; formulez-la précisément.

• Les données de terrain (CrUX) sont “data collected from the real users visiting your site.” (traduction) « des données recueillies auprès des vrais utilisateurs du site ». Elles sont rapportées au 75e centile sur une fenêtre glissante de 28 jours, séparées entre mobile et ordinateur. Les Core Web Vitals représentent cette expérience réelle et alimentent les systèmes de classement Google. Elles reflètent appareils, réseaux, états de cache et cache avant/arrière réels.
• Les données de laboratoire sont “data collected in a controlled environment with predefined device and network settings” (traduction) « des données recueillies dans un environnement contrôlé avec appareil et réseau prédéfinis » : téléphone émulé unique, cache froid, aucun utilisateur réel. Lighthouse et la section laboratoire de PSI les produisent. Elles servent à trouver les problèmes, pas à mesurer le terrain. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

Google conseille : “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (traduction) « Si vous disposez des deux pour une page, utilisez les données de terrain pour prioriser ». Le score Performance de Lighthouse “often does not correlate with field Core Web Vitals.” (traduction) « ne correspond souvent pas aux Core Web Vitals de terrain ». Mon guide des Core Web Vitals donne le même conseil : le laboratoire sert à tester et itérer, car la moyenne de terrain sur 28 jours met des semaines à refléter une correction.

Règle du p75 et importance

Une page réussit si 75 % des utilisateurs réels atteignent le seuil « bon ». Cette barre est à la fois tolérante et réelle : trois visiteurs sur quatre ont une bonne expérience, sans que quelques connexions très faibles dictent tout. Un chargement à 1,8 s sur votre téléphone ne signifie donc rien seul ; le p75 global compte.

Niveau page ou niveau origine — ne vous laissez pas tromper

De nombreux outils affichent par défaut la moyenne de l’origine, souvent plus favorable que les pages individuelles. Dans mon étude CWV portant sur CrUX et 5,2 millions de pages Ahrefs Site Audit, seulement 21,2 % des pages réussissaient les trois seuils, contre 33 % au niveau de l’origine. La documentation Google indique que ses systèmes évaluent généralement les pages individuellement, tout en effectuant aussi des évaluations globales. Une origine « bonne » peut donc masquer de nombreuses pages en échec. Lorsqu’un outil offre les deux vues, contrôlez aussi le chiffre de la page.

Les pages sans trafic suffisant ne disposent parfois d’aucune donnée CrUX de terrain. CrUX inclut seulement les utilisateurs Chrome ayant accepté les statistiques — pas Chrome sur iOS ni les autres navigateurs. C’est une lacune d’admissibilité, pas un échec. Les règles de regroupement ou de repli pour les URL peu fréquentées appartiennent à chaque produit — PSI, Search Console, API CrUX — et non à une règle universelle.

Quel poids réel dans le classement ?

Il s’agit d’un signal de classement confirmé : Google dit que ses systèmes utilisent les Core Web Vitals. Sa documentation actuelle ne leur attribue toutefois aucun poids, pourcentage ou statut officiel de « départage ». Ne présentez pas ces formules comme des mots de Google.

Pour confirmer le signal, la documentation indique que les Core Web Vitals “along with other page experience aspects, aligns with what our core ranking systems seek to reward,” (traduction) « avec les autres aspects de l’expérience de page, correspondent à ce que nos systèmes fondamentaux cherchent à récompenser ». John Mueller a déclaré : “more than a tie-breaker, but it also doesn’t replace relevance.” (traduction) « plus qu’un critère de départage, sans remplacer la pertinence ».

Pour éviter l’exagération, Mueller a aussi dit : “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that,” (traduction) « les Core Web Vitals ne sont pas des facteurs énormes et je doute qu’elles provoquent seules une forte baisse », puis en mars 2024 : “it’s not going to make your site’s rankings jump up.” (traduction) « cela ne fera pas bondir le classement ». Google précise : “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (traduction) « Google cherche toujours à afficher le contenu le plus pertinent, même si l’expérience de page est médiocre », et avertit : “trying to get a perfect score just for SEO reasons may not be the best use of your time.” (traduction) « viser un score parfait uniquement pour le SEO n’est peut-être pas le meilleur usage de votre temps ». Evidence for this claim Google says Core Web Vitals are used by ranking systems, while page experience does not override more relevant content. Scope: Google Search ranking guidance; no fixed weight or ranking-position effect is promised. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search Google: Page experience

Lecture pragmatique : la pertinence domine, Google ne chiffre pas le poids des CWV et la plupart des sites n’en tireront pas un grand bénéfice de classement. Les améliorations UX restent utiles aux utilisateurs et conversions. Les plateformes — WordPress, Cloudflare, frameworks — absorbent aussi automatiquement une part croissante de l’optimisation. Pour les petites entreprises locales, ce n’est généralement pas la priorité.

Précision de la mise à jour 2024 : parmi les signaux généraux d’expérience de page, seules les Core Web Vitals contribuent directement au classement de manière confirmée. HTTPS, compatibilité mobile, absence d’interstitiels intrusifs et clarté restent de bonnes pratiques, sans amélioration directe telle que l’ancienne documentation pouvait le laisser penser.

Les « autres Web Vitals » — diagnostic, pas cœur

Ces mesures sont souvent mal classées. Aucune n’est une Core Web Vital :

• Time to First Byte (TTFB) — délai avant le premier octet. Il “precedes every other meaningful loading performance metric” (traduction) « précède toute autre mesure significative du chargement » et alimente LCP. Google dit : “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold.” (traduction) « TTFB n’étant pas une Core Web Vital, les sites ne doivent pas absolument atteindre son seuil bon ». Bon ≤ 0,8 s. Diagnostic.
• First Contentful Paint (FCP) — délai avant l’affichage du premier contenu. Diagnostic de chargement utile, bon ≤ 1,8 s, mais pas une mesure cœur.
• Total Blocking Time (TBT) — approximation de laboratoire d’INP. Les outils tels que Lighthouse “cannot measure INP” (traduction) « ne peuvent pas mesurer INP » sans utilisateur réel et rapportent TBT. Laboratoire uniquement.
• Speed Index — approximation de la vitesse perçue. Uniquement dans Lighthouse.

Utilisez-les pour diagnostiquer. Ne les présentez ni comme Core Web Vitals ni comme seuils de classement.

Un mythe à abandonner

Vous verrez peut-être « Engagement Reliability » présenté comme nouvelle Core Web Vital. Google n’a publié aucune annonce officielle sur une telle mesure ; elle circule uniquement dans des contenus tiers. La liste reste LCP, INP et CLS jusqu’à annonce contraire.

Comment mesurer — quel outil pour quel usage

Faites correspondre l’outil à la tâche :

• Pertinent pour le classement — terrain : PageSpeed Insights, avec CrUX aux niveaux page et origine ; rapport Core Web Vitals de Google Search Console, qui regroupe les pages semblables ; API CrUX ou BigQuery pour les analyses personnalisées ; bibliothèque JavaScript web-vitals pour votre propre RUM.
• Diagnostic — laboratoire : Lighthouse, panneau Performance de Chrome DevTools et section laboratoire de PSI. Ils identifient la cause, sans décider du classement.

Processus conseillé : utilisez GSC pour repérer les groupes en échec sur le terrain, confirmez avec PageSpeed Insights au niveau page, puis passez à Lighthouse ou DevTools pour diagnostiquer et itérer, sachant que les données de terrain peuvent attendre 28 jours.

Étape suivante : pôle des performances web

Ce hub sert de carte. Chaque sujet suivant possède son guide.

Les trois Core Web Vitals

• Largest Contentful Paint — chargement : élément LCP, cible ≤ 2,5 s et accélération.
• Interaction to Next Paint — réactivité remplaçant FID : délai d’entrée, traitement d’événement et présentation.
• Cumulative Layout Shift — stabilité visuelle : fenêtres de session, médias sans dimensions, polices, publicités injectées et cible ≤ 0,1.

Mesures complémentaires et diagnostiques

• Time to First Byte — latence serveur qui alimente LCP, utile à diagnostiquer.
• First Contentful Paint — premier contenu affiché, diagnostic de chargement.
• Total Blocking Time — approximation de laboratoire d’INP dans Lighthouse.
• Speed Index — approximation en laboratoire de la vitesse perçue.

Méthodes de mesure

• PageSpeed Insights — données de terrain CrUX et rapport Lighthouse au même endroit.
• Google Lighthouse — moteur de laboratoire derrière PSI et DevTools.
• Chrome UX Report (CrUX) — jeu de données réelles utilisé par l’évaluation Google.

Pour l’ensemble, consultez le hub des performances web. Chaque guide associé renverra automatiquement ici lors de sa publication.

Résumé par l’IA

Synthèse de la version Avancé :

• Core Web Vitals = trois mesures de terrain : LCP — chargement, bon ≤ 2,5 s —, INP — réactivité, ≤ 200 ms — et CLS — stabilité, ≤ 0,1. TTFB, FCP, TBT et Speed Index ne sont pas des mesures cœur.
• Évaluation sur le terrain : utilisateurs Chrome réels via CrUX, au 75e centile sur 28 jours. Les seuils mobile et ordinateur sont identiques mais évalués séparément, et les trois doivent être bonnes.
• INP a remplacé FID le 12 mars 2024. FID est retiré ; INP mesure toutes les interactions, pas seulement la première.
• Les outils de laboratoire sont diagnostiques, pas des mesures de terrain, et diffèrent souvent des CWV réelles. Ils trouvent les causes ; le terrain peut attendre 28 jours.
• Le niveau page diffère du niveau origine : environ 21,2 % des pages réussissent, contre 33 % des origines, selon mon étude CWV. Les moyennes d’origine masquent des pages en échec.
• Poids de classement : utilisé, mais non chiffré. Google dit utiliser les CWV sans pourcentage ni étiquette officielle de départage. La pertinence reste décisive et une bonne note n’assure aucun résultat. Mueller : “not giant factors in ranking.” (traduction) « pas des facteurs énormes dans le classement ». Seules les CWV contribuent directement parmi les aspects généraux cités en 2024.
• Mythe : « Engagement Reliability » n’est pas une Core Web Vital confirmée.
• Outils : terrain = PSI, rapport GSC, API CrUX, web-vitals.js ; diagnostic = Lighthouse, DevTools et laboratoire PSI.

Documentation officielle

Sources primaires de Google.

web.dev — équipe Chrome

• Web Vitals — initiative, trois mesures, règle p75 et autres Web Vitals TTFB/FCP.
• Largest Contentful Paint — définition, seuils et éléments admissibles.
• Interaction to Next Paint — définition, seuils, délai d’entrée, traitement et présentation.
• Cumulative Layout Shift — définition, fenêtres de session et causes.
• Définition des seuils Core Web Vitals — choix des seuils « bons » et du 75e centile.
• Différences entre données de laboratoire et de terrain — raisons des écarts CrUX/Lighthouse.
• Processus et outils Core Web Vitals — outils de terrain et laboratoire.
• INP devient une Core Web Vital — mai 2023 — annonce du remplacement de FID.
• INP est officiellement une Core Web Vital — 12 mars 2024 — confirmation du lancement.
• TTFB et FCP — autres Web Vitals diagnostiques.

Google Search Central

• Comprendre les Core Web Vitals et les résultats Google — lien avec le classement.
• Comprendre l’expérience de page dans les résultats Google — cadre général et priorité à la pertinence.
• Présentation d’INP dans les Core Web Vitals — mai 2023 — annonce Search Central.

Documentation Chrome pour les développeurs

• Rapport d’expérience utilisateur Chrome — CrUX — données réelles, admissibilité et fenêtre de 28 jours.

Citations des sources

Déclarations officielles de Google. Chaque lien profond mène au passage cité.

Google — définition des Core Web Vitals

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (traduction) « Les Core Web Vitals sont le sous-ensemble applicable à toutes les pages, que tous les propriétaires doivent mesurer et que tous les outils Google présenteront. » — Philip Walton, web.dev. Accéder à la citation
• “LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (traduction) « LCP indique le temps de rendu de la plus grande image, du plus grand bloc de texte ou de la vidéo visible, depuis le début de la navigation. » — web.dev, LCP. Accéder à la citation
• “INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (traduction) « INP évalue la réactivité globale en observant la latence de tous les clics, touchers et interactions clavier durant la visite. » — web.dev, INP. Accéder à la citation
• “CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (traduction) « CLS mesure la plus grande rafale de scores pour chaque décalage inattendu durant toute la vie d’une page. » — web.dev, CLS. Accéder à la citation

Google — remplacement de FID par INP

• “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” (traduction) « Interaction to Next Paint est désormais une mesure Core Web Vital stable, remplaçant First Input Delay. » — Rick Viscomi, web.dev, 12 mars 2024. Accéder à la citation

Google — terrain, laboratoire et classement

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (traduction) « Si une page dispose de données de terrain et de laboratoire, utilisez celles de terrain pour prioriser. » — Philip Walton, web.dev. Accéder à la citation
• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (traduction) « Le Chrome User Experience Report, ou CrUX, reflète la manière dont de vrais utilisateurs Chrome vivent les destinations populaires du Web. » — documentation CrUX de Chrome for Developers. Accéder à la citation

John Mueller, Google

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” (traduction) « C’est un facteur de classement, plus qu’un critère de départage, mais il ne remplace pas la pertinence. » — via Search Engine Journal, Reddit, août 2021. Lire l’article
• “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that.” (traduction) « Les Core Web Vitals ne sont pas des facteurs énormes et je doute qu’elles provoquent seules une forte baisse. » — via Stan Ventures, 2024. Lire l’article

Liste de contrôle des Core Web Vitals

Contrôle rapide pour mesurer la bonne chose et corriger les bonnes pages :

• Lire les données de terrain CrUX, pas uniquement un score de laboratoire, pour les mesures utilisées par Google.
• Examiner les valeurs au niveau page, pas seulement la moyenne de l’origine.
• Vérifier les trois : LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 au p75.
• Examiner mobile et ordinateur séparément.
• Ne pas optimiser FID ; il a été retiré le 12 mars 2024 au profit d’INP.
• Examiner dans GSC les groupes de pages en échec, pas seulement des cas isolés.
• Comprendre que les pages peu fréquentées peuvent n’avoir aucune donnée CrUX.
• Utiliser Lighthouse ou PSI pour diagnostiquer, pas comme verdict de réussite, sans attendre un score Performance parfait.
• Laisser jusqu’à 28 jours pour que les corrections apparaissent sur le terrain.
• Ne pas poursuivre les CWV avant la pertinence du contenu et les gains SEO majeurs.

Modèles mentaux

1. Trois dimensions, trois mesures. LCP = chargement, INP = réactivité, CLS = stabilité visuelle. Nommer la dimension du problème indique la mesure et le guide à ouvrir.

2. Le terrain sert au classement ; le laboratoire sert à corriger. Google s’appuie sur CrUX au p75 sur 28 jours. Lighthouse et PSI trouvent les causes. Ne traitez jamais un score de laboratoire comme votre valeur de classement ; ils ne correspondent souvent même pas.

3. Le niveau page vaut mieux que le niveau origine. Une origine « bonne » peut masquer des pages en échec. Google utilise les données de page lorsqu’elles existent. Si un outil montre les deux, consultez la page.

4. Utilisé, mais non pondéré publiquement. CWV est un signal confirmé auquel Google n’attribue aucun poids officiel ; la pertinence peut l’emporter. Corrigez pour les utilisateurs et conversions, sans promettre un bond du classement.

5. Test « est-ce vraiment une mesure cœur ? » Seules LCP, INP et CLS sont des Core Web Vitals. TTFB et FCP sont diagnostiques ; TBT et Speed Index sont des approximations de laboratoire. « Engagement Reliability » n’est pas confirmé.

Aide-mémoire des Core Web Vitals

Les trois Core Web Vitals — données de terrain, p75

Mesures diagnostiques — PAS des Core Web Vitals

Repères rapides

• Évaluation = CrUX, 75e centile, fenêtre glissante de 28 jours, mobile et ordinateur séparément.
• INP a remplacé FID le 12 mars 2024. FID est retiré.
• Les scores Lighthouse et PSI sont diagnostiques, pas des mesures de terrain, et ne correspondent souvent pas aux CWV réelles.
• Google privilégie le niveau page ; la moyenne d’origine peut tromper — environ 21,2 % des pages contre 33 % des origines dans mon étude CWV.
• Poids : utilisé par les systèmes Google, sans poids officiel. La pertinence domine et un bon score ne garantit rien.
• « Engagement Reliability » n’est pas une Core Web Vital confirmée.

Quelle Core Web Vital examiner en premier ?

Régression des Core Web Vitals après une version

1. Confirmez le signal. Distinguez terrain et laboratoire, URL et origine, mobile et ordinateur. Si une seule exécution de laboratoire change, reproduisez-la avant de déclarer un incident.
2. Identifiez la mesure en échec. LCP, INP et CLS représentent des problèmes différents. Si plusieurs évoluent, contrôlez d’abord la version partagée et les scripts tiers.
3. Reliez la régression au déploiement. Comparez RUM ou des traces reproductibles avant et après. Si les dates ne coïncident pas, examinez le mélange trafic/appareils.
4. Diagnostiquez la mesure, pas le score. Pour LCP, inspectez l’élément et ses sous-parties ; pour INP, les interactions lentes et le thread principal ; pour CLS, les sources de décalage.
5. Livrez la plus petite correction attribuable. Validez-la immédiatement au laboratoire. Annulez si elle casse une fonction ou dégrade une autre mesure.
6. Observez les vrais utilisateurs. Utilisez RUM comme signal avancé et CrUX ou Search Console comme verdict glissant. Documentez le périmètre et la fenêtre afin que personne n’attende une réinitialisation CrUX le jour même.

Erreurs Core Web Vitals qui gaspillent du travail

Optimiser le score composite Lighthouse

L’évaluation de terrain de Google utilise LCP, INP et CLS issus d’utilisateurs réels, pas le nombre Performance unique de Lighthouse. Diagnostiquez la mesure de terrain en échec et utilisez Lighthouse comme environnement de débogage contrôlé.

Traiter les Core Web Vitals comme un raccourci de classement

Les CWV sont un signal d’expérience auquel Google n’a jamais attribué de poids officiel. La qualité du contenu reste prioritaire. Corrigez une mauvaise expérience pour les utilisateurs, mais ne promettez pas de bond du classement et ne remplacez pas sans preuve les travaux plus importants sur le contenu ou l’indexation.

Mélanger URL, origine, mobile et ordinateur

Ces périmètres peuvent raconter des histoires différentes. Étiquetez chaque valeur et ne déclarez pas qu’une page réussit parce que le repli d’origine ou l’agrégat ordinateur est vert.

Attendre CrUX avant de vérifier une version

La fenêtre glissante de 28 jours est trop lente pour l’assurance qualité d’un déploiement. Validez immédiatement au laboratoire et avec RUM, puis utilisez CrUX pour confirmer le résultat de terrain à plus long terme.

Outils de mesure des Core Web Vitals

Vérifiez avec l’ historique Core Web Vitals et comparaison des concurrents :

1. Ajoutez un site — une origine nue telle que example.com possède généralement le plus de données CrUX ; ajoutez-en jusqu’à cinq pour comparer.
2. Choisissez mobile ou ordinateur, puis lancez la comparaison.
3. Consultez la fiche de réussite actuelle pour LCP, INP et CLS, puis la tendance hebdomadaire afin de voir si chaque mesure se rapproche ou s’éloigne de la zone bonne.

Données de terrain — mesure réelle des Core Web Vitals

• PageSpeed Insights — données CrUX aux niveaux page et origine, accompagnées d’un rapport Lighthouse.
• Google Search Console — rapport Core Web Vitals — groupes de pages similaires et tendances globales ; moyen rapide de repérer les groupes en échec.
• API CrUX ou BigQuery — analyses personnalisées et par pays depuis la source.
• Bibliothèque JavaScript web-vitals — collecte de vos propres données RUM, par exemple vers l’analytique.

Données de laboratoire — diagnostic, pas classement

• Lighthouse — possibilités de diagnostic et score Performance non utilisé pour le classement.
• Panneau Performance de Chrome DevTools — traces détaillées de LCP, décalages et tâches longues.
• Section laboratoire de PageSpeed Insights — recommandations Lighthouse sous les données de terrain.

Règle pratique : GSC pour repérer où le terrain échoue → PSI pour confirmer au niveau page → Lighthouse ou DevTools pour diagnostiquer et itérer.

Ressources utiles

Mes articles liés

• Core Web Vitals : comment les améliorer — guide pratique complet des trois mesures.
• Étude de données Core Web Vitals — CrUX et 5,2 millions de pages, comparaison page/origine.
• Guide Largest Contentful Paint.
• Guide Cumulative Layout Shift.
• Guide PageSpeed Insights.
• Guide du débutant pour le SEO technique — place de l’expérience de page.

Sources officielles

• web.dev — Web Vitals et articles par mesure liés dans la section Documentation officielle.
• Google actualise sa documentation sur l’expérience de page — Barry Schwartz sur le changement de mars 2024.

Sources du secteur

• Core Web Vitals comme facteur : plus qu’un départage — déclaration Reddit de Mueller selon laquelle CWV dépasse un critère de départage sans remplacer la pertinence.
• Priorité des Core Web Vitals pour les petites entreprises locales — commentaire Mastodon de Mueller sur la faible priorité.
• Confirmation : les Core Web Vitals ne sont pas un grand facteur — citation de Mueller dans son contexte.
• Impact des Core Web Vitals sur le SEO — synthèse actualisée en novembre 2025.
• Mise à jour de l’expérience de page : départage — ancien cadrage de Mueller et Illyes avant le lancement.

Statistiques utiles à citer

• Seulement environ 21,2 % des pages individuelles réussissent les trois Core Web Vitals, contre environ 33 % des origines, selon mon étude CrUX et 5,2 millions de pages Ahrefs Site Audit. Google évalue généralement les pages individuellement ; une moyenne d’origine favorable peut masquer des échecs. Source
• LCP est la difficulté principale. L’étude constatait des progrès sur l’ancien FID et CLS, mais un retard sur LCP, avec “almost no sites on 3G or slower connections are passing.” (traduction) « presque aucun site sur une connexion 3G ou plus lente ne réussit ». Source
• Seuils bons : LCP ≤2,5 s, INP ≤200 ms, CLS ≤0,1, chacun au 75e centile des données de terrain. Source
• INP a remplacé FID le 12 mars 2024, date du retrait de FID de Search Console. Source

Testez vos connaissances : Core Web Vitals

Cinq questions rapides sur les Core Web Vitals. Choisissez une réponse, puis vérifiez-la.

Prouver qu’une correction LCP, INP ou CLS est effective

Le piège consiste à fêter le score de laboratoire dès le déploiement. Lighthouse indique si le changement peut fonctionner ; seules les données de terrain CrUX montrent l’effet pour les vrais utilisateurs, avec une fenêtre glissante de 28 jours. Exécutez les deux dans cet ordre.

Test 1 — amélioration au laboratoire

• Test : exécutez la page dans le vérificateur Core Web Vitals, Lighthouse ou PageSpeed Insights, avant et après la modification.
• Résultat attendu : la mesure ciblée évolue dans le bon sens — élément LCP affiché plus tôt, aucun nouveau décalage, diagnostic corrigé.
• Interprétation d’un échec : aucune évolution signifie que le changement n’a pas touché le chemin critique — mauvais élément LCP ou script non bloquant.
• Fenêtre de surveillance : immédiate, les tests étant exécutés à la demande.
• Déclencheur de retour arrière : régression d’une autre mesure — correction LCP qui introduit CLS ou JavaScript qui dégrade INP — détectée avant les utilisateurs.

Test 2 — effet réel pour les utilisateurs

• Test : suivez le p75 de LCP, INP et CLS de la page ou origine dans CrUX, via l’historique et comparaison Core Web Vitals ou le rapport GSC.
• Résultat attendu : le p75 de la mesure corrigée passe dans la zone « Bonne » et y reste — seuils Google : LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1.
• Interprétation d’un échec : le laboratoire s’améliore mais pas le terrain ; la correction aide un test sur connexion rapide, pas le mélange réel d’appareils et réseaux, ou trop peu d’URL du groupe la partagent.
• Fenêtre de surveillance : 28 jours glissants. Il faut environ quatre semaines de données accumulées avant de faire confiance au p75 ; ne concluez pas après une semaine.
• Déclencheur de retour arrière : le p75 repasse le seuil « médiocre » ou le nombre d’URL bonnes dans GSC baisse après une modification de modèle.

Indicateur permanent du sujet

Au-delà d’une correction particulière, observez chaque trimestre la santé de l’expérience de page. Google publie des seuils défendables ; aucun nombre n’est inventé.

p75 de LCP, INP et CLS — données de terrain

• Mesure : valeur au 75e centile de chaque Core Web Vital sur les visites réelles, par groupe de pages et appareil.
• Interprétation : indique si 75 % des utilisateurs bénéficient d’une bonne expérience, barre exacte utilisée par Google. Le p75, pas la moyenne, reflète la traîne lente.
• Collecte : CrUX via l’ historique et comparaison Core Web Vitals, rapport GSC regroupé par modèle d’URL, ou PageSpeed Insights pour une URL.
• Référence : seuils Google LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 pour « Bon » ; zones « À améliorer » et « Médiocre » : 2,5–4 s / >4 s, 200–500ms / >500ms et 0,1–0,25 / >0,25.
• Cadence : fenêtre glissante de 28 jours, donc revue mensuelle. Le laboratoire sert d’indicateur avancé et le p75 CrUX d’indicateur retardé.

Couverture des URL « bonnes » sur le site

• Mesure : part des URL indexées dans la catégorie « Bonnes » du rapport Core Web Vitals GSC, mobile et ordinateur séparément.
• Interprétation : étendue de la propagation des corrections ; une page rapide isolée ne modifie pas le site, une amélioration de modèle le fait.
• Collecte : GSC → rapport Core Web Vitals → nombre d’URL bonnes, à améliorer et médiocres dans le temps.
• Référence : contextuelle selon les modèles et le trafic. Établissez votre propre base et augmentez la part bonne plutôt que de poursuivre un pourcentage inventé.
• Cadence : mensuelle, ou hebdomadaire après une modification de thème pendant que la fenêtre de terrain se met à jour.

Journal des modifications