Rapport Core Web Vitals dans Google Search Console

En bref — Le rapport Core Web Vitals de Google Search Console montre les performances de vos pages pour de vrais visiteurs selon les trois mesures de vitesse et de stabilité de Google — LCP, INP et CLS. Il s’appuie sur des données réelles d’utilisateurs de Chrome, regroupe les pages similaires et sépare les résultats dans les onglets Mobile et Desktop. C’est un outil de diagnostic à l’échelle du site, pas un test de vitesse page par page ; un site petit ou récent peut ne présenter aucune donnée.

Qu’est-ce que le rapport Core Web Vitals ?

Vous le trouverez dans la section Expérience de Google Search Console. Google le décrit en une phrase : il “shows how your pages perform, based on real world usage data (sometimes called field data).” (traduction) « montre les performances de vos pages à partir de données d’utilisation réelles, parfois appelées données de terrain ».

Premier point à bien comprendre : il s’agit d’un rapport, pas des mesures elles-mêmes. Les Core Web Vitals — LCP, INP et CLS — mesurent trois dimensions de l’expérience d’un visiteur réel : la vitesse d’affichage du contenu principal, la rapidité de réaction à une interaction et l’ampleur des déplacements de contenu pendant le chargement. Ces mesures sont définies en détail ailleurs sur ce site. Cet article traite du rapport, l’outil de Search Console qui affiche et organise ces données.

D’où viennent les données ?

Le rapport n’exécute pas de test de vitesse. Il récupère les données de terrain du Chrome User Experience Report (CrUX), c’est-à-dire des temps anonymisés observés auprès d’utilisateurs réels de Chrome ayant visité vos pages. Ce fonctionnement diffère d’un test de laboratoire comme PageSpeed Insights, qui charge une fois votre page dans un environnement contrôlé. Les données de terrain reflètent ce que les visiteurs ont réellement vécu, sur une fenêtre glissante de 28 jours.

Comment le rapport est-il organisé ?

Trois principes régissent le regroupement de vos URL :

• Mobile et Desktop sont deux onglets distincts. Une page peut être « Good » sur mobile et « Poor » sur ordinateur au même moment. Les résultats ne sont jamais moyennés.
• Trois états : Poor, Need improvement et Good. L’état d’une URL dépend de sa mesure la plus faible : un seul mauvais résultat dégrade toute la page.
• Les URL sont regroupées, pas évaluées une par une. Google rassemble les pages similaires, généralement fondées sur le même modèle ; un problème peut donc toucher tout un lot d’URL.

L’erreur d’interprétation la plus courante

Ce rapport ne permet pas de déterminer de façon fiable si une page précise est lente. Google le dit clairement : il n’est “not designed [to] find the status of a specific URL, but rather to see your site’s performance as a whole.” (traduction) « pas conçu pour déterminer l’état d’une URL précise, mais pour observer les performances du site dans son ensemble ». Il sert à repérer des problèmes généraux liés aux modèles de pages. Pour contrôler une page, utilisez plutôt PageSpeed Insights ou l’outil URL Inspection.

Deux autres points sont utiles dès le départ :

• « No data available » est fréquent et ne signale généralement pas un problème de page. Deux causes sont possibles : la propriété vient d’être ajoutée à Search Console, ou le trafic Chrome est insuffisant sur l’appareil consulté — mobile ou ordinateur — pour atteindre le seuil de publication de Google.
• Le rapport accuse environ un mois de retard. Comme il repose sur une moyenne de 28 jours, une correction déployée aujourd’hui n’y apparaîtra pleinement qu’après plusieurs semaines. Utilisez PageSpeed Insights pour obtenir un retour plus rapide.

Pour comprendre le fonctionnement complet — regroupement des URL, écarts avec PageSpeed Insights, validation et remplacement de FID — passez à l’onglet Avancé.

En bref — Le rapport Core Web Vitals expose les données de terrain CrUX de vos URL indexées — fenêtre glissante de 28 jours, 75e centile — sans calculer de nouvelle mesure. Il regroupe les URL par appareil — onglets Mobile et Desktop indépendants —, par état — Poor, Need improvement ou Good, la plus mauvaise mesure l’emportant — et par groupe d’URL, c’est-à-dire des pages utilisant des modèles similaires et partageant un état. Seules des URL indexées apparaissent, sous forme d’échantillon. Si un groupe d’URL est trop petit pour respecter la confidentialité, Google remonte à un groupe d’origine ; si celui-ci reste insuffisant, le rapport affiche « No data available ». Il diffère de PageSpeed Insights — groupe contre URL individuelle ; GSC conserve les paramètres, PSI les retire — et sert au diagnostic du site, pas à la consultation d’une URL isolée. FID a été retiré le 12 mars 2024, lorsque INP est devenu une Core Web Vital : GSC l’a supprimé immédiatement, contrairement à la période de transition de six mois de PSI et CrUX. Corrigez d’abord l’état Poor, lancez Start Tracking, puis laissez environ un mois aux données de terrain pour évoluer.

Un rapport, pas une redéfinition des mesures

