CrUX Ads Metrics : la réalité des pubs enfin visible !
Cela fait un moment que Google n’avait pas pondu de nouveaux indicateurs à se mettre sous la dent. Eh bien le 15 septembre dernier, Google a rendu publiques, au travers de son célèbre Chrome UX Report autrement nommé CrUX, non pas une mais quatre métriques : les CrUX Ads Metrics. Une régalade pour les amateurs de statistiques techniques comme moi.
Si la publication s’est faite dernièrement, on constate dans ce même CrUX que les données ont commencé à être récoltées depuis juillet. Ce qui va nous permettre de faire un premier état des lieux de la presse française, comme on aime à le faire tous les mois.
Bref, revenons en détail sur le CrUX, ces nouvelles métriques, l’impact des pubs sur le Web parce que c’est surtout ça le sujet, et enfin ce qu’on vous recommande.
Le CrUX, un rappel avant de commencer
Le CrUX (Chrome User Experience Report), c’est le jeu de données de terrain que Google collecte auprès des utilisateurs réels de Chrome. C’est cette base qui alimente les Core Web Vitals dans Search Console, PageSpeed Insights, ou l’onglet Performance de Chrome DevTools.
La collecte se fait sur une fenêtre glissante de 28 jours. Et pour toutes les métriques du CrUX, ads comprises, on est au 75e percentile : donc un quart des visiteurs vivent une expérience pire que le chiffre affiché.
Une vue partielle des utilisateurs
Deux points qu’on oublie souvent quand on débute avec le CrUX :
- Il faut un volume de trafic suffisant pour qu’une URL ou une origine y apparaisse. Google ne communique pas de chiffre précis (sinon ça serait trop simple), la doc officielle indique juste que le seuil « a été choisi pour garantir suffisamment d’échantillons pour être confiant dans les distributions statistiques ». Concrètement, un petit site n’aura simplement pas de données CrUX, ni pour les Core Web Vitals, ni pour les nouvelles métriques ads…
>NB : si vous n’avez pas de données CrUX pour votre site, vous pouvez reprendre vos activités quotidiennes : ce qui va suivre ne va guère vous passionner. - Google ne collecte pas les données de tous les utilisateurs Chrome. Il faut que l’utilisateur soit connecté à un compte Google avec la synchronisation de l’historique de navigation activée et une fois ce cap franchi… ne pas toucher aux options par défaut comme le partage des statistiques d’usage ou la phrase de synchronisation personnalisée. Et ça ne concerne que Windows, macOS, Android, ChromeOS et Linux. iOS et les WebViews sont exclus d’office. Et bien sûr, Google ne communique pas la proportion de son parc qui remplit ces conditions (bah oui, sinon ça serait trop simple).
URL vs Origin
Autre distinction à garder en tête, celle entre les données au niveau URL et au niveau origine. Le niveau page agrège uniquement les visites de cette URL précise, et nécessite qu’elle soit accessible publiquement et suffisamment populaire à elle seule. Le niveau origine agrège toutes les pages du domaine, dès lors que l’origine elle-même est accessible, même si certaines pages individuelles ne le sont pas. Pour un site de presse avec des milliers d’articles, c’est souvent uniquement le niveau origine qui remonte des données exploitables, article par article on retombe vite sous le seuil une fois le pic de trafic lié à l’actualité retombé.
Mise à part ces quelques subtilités, le CrUX reste, de par son volume, une base de données plus qu’intéressante, car elle remonte la réalité du terrain et permet aussi de se comparer avec des sites concurrents ou des sites avec la même stack technique.
CrUX Ads Metrics : quatre nouveaux indicateurs
Le CrUX introduit :
- Ad Count : le nombre moyen de blocs publicitaires distincts visibles dans le viewport pendant que l’utilisateur scrolle.
- Ad Density : la part de l’espace visible occupée par la pub tout au long de la session de scroll.
- Ad Weight CPU : la charge de calcul cumulée générée par le chargement et l’exécution des scripts et assets publicitaires (en millisecondes).
- Ad Weight Network : le volume de trafic réseau cumulé lié à ces mêmes scripts et assets (en octets).
Ads.txt, le sésame pour apparaître dans les données CrUX Ads Metrics
C’est le point le moins documenté ailleurs, alors autant le sourcer précisément. La doc officielle de Chrome for Developers le dit noir sur blanc : « pour soutenir la qualité des métriques rapportées dans le CrUX, nous n’incluons que les sites qui listent au moins un vendeur autorisé dans leur ads.txt. Les origines sans ads.txt, ou n’en contenant qu’un enregistrement placeholder, sont exclues du reporting des CrUX Ads Metrics ». Le filtrage se fait au moment de l’agrégation des données CrUX, pas dans le navigateur. DevTools continue donc d’afficher les métriques ads localement même sur un site sans ads.txt, mais ces mesures ne remonteront jamais dans les rapports publics.
Pour ceux qui n’ont pas ce fichier tous les jours sous les yeux, ads.txt (Authorized Digital Sellers) est un standard publié en juin 2017 par le groupe de travail OpenRTB de l’IAB Tech Lab. Un fichier texte à la racine du domaine, qui liste publiquement les revendeurs autorisés à vendre l’inventaire publicitaire du site. Son objectif d’origine : lutter contre le « domain spoofing », ces intermédiaires qui prétendent vendre de l’espace pub sur un site sans y être autorisés, en créant un registre public vérifiable par les acheteurs programmatiques.
Autrement dit, sans ads.txt correctement rempli, un site peut cumuler perte de revenu publicitaire (les acheteurs écartent l’inventaire non déclaré) et invisibilité totale dans les nouvelles Ads Metrics. Un bon argument de plus pour vérifier ce fichier, si ce n’était pas déjà fait.
Une donnée qui vient compléter le diagnostic webperf de MilleCheck
Le CrUX donne une tendance agrégée, côté navigateur, sur 28 jours glissants. Ça reste un chiffre macro. L’étape suivante, chez nous, c’est de le croiser avec l’audit Third Parties de MilleCheck, qui descend au niveau du domaine tiers individuel : quel script, quel tag de mesure d’audience, quel pixel de retargeting pèse le plus lourd sur une page donnée, au moment précis de l’audit. Le CrUX valide la tendance terrain, MilleCheck permet de désigner le coupable et d’agir dessus.
La recommandation d’artwaï : viser 30% d’Ad density
Google n’a volontairement fixé aucun seuil « Good / Needs improvement / Poor » pour ces Ads Metrics, contrairement aux Core Web Vitals. En effet, ces métriques sont encore considérées comme expérimentales. Mais bon, on se doute bien qu’ils ne font pas ça pour rien et que tôt ou tard, on aura droit à nos pastilles vertes, oranges et rouges habituelles.
Toutefois, on peut quand même anticiper quelques usages. Google siégeant au conseil d’administration de la Coalition for Better Ads, il y a fort à parier qu’il en promeuve ce standard. Or l’une des recommandations directement mesurable avec les CrUX Ads Metrics, est celle de la densité sous le seuil des 30% aussi bien sur mobile que sur desktop. Pour être précis, il faut comprendre qu’une page est jugée non conforme quand ses publicités dépassent 30% de la hauteur verticale de la zone de contenu principal. Les calculs semblent légèrement différents entre celui du CrUX et celui du Better Ads mais l’idée est là.
Donc, mon conseil est de surveiller cet indicateur, l’Ad Density, et veiller à rester sous le seuil des 30% !
On pourrait aussi se fixer des limites sur les 2 indicateurs Ad Weight, CPU et Network. Mais je n’ai trouvé aucune mention dans le Better Ads pour ces notions de performance et qui sont de toute façon mesurées de manière globale au sein des Core Web Vitals.
CrUX Ads Metrics du top 50 des sites de presse français
Maintenant qu’on a nos nouveaux jouets, on va pouvoir se faire une idée concrète. Pour cela, on a passé au crible les CrUX Ads Metrics des 50 sites de presse français référencés dans notre classement de la webperf de la presse. Le tableau ci-dessous liste les quatre CrUX Ads Metrics (mobile) au niveau de l’origine pour chaque site, mis en parallèle avec leurs Core Web Vitals. Et bien sûr, on a appliqué un code couleur sur l’Ad Density conformément à ma reco.
| Ads Metrics | Core Web Vitals | ||||||
|---|---|---|---|---|---|---|---|
| Site | Count | Density | CPU | Network | LCP | INP | CLS |
| actu.fr | 0,77 | 15 % | 4,16 s | 3,99 Mo | 1,42 s | 0,21 s | 0,05 |
| aufeminin.com | 1,77 | 24 % | 5,49 s | 3,64 Mo | 1,25 s | 0,23 s | 0,02 |
| autoplus.fr | 2,03 | 35 % | 8,79 s | 7,76 Mo | 1,4 s | 0,25 s | 0,06 |
| bfmtv.com | 0,67 | 16 % | 2,44 s | 2,03 Mo | 1,53 s | 0,11 s | 0 |
| boursorama.com | 0,77 | 11 % | 1,17 s | 0,2 Mo | 1,67 s | 0,13 s | 0,01 |
| capital.fr | 1,16 | 16 % | 9,94 s | 4,83 Mo | 1,3 s | 0,31 s | 0,02 |
| charentelibre.fr | 2,33 | 16 % | 6,15 s | 3,38 Mo | 1,48 s | 0,19 s | 0,12 |
| closermag.fr | 2,68 | 41 % | 9,57 s | 6,62 Mo | 1,64 s | 0,31 s | 0,08 |
| courrierinternational.com | 0,58 | 8 % | 2,8 s | 1,8 Mo | 1,12 s | 0,09 s | 0 |
| dna.fr | 1,54 | 18 % | 2,61 s | 2,63 Mo | 2,04 s | 0,23 s | 0,21 |
| estrepublicain.fr | 1,77 | 17 % | 2,45 s | 2,54 Mo | 1,95 s | 0,26 s | 0,15 |
| femmeactuelle.fr | 1,16 | 15 % | 10,62 s | 4,53 Mo | 1,7 s | 0,35 s | 0,03 |
| footmercato.net | 1,16 | 16 % | 2,55 s | 1,49 Mo | 1,68 s | 0,11 s | 0,02 |
| ici.fr | 0,25 | 5 % | 1,46 s | 1 Mo | 1,53 s | 0,16 s | 0 |
| franceinfo.fr | 0,51 | 8 % | 3,06 s | 0,03 Mo | 1,33 s | 0,18 s | 0,01 |
| frandroid.com | 1,01 | 15 % | 3,42 s | 1,87 Mo | 1,77 s | 0,15 s | 0,03 |
| gala.fr | 1,01 | 13 % | 7,12 s | 6,36 Mo | 1,31 s | 0,26 s | 0,06 |
| geo.fr | 1,16 | 15 % | 10,61 s | 4,34 Mo | 1,63 s | 0,27 s | 0,01 |
| grazia.fr | 1,77 | 31 % | 6,95 s | 6,02 Mo | 1,32 s | 0,36 s | 0,07 |
| huffingtonpost.fr | 0,67 | 12 % | 5,16 s | 4,07 Mo | 1,37 s | 0,11 s | 0,03 |
| larepubliquedespyrenees.fr | 2,03 | 17 % | 7,24 s | 4,15 Mo | 1,83 s | 0,24 s | 0,14 |
| latribune.fr | 0,88 | 19 % | 6 s | 4,87 Mo | 2,5 s | 0,18 s | 0,27 |
| ledauphine.com | 1,77 | 17 % | 2,44 s | 2,77 Mo | 1,83 s | 0,25 s | 0,16 |
| lefigaro.fr | 0,67 | 12 % | 2,63 s | 2,31 Mo | 1,24 s | 0,26 s | 0,08 |
| lejsl.com | 1,54 | 17 % | 2,57 s | 2,06 Mo | 1,93 s | 0,28 s | 0,12 |
| lemonde.fr | 0,67 | 11 % | 2,85 s | 2,2 Mo | 1,29 s | 0,13 s | 0,08 |
| leparisien.fr | 1,54 | 11 % | 3,48 s | 2,92 Mo | 1,66 s | 0,16 s | 0,04 |
| lequipe.fr | 0,58 | 12 % | 2,48 s | 1,24 Mo | 1,34 s | 0,25 s | 0,07 |
| leprogres.fr | 1,77 | 17 % | 2,53 s | 2,74 Mo | 1,94 s | 0,26 s | 0,15 |
| lexpress.fr | 0,67 | 8 % | 2,85 s | 1,95 Mo | 1,59 s | 0,12 s | 0,12 |
| libramemoria.com | 0,51 | 16 % | 1,36 s | 0,5 Mo | 1,49 s | 0,13 s | 0 |
| lindependant.fr | 1,54 | 23 % | 4,72 s | 5,21 Mo | 1,36 s | 0,2 s | 0,05 |
| mariefrance.fr | 2,03 | 33 % | 4,7 s | 3,47 Mo | 1,45 s | 0,28 s | 0,03 |
| marmiton.org | 1,77 | 34 % | 14,69 s | 11,21 Mo | 1,84 s | 0,29 s | 0,05 |
| midilibre.fr | 1,54 | 23 % | 5,27 s | 5,23 Mo | 1,41 s | 0,21 s | 0,06 |
| nouvelobs.com | 0,58 | 11 % | 2,39 s | 2,3 Mo | 1,55 s | 0,13 s | 0,02 |
| ohmymag.com | 1,54 | 16 % | 10,19 s | 4,56 Mo | 1,11 s | 0,35 s | 0,02 |
| ouest-france.fr | 0,77 | 21 % | 5,71 s | 4,03 Mo | 1,46 s | 0,21 s | 0,06 |
| parismatch.com | 0,58 | 10 % | 3,54 s | 2,43 Mo | 1,44 s | 0,17 s | 0,03 |
| programme-television.org | 0,77 | 14 % | 5,26 s | 2,91 Mo | 1,61 s | 0,22 s | 0,25 |
| programme-tv.net | 1,01 | 15 % | 5,11 s | 2,47 Mo | 1,68 s | 0,29 s | 0,02 |
| programme.tv | 1,16 | 15 % | 7,68 s | 3,35 Mo | 1,6 s | 0,31 s | 0,01 |
| radiofrance.fr | 0,44 | 10 % | 1,55 s | 0,88 Mo | 2,33 s | 0,33 s | 0,03 |
| republicain-lorrain.fr | 1,54 | 16 % | 2,26 s | 2,17 Mo | 1,98 s | 0,25 s | 0,11 |
| science-et-vie.com | 2,03 | 32 % | 4,93 s | 4,94 Mo | 1,88 s | 0,23 s | 0,01 |
| sudouest.fr | 2,33 | 16 % | 4,91 s | 3,4 Mo | 1,6 s | 0,25 s | 0,07 |
| telerama.fr | 0,67 | 8 % | 1,44 s | 1,96 Mo | 1,74 s | 0,14 s | 0 |
| topsante.com | 2,33 | 38 % | 7,09 s | 6 Mo | 1,51 s | 0,3 s | 0,01 |
| voici.fr | 1,16 | 14 % | 11,84 s | 5,49 Mo | 1,54 s | 0,38 s | 0,02 |
Une tendance se dégage assez nettement : l’Ad Weight CPU semble tirer l’INP vers le haut. Logique, les sites qui font tourner leurs scripts pubs le plus longtemps sur le processeur (voici.fr, femmeactuelle.fr, ohmymag.com) se retrouvent aussi avec les INP les plus dégradés, autour de 0,35 s et plus. Tandis que les plus légers en CPU (boursorama.com, telerama.fr) gardent un INP au top. La tendance n’est pas parfaite pour autant, marmiton.org cumule le CPU le plus lourd du classement (14,69 s) sans pour autant afficher un INP catastrophique, et radiofrance.fr fait l’inverse, un CPU parmi les plus légers, mais un INP aussi dégradé que le trio de tête. De quoi rappeler que l’Ad Weight CPU pèse sur la réactivité de la page, mais qu’il n’est pas le seul facteur en jeu.
En revanche, pas de lien évident entre Ad Density ou Ad Weight Network d’un côté, et LCP ou CLS de l’autre : certains sites très denses en pub (closermag.fr, topsante.com) affichent un CLS quasi parfait, quand des titres de presse régionale, pourtant modérés en densité, cumulent les CLS les plus élevés du classement.
Bref, si la pub pèse clairement sur la réactivité de la page, elle n’explique pas tout côté stabilité visuelle ou vitesse d’affichage. Notons toutefois, que l’expérience utilisateur ne se limite pas qu’au temps d’affichage et que la densité de pubs peut devenir un sujet si elle fait fuir vos utilisateurs.
Que retenir de tout ça ?
Ces CrUX Ads Metrics ne sont pas encore une norme gravée dans le marbre, mais ce n’est pas une raison pour les ignorer en attendant que Google leur colle enfin ses pastilles officielles. La donnée est là, gratuite, accessible, et elle raconte une réalité qu’on ne pouvait tout simplement pas mesurer avant. Je pense que Google doit encore travailler et va certainement améliorer la fiabilité de ces mesures dans les prochains mois.
Alors en attendant le seuil officiel qui viendra ou pas, je continue de préconiser le nôtre : 30% d’Ad Density, mobile comme desktop, à surveiller avec la même rigueur que le LCP, l’INP ou le CLS. Le jour où Google publiera ses propres seuils pour les Ads Metrics, vous pourrez me maudire ou applaudir, mais au moins je me serai mouillé. Dans tous les cas, on mettra à jour cet article.
