Google CrUX rend la charge publicitaire des sites plus visible

Google ajoute quatre métriques publicitaires expérimentales au Chrome UX Report (CrUX). L’enjeu est simple : rendre plus lisible la pression publicitaire réellement subie par les internautes, au-delà du seul nombre d’emplacements vendus sur une page.

Ces indicateurs portent sur le nombre de publicités visibles, la part de l’écran qu’elles occupent, ainsi que les ressources réseau et processeur qui leur sont attribuées. Ils constituent un repère utile pour les éditeurs, les équipes ad tech et les acheteurs média ; ils ne sont pas, à ce stade, une note de « qualité publicitaire » ni un facteur de classement organique annoncé par Google. 13

Les quatre métriques publicitaires de CrUX

Google décrit quatre dimensions de l’expérience publicitaire d’un site :

• Ad Count : le nombre moyen de publicités présentes dans la zone visible de l’écran (« viewport »).
• Ad Density : la fraction moyenne de la surface visible occupée par les publicités.
• Ad Weight (Network Usage) : les ressources consommées par les publicités, mesurées en octets.
• Ad Weight (CPU Usage) : les ressources processeur consommées par les publicités, mesurées en millisecondes. 13

Ces mesures évitent de résumer la charge publicitaire à un simple compteur de formats. Une page peut afficher peu de publicités tout en ayant une forte densité si un grand format fixe occupe une part importante de l’écran. À l’inverse, une page visuellement peu encombrée peut embarquer une chaîne programmatique lourde, avec un poids réseau ou CPU élevé.

Ce que mesure CrUX — et ce qu’il ne mesure pas

CrUX est le jeu de données public de Google fondé sur l’expérience agrégée d’utilisateurs réels de Chrome. Il reflète donc des appareils, débits, variantes de pages et diffusions publicitaires variés, plutôt qu’un unique test de laboratoire. 6

Les données ne décrivent pas une impression publicitaire précise, une création, une campagne ou un emplacement donné. Elles donnent une vision agrégée de la charge publicitaire rencontrée par les visiteurs d’une origine ou, lorsque les données sont suffisantes, d’une URL. 13

Le statut expérimental est important : Google précise que ces métriques peuvent évoluer. Les équipes ne doivent donc pas considérer les valeurs, définitions ou règles de disponibilité actuelles comme définitives. 12

Où consulter les données

API CrUX : un état des lieux récent

L’API CrUX fournit rapidement des données agrégées d’utilisateurs réels au niveau de l’origine et de l’URL. Une requête par origine agrège les expériences des pages éligibles de cette origine ; une requête par URL est plus ciblée, si le volume de données le permet. 5

C’est l’outil à privilégier pour établir un point de référence actuel ou intégrer les résultats CrUX dans un suivi interne.

API CrUX History : suivre les tendances hebdomadaires

L’API CrUX History propose une série chronologique hebdomadaire d’environ six mois, soit 40 points de données, aux niveaux origine et page. 111

Elle permet notamment de comparer la situation avant et après une modification : réduction du nombre de formats affichés simultanément, retrait d’un partenaire de demande, ajustement du lazy loading ou limitation des créations les plus lourdes.

CrUX Vis : des graphiques sans intégration technique

CrUX Vis visualise les données hebdomadaires de l’API History et comprend une page Ad Metrics. Pour les propriétés présentes dans le jeu de données, c’est le moyen le plus direct d’observer une tendance sans développer d’intégration API. 3

Chrome DevTools : enquêter localement, sans remplacer les données terrain

Chrome DevTools aide à inspecter et reproduire des comportements locaux de performance. Les notes de version de Google indiquent aussi l’intégration de données de terrain CrUX dans le panneau Performance de DevTools, afin de replacer le débogage local dans le contexte de l’expérience réelle. 4

Mais une trace locale ne remplace pas CrUX : elle ne reproduit ni la diversité des appareils et connexions, ni les états de consentement, les enchères ou les variations de créations publicitaires rencontrées en conditions réelles. Il est donc préférable d’utiliser les données terrain pour repérer un problème durable, puis les outils locaux pour en rechercher les causes plausibles.

Quels sites peuvent apparaître dans les rapports ?

CrUX ne couvre pas tous les sites ni toutes les pages. Pour figurer dans le jeu de données, une expérience doit répondre aux critères d’éligibilité de Google : utilisateurs éligibles, origine ou page publiquement accessible et popularité suffisante. Google ne publie pas de seuil universel de trafic garantissant l’inclusion. 210