Le cadre le plus utile est simple : le rapport Core Web Vitals donne accès à des données qui existent déjà ; il ne crée pas de nouvelle mesure. Google précise que “the data for the Core Web Vitals report comes from the CrUX report. The CrUX report gathers anonymized metrics about performance times from actual users visiting your URL (called field data). The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” (traduction) « les données du rapport Core Web Vitals proviennent du rapport CrUX. CrUX collecte des mesures anonymisées des temps de performance auprès d’utilisateurs réels qui visitent votre URL, appelées données de terrain. Sa base collecte des informations sur les URL, qu’elles appartiennent ou non à une propriété Search Console ».

Le rapport contient donc zéro donnée de laboratoire : aucun score Lighthouse ni test synthétique. Il repose à 100 % sur des données de terrain provenant de vrais utilisateurs de Chrome, sur 28 jours glissants, au 75e centile et par appareil. Les définitions, seuils et nuances de classement des mesures se trouvent dans le glossaire Core Web Vitals et le sujet Web Vitals. Ici, nous étudions uniquement l’outil.

Seulement des URL indexées, et seulement un échantillon

Trois limites sont souvent oubliées. Premièrement, un groupe d’URL n’apparaît qu’après avoir atteint un seuil de données pour LCP et CLS ; faute de données suffisantes pour les deux, il est omis, pas considéré comme réussi. Deuxièmement : “Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” (traduction) « seules les URL indexées peuvent apparaître dans ce rapport. Celui-ci ne fournit pas une liste exhaustive de toutes les URL indexées, mais un échantillon de pages permettant d’évaluer les performances Core Web Vitals du site ». Ne le prenez donc pas pour un audit exhaustif. Troisièmement : “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” (traduction) « les données sont attribuées à l’URL réelle, pas à l’URL canonique comme dans la plupart des autres rapports ». Contrairement à la majorité des rapports Search Console, celui-ci ne consolide pas les données sur la canonique.

Mobile et Desktop sont des jeux de données indépendants

Le rapport ventile tout par appareil. Les deux onglets sont entièrement séparés et ne sont jamais moyennés. Un groupe d’URL peut être Good sur mobile et Need improvement sur ordinateur, car les jeux CrUX reflètent des appareils, réseaux et processeurs différents. Vérifiez toujours les deux onglets : un résumé Good dans l’un peut masquer un lot Poor dans l’autre.

État : la mesure la plus faible l’emporte

Chaque groupe d’URL relève de l’un des trois états — Poor, Need improvement ou Good — selon sa mesure la moins performante. Un groupe dont LCP et INP sont bons, mais CLS mauvais, reste Poor. Cette règle explique pourquoi un seul élément instable peut dégrader un modèle de page autrement rapide.

Les seuils sous-jacents — LCP ≤ 2,5 s, INP ≤ 200ms et CLS ≤ 0,1 pour l’état Good, au p75 — relèvent de la définition des mesures et sont détaillés dans le glossaire Core Web Vitals. Au moment de mes recherches, la documentation Search Central affichait toujours ces valeurs. Je n’ai trouvé aucune source appartenant à Google confirmant que le seuil LCP Good aurait discrètement baissé à 2,0 secondes ou qu’une mise à jour majeure de fin 2025 aurait fortement accru le poids des Core Web Vitals ; la documentation les contredit. Traitez ces affirmations comme des rumeurs.

Les groupes d’URL : le mécanisme central

C’est la caractéristique déterminante du rapport et le principal changement de modèle mental pour qui utilise PageSpeed Insights URL par URL. Google explique : “URLs in the report are grouped into pages that have a similar user experience. The LCP, INP, and CLS status applies to the entire group. Some outlier URLs might have better or worse values on some visits, but 75% of visits to all URLs in the group experienced the group status shown.” (traduction) « le rapport rassemble les pages offrant une expérience proche. Les états LCP, INP et CLS valent pour l’ensemble ; malgré quelques URL atypiques, le résultat affiché correspond à l’expérience de 75 % des visites du groupe ».

John Mueller décrivait ce mécanisme en 2021 : “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” (traduction) « nous utilisons les données réelles de terrain du Chrome User Experience Report pour reconnaître des pages suffisamment similaires afin de les regrouper ». Les données du groupe peuvent aussi représenter une URL dépourvue de données propres : “If we find a new URL that is also a part of this group, we don’t have to have data for that new URL. We can rely on the data for the group overall.” (traduction) « si une nouvelle URL appartient également à ce groupe, nous n’avons pas besoin de données pour cette URL ; nous pouvons nous appuyer sur celles du groupe entier ».

C’est aussi pourquoi le rapport peut sembler alarmant alors qu’un seul défaut est en cause. Mueller poursuit : “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” (traduction) « selon Mueller, un groupe unique peut réunir des milliers d’URL ; le rapport attribue alors ce problème à chacune d’elles ». Un défaut de modèle suffit à signaler des milliers d’URL.

Voilà précisément pourquoi le regroupement est utile. Dans le guide Core Web Vitals d’Ahrefs, j’écris : “This grouping of pages makes a lot of sense. This is because most of the changes to improve Core Web Vitals are done for a particular page template that impacts many pages.” (traduction) « ce regroupement est logique, car la plupart des améliorations Core Web Vitals s’appliquent à un modèle qui touche de nombreuses pages ». Dans le guide PageSpeed Insights : “The benefit of GSC is that it buckets similar URLs. For the bucketed pages, you will likely be working in one system or template.” (traduction) « GSC regroupe les URL similaires ; pour ces pages, vous travaillerez probablement dans un même système ou modèle ». Corriger le modèle une fois corrige tout le groupe. Je l’expliquais aussi dans un entretien avec Outside Communications : “Basically, here are groups with issues that probably share the exact same theme. You fix it once, you fix that issue for all those pages.” (traduction) « ces groupes problématiques partagent probablement le même thème ; une seule correction résout le problème pour toutes ces pages ».

