Page Experience : Google ajoute les métriques publicitaires de CrUX à sa documentation

L’essentiel

• Depuis sa mise à jour du 22 septembre 2026, la page « Page experience » de Search Central renvoie vers les métriques publicitaires de CrUX.
• Quatre métriques expérimentales : Ad Count, Ad Density, Ad Weight (réseau) et Ad Weight (CPU), lancées par Chrome le 15 septembre.
• Google ne les présente pas comme un signal de classement, et John Mueller rappelle que tout n’est pas un facteur direct.
• Les données sont lisibles dans CrUX Vis, l’API CrUX et l’API History ; BigQuery ne les contient pas encore.

Documentation Search : une ligne de plus dans les ressources

Google a modifié le 22 septembre 2026 sa page consacrée à l’expérience sur la page, dans la documentation Search Central. La liste des ressources compte désormais une entrée « CrUX ad metrics », du nom des métriques publicitaires du Chrome User Experience Report (CrUX). Google y voit des indicateurs expérimentaux, calculés par Chrome sur la navigation réelle des internautes, pour suivre combien de publicités un site affiche, quelle place elles prennent à l’écran et ce qu’elles pèsent. Barry Schwartz a repéré l’ajout sur Search Engine Roundtable.

Pour rappel, la même page pose déjà une question d’auto-évaluation sur la publicité : le contenu évite-t-il un excès d’annonces qui détournent l’attention du contenu principal ou en gênent la lecture ? Les nouvelles métriques permettent de mettre des chiffres en face de cette question.

Signal de classement : Google ne franchit pas le pas

Le texte ne relie pas ces métriques au classement. La page garde sa position : les Core Web Vitals sont utilisées par les systèmes de classement, il n’existe pas de signal unique d’expérience sur la page, et au-delà des Core Web Vitals, les autres aspects de cette expérience n’aident pas directement un site à mieux se positionner.

Interrogé sur Bluesky, John Mueller explique que ces métriques ont été ajoutées « parce qu’elles sont disponibles pour aider à évaluer l’état de votre site » (traduction). Puis : « Tout n’est pas un facteur de classement direct ! » (traduction). Il ajoute en substance que des mesures communes facilitent le travail sur l’expérience d’un site, que ce travail porte l’étiquette SEO ou non. Google ne dit donc pas qu’il exploite ces données dans la recherche. Rien de public ne permet de l’affirmer.

Quatre métriques mesurées chez les vrais visiteurs

Chrome a présenté ces métriques le 15 septembre 2026 dans un billet d’Alex Cone sur le blog Chrome for Developers. Elles s’inspirent des Core Web Vitals sans en faire partie, suivent les mêmes critères d’éligibilité que les autres Web Vitals de CrUX et n’ont, à ce stade, aucun seuil recommandé :

• Ad Count : nombre moyen d’éléments publicitaires visibles dans la fenêtre pendant la visite d’une page ;
• Ad Density : part moyenne de la surface de la fenêtre occupée par des publicités ;
• Ad Weight (réseau) : octets compressés transférés pour charger les ressources publicitaires, exprimés en kilo-octets ;
• Ad Weight (CPU) : temps d’exécution JavaScript consommé par les cadres publicitaires et leurs sous-ressources, en millisecondes.

D’après la méthodologie publiée par Chrome, la fenêtre est échantillonnée une fois par seconde, et une publicité compte comme visible dès qu’un seul de ses pixels s’y trouve. Les valeurs publiées correspondent au 75^e centile. La page sur la détection décrit deux mécanismes : une version condensée de la liste de filtres EasyList, et le marquage des ressources ou cadres créés alors qu’un script publicitaire figure dans la pile d’appels JavaScript. Le périmètre est restreint par une condition : seuls les sites dont le fichier ads.txt déclare au moins un vendeur autorisé entrent dans les agrégats. Sans ads.txt, ou avec un simple enregistrement de remplissage, une origine est exclue. Dans son billet, Chrome prévient aussi que la couverture des données doit progresser au cours du mois suivant.

Chrome reconnaît deux biais. Sur une page à défilement infini, l’internaute qui reste inactif en bas de page continue d’ajouter des relevés identiques à la moyenne. Sur une application monopage, les navigations internes ne remettent pas la mesure à zéro. Côté CPU, les scripts publicitaires exécutés dans le cadre principal de la page ne sont pas comptés.

Où consulter les données : CrUX Vis, API CrUX, BigQuery

La page outils de Chrome liste les accès disponibles. CrUX Vis affiche un tableau de bord sans code, par origine ou par URL et par type d’appareil, sur 40 semaines de périodes glissantes de 28 jours. L’API CrUX (point d’accès queryRecord, clé d’API requise) renvoie la dernière fenêtre de 28 jours pour une origine ou une URL. Les champs s’appellent experimental_ad_count, experimental_ad_density, experimental_ad_cpu et experimental_ad_kilobytes, avec une valeur au 75^e centile. L’API History (queryHistoryRecord) fournit une série hebdomadaire, en général 40 points, mise à jour chaque lundi.

BigQuery n’est pas encore servi. Chrome indique travailler à l’ajout des métriques publicitaires au jeu de données, sans donner de date. Le préfixe « experimental_ » signale aussi que les noms de champs peuvent bouger. Enfin, le panneau Ads des DevTools affiche une mesure locale, y compris sur des sites sans ads.txt valide : elle peut donc différer des agrégats CrUX.

Ce que j’en retiens

Je ne réorganiserais pas une mise en page publicitaire pour le seul SEO sur la foi de cet ajout, puisque Google le range parmi les ressources de diagnostic. Pour un site qui vit de la publicité, l’intérêt est ailleurs. Il existe désormais une mesure terrain de la charge publicitaire, publiée par Chrome, et comme l’API CrUX accepte n’importe quelle origine éligible, vous pouvez comparer votre densité au 75^e centile à celle de vos concurrents directs. Je commencerais par l’origine, puis par les URL des principaux gabarits (article, page catégorie), en séparant mobile et ordinateur. Avant tout, vérifiez que le fichier ads.txt déclare bien un vendeur autorisé : sinon, rien ne remontera.

Le poids CPU est la métrique que je surveillerais en premier. C’est une interprétation de ma part : un temps d’exécution publicitaire élevé est un suspect naturel quand l’INP, l’une des Core Web Vitals, se dégrade sur les pages les plus monétisées. La métrique ne couvre toutefois que les cadres publicitaires, pas les scripts chargés dans la page elle-même. Croiser les deux séries dans l’API History reste un test rapide.