Pour les nouvelles métriques publicitaires, le reporting est en outre limité aux sites éligibles qui déclarent un vendeur autorisé. La couverture sectorielle du lancement associe cette condition à une déclaration ads.txt. 17

Deux conséquences pratiques :

1. Une origine peut disposer de données CrUX alors que certaines de ses URL n’ont pas assez d’observations éligibles pour un reporting au niveau de la page.
2. L’absence de données publicitaires ne prouve ni l’absence de publicité ni l’absence de charge publicitaire. Elle peut simplement refléter un volume insuffisant ou le non-respect des critères de reporting.

Lire les quatre chiffres ensemble

Question à se poser	Indicateur principal	Ce qu’il renseigne
Combien de publicités se disputent l’attention du lecteur ?	Ad Count	L’encombrement publicitaire visible simultanément
Quelle part de l’écran est prise par les publicités ?	Ad Density	L’intrusion visuelle dans la zone visible
Quel volume de données les publicités consomment-elles ?	Ad Weight (Network)	La charge de téléchargement imputable aux publicités
Quel travail de traitement imposent-elles au navigateur ?	Ad Weight (CPU)	La charge de calcul imputable aux publicités

Pour un éditeur, cette lecture croisée aide à distinguer un problème de mise en page d’un problème d’efficacité de la stack publicitaire. Réduire les emplacements visibles peut faire baisser le nombre et la densité ; simplifier les scripts tiers ou encadrer les créations lourdes peut davantage agir sur le réseau et le CPU.

Quels usages pour les éditeurs et les acheteurs média ?

Google présente ces mesures comme un moyen pour les équipes côté achat et côté vente d’évaluer l’expérience de charge publicitaire des audiences. 15

À court terme, leur usage le plus solide est opérationnel :

• Les éditeurs peuvent suivre ces tendances avec les revenus, les Core Web Vitals, l’engagement et leurs autres indicateurs internes.
• Les équipes ad operations peuvent tester des règles de placement, des chemins de demande, le chargement différé et des politiques limitant les créations très consommatrices.
• Les acheteurs média peuvent les intégrer comme un signal parmi d’autres dans l’évaluation de la qualité ou des chemins d’approvisionnement, notamment lorsque la fluidité de l’expérience utilisateur est un objectif de campagne.

Ces métriques ne suffisent toutefois pas à valoriser un inventaire. Elles ne mesurent ni la visibilité effective, ni l’attention, ni l’adéquation à l’audience, ni la fraude, ni le taux de conversion, ni les résultats de marque. Il n’existe pas non plus, à ce jour, de preuve publique solide d’un standard sectoriel de CPM, d’un modificateur d’enchère généralisé ou d’une obligation acheteur fondée sur ces champs.

SEO et classement dans Google Search : ce qui est établi

Une expérience publicitaire lourde peut affecter indirectement le SEO si elle ralentit le chargement ou dégrade la réactivité. CrUX permet déjà d’observer les conditions de performance vécues par les utilisateurs, et ces nouvelles mesures apportent du contexte sur une source possible de surcharge. 613

La conclusion doit néanmoins rester précise : Google n’a pas déclaré qu’Ad Count, Ad Density, Ad Weight (Network Usage) ou Ad Weight (CPU Usage) sont des signaux directs de classement dans Google Search. Il ne faut donc pas les optimiser en fonction d’un seuil SEO supposé.

Une méthode pragmatique pour agir

Ces quatre métriques doivent être traitées comme des indicateurs terrain de diagnostic :

1. Établir une référence au niveau de l’origine dans l’API CrUX ou CrUX Vis.
2. Examiner les données par URL lorsqu’elles existent, afin de déterminer si un problème se concentre sur certains modèles de pages.
3. Modifier un seul paramètre à la fois : moins de publicités simultanées dans le viewport, limitation des grands formats fixes ou suppression de chemins tiers inutiles, par exemple.
4. Suivre la tendance hebdomadaire dans CrUX History, en parallèle des revenus, des Web Vitals et de l’engagement propriétaire.
5. Valider localement dans DevTools, en gardant à l’esprit qu’un test local sert au débogage et ne remplace pas les données d’utilisateurs réels.

La valeur principale de ces métriques est la transparence : elles séparent l’encombrement visuel du coût technique des publicités, deux réalités jusqu’ici souvent déduites du seul nombre d’emplacements ou d’audits synthétiques. Parce qu’elles restent expérimentales et agrégées, elles doivent guider des tests fondés sur des données — pas devenir, seules, une note de qualité, une règle d’enchère ou une consigne SEO. 1213