Seuil de confidentialité et repli vers le groupe d’origine

Le regroupement répond aussi à une exigence de confidentialité. Google indique : “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” (traduction) « pour respecter la confidentialité, un groupe d’URL doit réunir un volume minimal de données. S’il est insuffisant, Search Console crée un groupe d’origine de niveau supérieur censé réunir assez d’URL et de données ». La cascade est donc : groupe d’URL → groupe d’origine → aucune donnée. Si même l’origine n’atteint pas le seuil, « No data available » apparaît. C’est pourquoi les sites à faible trafic obtiennent des groupes grossiers ou aucun résultat.

Pourquoi un groupe Poor peut contenir des pages rapides

L’état s’appliquant à tout le groupe au 75e centile, une URL rapide peut se retrouver dans un groupe lent. Appartenir à un groupe Poor ne prouve pas que cette URL est lente ; cela signifie que le groupe, dans son ensemble, présente un problème. Le groupe reste l’unité d’analyse.

Lire le rapport : graphique et tableau

Le graphique d’accueil et le tableau des problèmes ne comptent pas de la même façon : “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” (traduction) « le graphique compte chaque URL une seule fois, selon le problème le plus lent ; le tableau compte au contraire tous les problèmes associés à une URL ». Une URL touchée par un problème Poor et un autre Need improvement apparaît une fois — comme Poor — dans le graphique, mais dans les deux lignes du tableau. Les totaux diffèrent donc par conception. En ouvrant un problème, comme je l’explique, vous obtenez une ventilation des groupes de pages touchés, avec des exemples d’URL classés par impressions.

Valider les corrections avec Start Tracking

Le rapport possède une boucle de validation intégrée facile à négliger. Google indique : “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” (traduction) « lorsque vous pensez avoir corrigé un problème, cliquez sur Start Tracking dans sa page de détail du rapport Core Web Vitals ». Une session de suivi de 28 jours commence alors : Google attend l’accumulation des données de terrain du groupe au lieu de relancer un contrôle instantané. Trois précisions comptent : une seule URL encore en échec pendant cette période peut faire échouer tout le problème ; ses états sont Not started (« non commencé »), Started (« lancé »), Looking good (« en bonne voie »), Passed (« réussi »), N/A ou Failed (« échec »), et ceux des URL Pending, Passed ou Failed ; enfin, Start Tracking ne déclenche aucune réindexation ni exploration active. Il s’agit uniquement d’un indicateur de suivi appliqué aux données déjà collectées. C’est la bonne manière de confirmer une correction sur le terrain.

Rapport Core Web Vitals et PageSpeed Insights

Ces deux outils puisent dans CrUX, mais présentent les données différemment et peuvent régulièrement diverger pour une même URL. Deux raisons sont documentées :

• Groupe contre URL individuelle. Google : “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” (traduction) « Core Web Vitals regroupe les données et états par groupes d’URL ; PageSpeed Insights affiche généralement les données d’URL individuelles ». Une URL atypique peut donc différer de l’état de son groupe.
• Paramètres d’URL. “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” (traduction) « Core Web Vitals tient compte des paramètres pour distinguer les pages ; PageSpeed Insights les retire et attribue les résultats à l’URL nue ». Cette différence explique de nombreux écarts.

Il faut aussi distinguer la portée des données, car les expressions « données de terrain » et « données de laboratoire » sont souvent employées avec imprécision. Le rapport GSC contient uniquement des données de terrain CrUX regroupées. PageSpeed Insights réunit trois sources : les données CrUX de l’URL, un repli sur les données CrUX de l’origine lorsque l’URL est insuffisamment documentée et une exécution de laboratoire Lighthouse. Comme je le précise dans le guide PSI, “PageSpeed Insights also pulls in the page level data, as well as origin data and lab test data which comes from Lighthouse.” (traduction) « PageSpeed Insights récupère les données de la page, celles de l’origine et les données de laboratoire provenant de Lighthouse ». Le rapport GSC ne contient aucune couche de laboratoire.

Mon processus est le suivant : diagnostiquer et valider rapidement avec les données de laboratoire PSI, puis confirmer lentement, mais réellement, dans GSC. Le guide PSI précise : “The CWV data will take longer to show the impact of any changes because it is a 28-day average, so use PSI or the PSI data in Ahrefs to check if the changes you made improved the lab test metrics.” (traduction) « les données CWV mettent plus longtemps à refléter les changements, car elles reposent sur une moyenne de 28 jours ; utilisez PSI ou ses données dans Ahrefs pour vérifier l’amélioration des mesures de laboratoire ». Le laboratoire fournit un retour immédiat ; GSC confirme ensuite l’effet de terrain au fil des semaines.

« No data available » et sites à faible trafic

Google explique : “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” (traduction) « si l’écran No data available apparaît, la propriété est soit nouvelle dans Search Console, soit insuffisamment documentée dans CrUX pour l’appareil choisi, ordinateur ou mobile ». Une URL ou une origine doit atteindre un seuil de trafic Chrome avant que des données de terrain soient publiées.

Cette situation est très courante. Dans mon étude de janvier 2022 portant sur 43,66 millions de pages Site Audit uniques, “We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” (traduction) « seulement 5,21 millions de pages, soit environ 11,9 %, possédaient au moins une mesure Core Web Vitals, et 93 % d’entre elles — environ 4,85 millions — disposaient des trois ». L’étude portait sur le jeu CrUX brut, source du rapport GSC, et ses chiffres datent de janvier 2022 : ils donnent un ordre de grandeur, pas un taux actuel. Beaucoup de pages ne génèrent tout simplement pas assez de trafic Chrome, d’où le recours au groupe d’origine et les rapports vides. Cette absence ne vaut pas certificat de bonne santé : testez les URL dans PageSpeed Insights ou Lighthouse.

FID a disparu : ce qui a changé en mars 2024

Il faut être précis, car d’anciens tutoriels se trompent encore. Interaction to Next Paint (INP) a remplacé First Input Delay (FID) comme Core Web Vital le 12 mars 2024. L’annonce de l’équipe Chrome sur web.dev apporte une précision propre à Search Console : “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” (traduction) « dès le 12 mars, FID disparaîtra de Google Search Console avec l’arrivée d’INP ; PageSpeed Insights, CrUX et les autres outils laisseront six mois aux développeurs pour adapter leur code ». GSC a donc supprimé FID immédiatement, sans délai, tandis que PSI et CrUX l’ont conservé six mois. Une capture Search Console affichant FID date d’avant mars 2024.

Qu’est devenu le rapport Page Experience ?

Google a retiré de Search Console le rapport autonome Page Experience le 19 avril 2023. Cet ancien tableau de synthèse réunissait Core Web Vitals, HTTPS et d’autres signaux d’expérience. Les rapports Core Web Vitals et HTTPS ont toutefois subsisté comme rapports indépendants ; seul le résumé combiné a disparu. Si vous cherchez un tableau « Page Experience », voilà pourquoi il est introuvable. Les rapports Performance et Page Indexing couvrent d’autres dimensions de Search Console.

Prioriser et corriger les problèmes du rapport

Google sépare ses conseils entre publics non techniques et développeurs, signe que ce rapport s’adresse à des profils variés. La règle commune est : corriger d’abord Poor, puis Need improvement. Pour les développeurs, les URL d’un groupe sont triées par impressions décroissantes ; celles du haut influencent le plus l’état du groupe.

Parmi les corrections de page, Google donne une règle directe : “Reduce your page size: best practice is less than 500KB for a page and all its resources.” (traduction) « réduisez le poids de la page : la bonne pratique consiste à rester sous 500KB pour la page et toutes ses ressources ». Les méthodes d’amélioration de LCP, INP et CLS appartiennent aux sujets consacrés à chaque mesure. Le rapport sert à identifier les modèles à corriger, pas à les corriger lui-même.

Pourquoi l’état change-t-il sans modification du site ?

C’est fréquent et généralement normal. Google explique : “If you didn’t make any changes in your site, but you see a big change in status for a lot of pages, it’s possible that you had a borderline status for many pages, and some site-wide event pushed your pages over the edge.” (traduction) « si vous n’avez rien modifié, mais constatez un changement d’état important sur de nombreuses pages, celles-ci étaient peut-être proches d’un seuil et un événement global les a fait basculer ». Une évolution du trafic, de la latence du CDN ou des images, ou une mise à jour largement adoptée du navigateur peut déplacer tout un lot d’URL proches du seuil, car le rapport agrège le p75 sur 28 jours.

Le nombre d’URL admissibles fluctue aussi. En juillet 2025, lorsque le nombre d’URL disposant de données a diminué, surtout sur mobile, John Mueller a décrit ce mouvement comme une variation normale de la taille de l’échantillon, pas comme un problème : ces rapports reposent sur des échantillons de ce que Google connaît d’un site, et leur taille change. Barry Pollard, de l’équipe Core Web Vitals, a reconnu cette baisse et annoncé le déploiement d’un correctif. Retenez que le nombre d’URL admissibles et la qualité des mesures sont distincts : un échantillon changeant ne signifie pas que vos pages ont ralenti.

Le rapport influence-t-il le classement ?

Le rapport reflète les mêmes données de terrain que les systèmes de classement de Google peuvent prendre en compte. Les représentants de Google ont toutefois toujours présenté les Core Web Vitals comme un signal mineur, proche d’un critère de départage face à la pertinence du contenu ; le glossaire Core Web Vitals détaille cette pondération. Mon avis : atteindre ces seuils modifie probablement peu les classements aujourd’hui, même si Google pourrait renforcer le signal à l’avenir, comme pour la compatibilité mobile et HTTPS. Une autre raison compte : les pages rapides enregistrent davantage de données dans CrUX et vos outils d’analyse, car moins de visiteurs partent avant la fin du chargement. Ces améliorations valent surtout comme indicateur d’une meilleure expérience réelle.

Un mot sur Bing

Bing Webmaster Tools ne propose pas d’équivalent direct : aucun rapport Core Web Vitals de terrain avec regroupement d’URL comparable à CrUX. Bing met plutôt l’accent sur un rapport Performance — clics et impressions — et un audit technique Site Scan. Ses guides mentionnent des mesures de type Core Web Vitals, mais aucun rapport de terrain regroupé semblable à celui de Google n’a été publié. Les outils Bing évoluent souvent ; vérifiez la documentation actuelle si ce point est important pour vous.

Place du rapport dans Search Console

Ce rapport est l’un des nombreux rapports de Google Search Console. Performance décrit les résultats dans la recherche — clics, impressions et position — tandis que Page Indexing couvre l’indexation. Les éléments exposés ici — Core Web Vitals, CrUX et son complément de laboratoire PageSpeed Insights — font l’objet de guides approfondis dans le groupe consacré aux performances Web.

Résumé IA

Version condensée de l’onglet Avancé :

• C’est un rapport, pas les mesures. Le rapport Core Web Vitals — GSC → Experience — expose les données de terrain CrUX de vos URL indexées, au 75e centile sur 28 jours. Il ne calcule rien et ne contient aucune donnée de laboratoire.
• Trois regroupements : appareil — onglets Mobile et Desktop indépendants —, état — Poor, Need improvement ou Good, la pire mesure l’emportant — et groupe d’URL — pages aux modèles similaires qui partagent un état.
• Le groupe d’URL est l’unité élémentaire, pas l’URL isolée. Une seule correction de modèle peut supprimer des milliers de signalements. Un groupe Poor peut contenir des pages rapides.
• Cascade de confidentialité : groupe d’URL → groupe d’origine → No data available. Les sites récents ou peu fréquentés n’affichent souvent rien ; environ 12 % des pages seulement possédaient des données CrUX dans l’étude de Patrick en 2022.
• Les résultats diffèrent de PageSpeed Insights : groupe contre URL individuelle ; GSC conserve les paramètres, PSI les retire de l’URL nue.
• Seuil d’admissibilité : un groupe doit disposer de données pour LCP et CLS avant d’apparaître ; sinon il est omis, pas considéré comme réussi. Le rapport ne présente qu’un échantillon d’URL indexées, attribué à l’URL réelle, pas à la canonique.
• Graphique et tableau ne comptent pas de la même manière : le graphique retient une fois chaque URL selon son pire problème, le tableau compte tous les problèmes.
• FID a été retiré le 12 mars 2024 lorsque INP est devenu une Core Web Vital : GSC l’a supprimé immédiatement, contrairement au délai de six mois de PSI et CrUX.
• Le rapport Page Experience a disparu en avril 2023 ; Core Web Vitals et HTTPS subsistent.
• Processus : corrigez Poor en premier, lancez Start Tracking pendant 28 jours — une seule URL encore en échec bloque la validation et rien n’est réindexé —, diagnostiquez rapidement dans PSI, puis attendez environ un mois. Un changement d’état sans modification du site provient souvent d’URL proches d’un seuil ou de variations d’échantillon.

Documentation officielle

Documentation primaire de Google.

Google

• Rapport Core Web Vitals — page d’aide canonique : source CrUX, organisation par appareil, état et groupe d’URL, « No data available », repli sur le groupe d’origine, comptage graphique-tableau, différences avec PageSpeed Insights et validation Start Tracking.
• Interaction to Next Paint devient une Core Web Vital le 12 mars — annonce de l’équipe Chrome, notamment le retrait immédiat de FID dans GSC, contre six mois de transition dans PSI et CrUX.
• Présentation d’INP dans les Core Web Vitals — annonce Search Central de mai 2023 sur la transition FID → INP.
• Comprendre les Core Web Vitals et les résultats Google — synthèse Search Central avec les seuils actuels : 2,5 s, 200ms et 0,1 au moment des recherches.

Citations des sources

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

Google — nature du rapport et provenance des données

• “The Core Web Vitals report shows how your pages perform, based on real world usage data (sometimes called field data).” (traduction) « Le rapport Core Web Vitals montre les performances de vos pages à partir de données d’utilisation réelles, parfois appelées données de terrain. » — Aide Search Console. Accéder à la citation
• “The data for the Core Web Vitals report comes from the CrUX report… The CrUX database gathers information about URLs whether or not the URL is part of a Search Console property.” (traduction) « Les données du rapport Core Web Vitals proviennent de CrUX ; sa base recueille des informations sur les URL, qu’elles appartiennent ou non à une propriété Search Console. » Accéder à la citation
• “Only indexed URLs can appear in this report. This report isn’t a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site’s performance based on Core Web Vitals.” (traduction) « Seules les URL indexées peuvent apparaître dans ce rapport. Il ne fournit pas une liste exhaustive, mais un échantillon permettant d’évaluer les performances Core Web Vitals du site. » Accéder à la citation
• “Data is assigned to the actual URL, not the canonical URL, as it is in most other reports.” (traduction) « Les données sont attribuées à l’URL réelle, pas à l’URL canonique comme dans la plupart des autres rapports. » Accéder à la citation

Google — groupes d’URL et repli pour confidentialité

• « Les URL du rapport sont regroupées avec des pages offrant une expérience utilisateur similaire. Les états LCP, INP et CLS s’appliquent à l’ensemble du groupe. Certaines URL atypiques peuvent obtenir de meilleurs ou de moins bons résultats lors de quelques visites, mais 75 % des visites de toutes les URL ont connu l’état affiché pour le groupe. » Accéder à la citation
• “In order to respect user privacy, a URL group must have a minimum amount of data to be shown in the report. If a URL group doesn’t have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.” (traduction) « Pour respecter la confidentialité, un groupe d’URL doit réunir un minimum de données. Sinon, Search Console crée un groupe d’origine de niveau supérieur censé contenir assez d’URL et de données. » Accéder à la citation

Google — lecture du rapport et validation des corrections

• “The chart counts each URL only once, for the slowest issue affecting that URL. The table, in contrast, counts every issue associated with a URL.” (traduction) « Le graphique compte chaque URL une fois, selon son problème le plus lent ; le tableau compte tous les problèmes associés. » Accéder à la citation
• “The report is not designed find the status of a specific URL, but rather to see your site’s performance as a whole, and troubleshoot issues affecting multiple pages on your site.” (traduction) « Le rapport n’est pas conçu pour déterminer l’état d’une URL précise, mais pour observer les performances globales et résoudre les problèmes touchant plusieurs pages. » Accéder à la citation
• “When you think a particular issue is fixed, click Start Tracking on the issue details page in the Search Console Core Web Vitals report.” (traduction) « Lorsque vous pensez avoir corrigé un problème, cliquez sur Start Tracking dans sa page de détail du rapport Core Web Vitals. » Accéder à la citation

Google — comparaison avec PageSpeed Insights et « No data available »

• “Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs.” (traduction) « Core Web Vitals réunit les données et états en groupes d’URL ; PageSpeed Insights affiche généralement des URL individuelles. » Accéder à la citation
• “Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.” (traduction) « Core Web Vitals inclut les paramètres pour distinguer les pages ; PageSpeed Insights les retire et attribue tous les résultats à l’URL nue. » Accéder à la citation
• “If you see a ‘No data available’ screen, it means either that your property is new in Search Console, or that there is not enough data available in the CrUX report to provide meaningful information for the chosen device type (desktop or mobile).” (traduction) « L’écran No data available signifie que la propriété est nouvelle dans Search Console ou que CrUX ne dispose pas d’assez de données pertinentes pour l’appareil choisi. » Accéder à la citation

Google — transition FID → INP dans Search Console, équipe Chrome sur web.dev

• “FID will be removed from Google Search Console as soon as INP becomes a Core Web Vital on March 12. All other tools—such as PageSpeed Insights and CrUX—will offer a six-month deprecation period to give developers a chance to update their code.” (traduction) « FID sera retiré de Google Search Console dès qu’INP deviendra une Core Web Vital le 12 mars. Les autres outils, comme PageSpeed Insights et CrUX, offriront une période de transition de six mois. » Accéder à la citation

John Mueller, Google — pourquoi le rapport regroupe les URL en 2021

• “We do that with the Chrome User Experience Report data, the field real-world data, essentially, where we try to recognize when there are pages that are similar enough that we could group them together.” (traduction) « Nous utilisons les données réelles de terrain du Chrome User Experience Report pour reconnaître des pages suffisamment similaires afin de les regrouper. »
• “We might have one group, essentially, for a site. But that could contain thousands of URLs. So, in the report in Search Console, I think we would report that as thousands of URLs have this problem.” (traduction) « Un site peut n’avoir qu’un groupe contenant des milliers d’URL ; Search Console indiquera alors que des milliers d’URL présentent ce problème. » Lire l’article

Quel outil ou parcours choisir ?

« Je veux vérifier les Core Web Vitals d’une page précise. » → Pas ce rapport. Utilisez PageSpeed Insights — terrain et laboratoire pour cette URL — ou l’outil URL Inspection. Le rapport Core Web Vitals n’est pas conçu pour déterminer l’état d’une URL particulière.

« Le rapport affiche No data available. » → La propriété vient-elle d’être créée ? Laissez quelques jours à CrUX. → Sinon, le trafic est presque certainement insuffisant : même le groupe d’origine n’atteint pas le seuil de confidentialité. Testez les URL dans PageSpeed Insights ou Lighthouse. Une absence de données n’est pas un certificat de bonne santé.

« Un groupe est Poor : que corriger en premier ? » → Corrigez tout ce qui porte l’état Poor avant Need improvement. → Dans le groupe, les URL sont triées par impressions décroissantes ; celles du haut influencent le plus l’état. → L’état dépend de la pire mesure : trouvez laquelle de LCP, INP ou CLS échoue et corrigez celle-ci.

« L’état GSC et PageSpeed Insights divergent pour la même URL. » → C’est attendu. GSC présente le groupe ; PSI l’URL individuelle, qui peut être atypique. GSC conserve aussi les paramètres d’URL, tandis que PSI les retire pour former l’URL nue. Aucun outil ne se trompe : ils mesurent des périmètres différents.

« J’ai déployé une correction : comment confirmer son effet ? » → Vérifiez immédiatement le résultat de laboratoire dans PageSpeed Insights. → Cliquez sur Start Tracking dans GSC pour valider sur le terrain. → Patientez ensuite : la fenêtre glissante de 28 jours demande environ un mois pour refléter entièrement le changement.

« L’état a changé sans que je touche au site. » → Il s’agit souvent d’URL proches d’un seuil qui basculent après une évolution externe — trafic, latence du CDN ou des images, navigateur — ou d’une simple variation de la taille de l’échantillon. Vérifiez si le mouvement concerne le nombre d’URL admissibles ou la qualité des mesures ; ce sont deux phénomènes distincts.

Liste de contrôle pour lire le rapport Core Web Vitals

Vérifications rapides avant de conclure ou d’envoyer une liste de tâches à un développeur :

• Vous avez consulté les onglets Mobile et Desktop ; ils sont indépendants et peuvent diverger.
• Vous traitez les groupes d’URL, pas les URL isolées, comme unité ; une correction peut résoudre tout le groupe.
• Vous savez qu’un groupe Poor peut contenir des pages rapides, l’état étant calculé au p75 sur l’ensemble.
• Vous savez que le graphique et le tableau ne se réconcilient pas : le graphique compte une fois chaque URL selon son pire problème, le tableau compte tous les problèmes.
• Vous corrigez Poor avant Need improvement et priorisez les URL les plus vues.
• Vous avez identifié la mesure — LCP, INP ou CLS — qui détermine chaque état.
• Pour une URL isolée, vous utilisez PageSpeed Insights ou URL Inspection.
• Vous n’attendez pas une correspondance parfaite entre GSC et PageSpeed Insights.
• Face à No data available, vous vérifiez le trafic et l’admissibilité au lieu de conclure que les pages sont bonnes.
• Après une correction, vous avez cliqué sur Start Tracking et accordé environ un mois aux données de terrain.
• Vous ne poursuivez pas un changement d’état dû seulement à un seuil ou à l’échantillon.

Modèles mentaux

1. C’est un rapport, pas un compteur. Chaque valeur provient des données de terrain CrUX : utilisateurs réels de Chrome, fenêtre glissante de 28 jours, 75e centile. Le rapport expose ces données sans rien recalculer et sans couche de laboratoire. Il décrit toujours le passé récent, jamais l’instant présent.

2. Le groupe d’URL est l’unité élémentaire. Ne raisonnez plus uniquement URL par URL. Google regroupe les pages fondées sur des modèles similaires, attribue un état à tout le groupe et peut signaler des milliers d’URL à cause d’un seul défaut de modèle. Corriger le modèle corrige le groupe. Une URL rapide peut malgré tout appartenir à un groupe Poor.

3. La pire mesure l’emporte. L’état d’un groupe dépend de la moins bonne valeur parmi LCP, INP et CLS. Avant toute optimisation, repérez la mesure en échec : vous ne corrigez pas « le groupe », mais la mesure qui le dégrade.

4. La cascade de confidentialité explique les absences. Groupe d’URL → groupe d’origine → No data available. Un trafic insuffisant pour publier des données confidentielles entraîne des regroupements grossiers ou aucun résultat. L’absence de données signifie CrUX insuffisant, pas site irréprochable.

5. Deux outils, deux fonctions : diagnostiquer vite, confirmer lentement. PageSpeed Insights analyse une URL, combine terrain et laboratoire et fournit un retour immédiat. Le rapport GSC regroupe les URL, n’utilise que le terrain et accuse environ un mois de retard. Diagnostiquez avec le laboratoire PSI, puis attendez la confirmation réelle des données GSC.

Aide-mémoire du rapport Core Web Vitals

Organisation

Rapport GSC et PageSpeed Insights

Repères rapides

• Source : données de terrain CrUX, 28 jours glissants, p75, par appareil.
• Seulement des URL indexées, sous forme d’échantillon, attribuées à l’URL réelle, pas à la canonique.
• No data available = propriété récente ou trafic CrUX insuffisant : groupe d’URL → groupe d’origine → aucune donnée.
• Le graphique compte une fois chaque URL selon son pire problème ; le tableau compte tous les problèmes. Les totaux diffèrent.
• FID a été retiré de GSC le 12 mars 2024, immédiatement ; PSI et CrUX l’ont conservé six mois.
• Page Experience a été retiré le 19 avril 2023 ; Core Web Vitals et HTTPS subsistent.
• Corrigez Poor d’abord, lancez Start Tracking et prévoyez environ 28 jours.
• Règle Google sur le poids : moins de 500KB pour la page et toutes ses ressources.

Erreurs fréquentes avec le rapport Core Web Vitals

Considérer chaque URL d’un groupe Poor comme lente. L’état appartient au groupe au 75e centile ; un membre peut être plus rapide ou plus lent. Diagnostiquez des URL représentatives, puis corrigez le modèle ou composant commun.

Vérifier uniquement Mobile ou Desktop. Les jeux sont séparés et peuvent diverger. Analysez les deux onglets indépendamment au lieu de les fusionner.

Prendre No data available pour une réussite. Ce message signifie généralement que l’URL ou l’origine manque de trafic CrUX admissible. Utilisez le laboratoire et d’autres sources de terrain ; n’affirmez pas que la page est Good.

Attendre que GSC corresponde à PageSpeed Insights pour une URL. GSC présente des groupes et conserve les paramètres ; PSI présente généralement une URL nue. Comprenez l’unité et le traitement des URL avant de conclure à un bug.

Optimiser une mesure déjà Good. La plus faible détermine l’état du groupe. Identifiez si LCP, INP ou CLS est responsable avant de confier le travail au développeur.

Lancer Start Tracking juste après une correction de laboratoire. Vérifiez d’abord que le changement est déployé sur tous les modèles touchés. Lancez ensuite une seule validation de terrain et laissez CrUX recueillir des données réelles.

Réconcilier les totaux du graphique et du tableau. Le graphique compte chaque URL une fois selon son pire problème ; le tableau compte tous les problèmes associés. Des totaux différents sont attendus.

Valider une correction Core Web Vitals

Utilisez trois niveaux de preuve. Aucun ne suffit seul.

1. Preuve de déploiement

• Reproduisez l’interaction lente, l’élément instable ou le plus grand élément affiché tardivement sur une URL représentative.
• Confirmez que le code modifié est en production, pas seulement en prévisualisation, sur chaque modèle représenté dans le groupe.
• Exécutez Lighthouse ou une autre trace avant et après, dans les mêmes conditions. La mesure ciblée doit s’améliorer sans dégrader une autre Core Web Vital.

2. Preuve issue du processus du rapport

• Ouvrez la ligne exacte du problème et consignez l’appareil, l’état, la mesure, le groupe d’URL et les exemples.
• Contrôlez quelques exemples dans PageSpeed Insights, en gardant à l’esprit qu’une URL individuelle peut différer de son groupe GSC.
• Cliquez sur Start Tracking seulement après le déploiement complet. Suivez l’état de validation du problème au lieu de le relancer sans cesse.

3. Preuve du résultat de terrain

• Attendez que la fenêtre glissante CrUX de 28 jours intègre les visites postérieures au déploiement.
• Confirmez que le groupe s’améliore sur l’appareil et la mesure initialement en échec.
• Vérifiez Mobile et Desktop, puis distinguez l’amélioration réelle d’un changement des URL qui disposaient d’assez de données.
• Si GSC reste inchangé, comparez les exemples du groupe aux données PSI de l’URL et de l’origine avant de déclarer l’échec du déploiement.

La condition de réussite n’est pas « Lighthouse est devenu vert une fois ». Il faut que la correction soit présente dans tout le groupe, que les preuves de laboratoire contrôlées s’améliorent et que le problème de terrain GSC disparaisse après l’arrivée d’assez de données réelles.

Mesurer les progrès sans inventer de score

Suivez séparément ces éléments par appareil, mesure, groupe d’URL et date de version :

Utilisez les seuils Good publiés par Google — LCP à 2,5 secondes ou moins, INP à 200 millisecondes ou moins et CLS à 0,1 ou moins, au 75e centile — comme critère de qualité. N’inventez ni délai universel ni objectif d’amélioration en pourcentage. La tendance utile combine moins d’URL admissibles dans les groupes en échec, des validations résolues et des gains stables sur plusieurs fenêtres de 28 jours sans sacrifier une mesure.

Ressources utiles

Mes articles connexes

• Que sont les Core Web Vitals et comment les améliorer ? — mon guide des mesures et du regroupement par modèle dans GSC.
• Google PageSpeed Insights pour les spécialistes SEO et développeurs — complément de laboratoire et processus “diagnose in PSI, monitor in GSC” (traduction) « diagnostiquer dans PSI, surveiller dans GSC », avec le délai de 28 jours.
• Étude Core Web Vitals avec CrUX et 5,2 millions de pages — analyse du faible nombre de pages disposant de données CrUX, environ 12 %, qui explique la plupart des écrans No data available.

Mes interventions et entretiens

• Les Core Web Vitals de Google pour les PME : entretien avec Patrick Stox — explication courte et non technique de l’objectif du rapport : une correction résout le problème de toutes les pages du groupe.

Documentation officielle

• Rapport Core Web Vitals — aide Search Console — référence canonique de cet article.
• INP devient une Core Web Vital le 12 mars — web.dev — détail du retrait immédiat de FID dans GSC.

Sources du secteur

• Google explique le regroupement des URL pour les scores Core Web Vitals — transcription Office Hours de John Mueller sur les milliers d’URL d’un groupe.
• Utiliser le rapport Core Web Vitals de Google Search Console — parcours pratique et explication des pages rapides incluses dans des groupes lents.
• Core Web Vitals dans Google Search Console : corriger et optimiser — processus structuré : trier, prioriser, tester, résoudre et valider.
• Disparition du rapport Page Experience de Google Search Console — retrait de la synthèse en avril 2023.
• Mise à jour du rapport Core Web Vitals dans Google Search Console — ajout du repli sur le groupe d’origine en mars 2023.
• Mise à jour Core Web Vitals de Google Search Console — baisse des URL admissibles en juillet 2025 et commentaires sur la variation d’échantillon.

Statistiques utiles à citer

• Environ 12 % seulement des 43,66 millions de pages Site Audit uniques de l’échantillon de janvier 2022 possédaient une mesure CrUX. Dans mon étude, “We found only 5.21M (~11.9%) had at least one Core Web Vitals metric, and 93% of those (or ~4.85M total) had all three metrics.” (traduction) « seulement 5,21 millions de pages, environ 11,9 %, possédaient au moins une mesure Core Web Vitals, et 93 % d’entre elles, soit environ 4,85 millions, disposaient des trois ». Cette échelle explique pourquoi tant de sites voient No data available.
• FID a été retiré de GSC le 12 mars 2024, immédiatement et sans délai, tandis que PSI et CrUX proposaient six mois de transition. Source
• Règle de poids : moins de 500KB pour la page et toutes ses ressources, selon la section Fix issues du rapport Google. Source
• Page Experience a été retiré le 19 avril 2023 ; les rapports Core Web Vitals et HTTPS subsistent. Article

Testez vos connaissances sur le rapport Core Web Vitals

Cinq questions rapides sur le fonctionnement du rapport Core Web Vitals de Search Console. Choisissez une réponse, puis vérifiez-la.

Journal des modifications