La “taxe UX” des ads : prouver que ta page rame à cause des tiers (et pas « ton code »)

Sur un site monétisé, la perf devient vite un jeu débile. Le dev se fait taper dessus parce que “le LCP est mauvais”, pendant que trois tags pub, un CMP, deux trackers et une lib de header bidding se battent pour le CPU. Et quand tu demandes « qui coûte quoi ? », ça part en opinions, en politique, et en “oui mais c’est nécessaire”.

Ce que je te propose ici, c’est une approche qui produit des preuves : tu compares une session “normale” à une session “comme si les ads/tiers n’existaient pas” (adblock), dans des conditions identiques, sur plusieurs runs. Ensuite tu descends un cran plus bas que “le score Lighthouse” pour regarder ce qui compte vraiment : CPU, long tasks, jank, requêtes, JS exécuté. Et à la fin, tu traduis ça en décisions exploitables : budget par provider, kill switch, chargements conditionnels.

La “taxe UX” des ads : ce que tu mesures vraiment (au-delà du débat)

La “taxe UX”, ce n’est pas une morale anti-pub. C’est le delta entre deux réalités : ta page “telle qu’elle sert de l’argent” et ta page “telle qu’elle pourrait être si elle ne traînait pas de passagers”. Sur le terrain, ce delta se voit rarement sur un seul chiffre. Il se voit sur un profil.

Typiquement, quand la stack tiers est le vrai problème, tu peux avoir un backend correct (TTFB stable), un HTML propre, des images pas trop lourdes… et malgré ça : un main thread saturé, des long tasks qui s’empilent, des interactions qui collent, un INP qui part au plafond. Les pubs ne cassent pas toujours ton LCP “par magie”. Elles cassent surtout ta capacité à rendre et interagir proprement une fois que la page est déjà “visible”.

Et c’est pour ça que comparer “avec adblock” vs “sans” est un signal fort : tu ne cherches pas à simuler un navigateur parfait, tu cherches une ligne de base. Si l’écart est énorme, tu as un levier concret. Si l’écart est faible, au moins tu arrêtes de fantasmer que “les ads expliquent tout”.

Le protocole que tu peux refaire demain : adblock vs normal, mêmes conditions, 10 runs

La condition pour que tes chiffres soient défendables, c’est la répétabilité. Un seul run Lighthouse, c’est du divertissement. Tu veux des séries dans un cadre stable, et une façon simple de comparer.

Mon protocole de base ressemble à ça : tu choisis 1 à 3 pages représentatives (souvent home, article, page catégorie ou listing), tu fixes une config (mobile throttling identique, viewport identique), tu fais 10 runs en “normal”, 10 runs avec un adblock activé, et tu prends la médiane plutôt que la moyenne. La médiane absorbe mieux les runs “bizarres” (pub auction plus lente, variation réseau, serveur tiers en PLS).

Deux détails comptent plus qu’on ne croit. D’abord, l’état du consentement : “CMP acceptée” vs “CMP refusée” change complètement la stack appelée. Mesure les deux si c’est ton business réel. Ensuite, la cache: un premier hit “cold” et des hits “warm” n’ont rien à voir. Si tu veux du comparable, tu testes en cold à chaque run (plus long) ou tu standardises (warm) et tu assumes ce que tu mesures.

Tu peux faire ça avec Lighthouse CI (pratique pour automatiser) ou WebPageTest (pratique pour lire la waterfall et la vidéo). Personnellement, quand il faut convaincre, WebPageTest est souvent plus “évident” pour un non-dev. La waterfall, ça ne ment pas.

Option Lighthouse CI : deux collectes, même page, flags différents

Lighthouse CI est utile si tu veux intégrer la comparaison dans une CI, ou au moins la refaire souvent sans te retaper des clics. L’idée n’est pas d’avoir un “score”, c’est d’extraire des métriques stables et de stocker l’historique.

// lighthouserc.js
module.exports = {
  ci: {
    collect: {
      numberOfRuns: 10,
      url: [
        'https://example.com/',
        'https://example.com/article/mon-article'
      ],
      settings: {
        preset: 'mobile',
        throttlingMethod: 'simulate',
        // important : compare toujours les mêmes settings
      }
    },
    assert: {
      // pas de religion : mets des seuils réalistes, ou juste du reporting
      assertions: {
        'categories:performance': ['warn', {minScore: 0.6}],
      }
    },
    upload: {
      target: 'temporary-public-storage'
    }
  }
};

Pour la partie “adblock”, Lighthouse ne fournit pas un switch magique. Le plus simple reste d’exécuter Lighthouse dans un Chrome automatisé avec une extension adblock (ou un proxy type blocklist), puis de comparer deux séries. Ce n’est pas parfait, mais c’est reproductible si tu verrouilles l’environnement.

Option WebPageTest : la preuve par la waterfall (et par le CPU)

WebPageTest te donne des choses que Lighthouse abstrait : qui appelle quoi, qui bloque, à quel moment. Et surtout, tu peux visualiser les différences entre “normal” et “bloqué”.

Le point clé ici, c’est de rester strict : même localisation, même device, même connexion, même nombre de runs, et tu compares les médianes. Si tu as besoin d’un résultat “présentable”, tu ajoutes la vidéo et le filmstrip, parce que le jank se voit.

Les métriques à regarder (sinon tu vas te faire balader par un score)

Si tu veux prouver que “les tiers” dégradent l’UX, ne reste pas coincé sur LCP/CLS comme deux totems. Oui, c’est important, mais la pub tape très fort ailleurs.

Regarde le CPU time et les long tasks. C’est souvent la signature numéro 1 : un main thread qui n’arrive plus à respirer. Sur beaucoup de sites, tu peux avoir un LCP “acceptable” mais une page qui devient pénible dès qu’on scroll, qu’on clique, qu’on ouvre un menu. Ça, c’est l’INP dans la vraie vie. Et en lab, tu le vois via des proxys : Total Blocking Time, long tasks, timings d’exécution JS.

Regarde le nombre de requêtes et la waterfall. Les stacks pub rajoutent des dizaines voire des centaines d’appels, souvent en cascade, avec des DNS/TLS à répétition, et parfois des ressources qui se battent pour la priorité réseau. Même quand ça ne “bloque pas” techniquement, ça crée de la contention. Sur mobile, ça se paye.

Regarde aussi ce que j’appelle le “bruit” : JS téléchargé vs JS exécuté, scripts injectés après coup, iframes, timers, observers, listeners partout. Le poids en Ko est parfois moins grave que l’exécution et la replanification du travail sur le thread principal. Deux tags “légers” peuvent te plomber plus qu’un bundle plus gros mais stable.

Et évidemment, sépare TTFB (serveur) de tout le reste (client). Si ton TTFB est mauvais, la pub n’est pas ton seul sujet. Mais si TTFB est correct et que tout explose après, ton dossier “tiers” devient solide.

Attribuer “qui coûte quoi” : arrêter le Cluedo des scripts tiers

Le piège classique, c’est de voir “plein de JS” et de conclure “c’est la pub”. Sauf que la pub, c’est rarement un seul script. C’est un graphe. Tag manager, CMP, header bidding, wrappers, pixels, A/B testing, anti-adblock, analytics… et souvent des trucs qui se chargent entre eux.

Pour attribuer proprement, j’utilise trois angles qui se recoupent. D’abord, la waterfall réseau et les initiateurs : qui déclenche quelles requêtes, à quel moment, et qui attend quoi. Ensuite, le profil CPU (Performance panel) : quelles fonctions mangent le temps, quels scripts créent des long tasks, quels callbacks reviennent en boucle. Enfin, une vue “tiers” au niveau domaine : regrouper par eTLD+1 et identifier les gros pourcentages de temps réseau/CPU.

Sur DevTools, la combo qui aide vraiment en audit, c’est de corréler le réseau (domaine + initiator) et le CPU (call tree). Tu identifies vite les suspects : un script tiers qui parse, qui fait du layout thrash, qui force des recalculs de style, qui pose 200 listeners, qui spamme des timers. Et là, tu ne débats plus. Tu as des traces.

Attention à un truc : beaucoup de stacks pub s’exécutent dans des iframes, ou injectent des iframes. Ça peut brouiller l’attribution si tu ne regardes que “la page” sans étendre aux frames. Si ton tooling te le permet, inclus-les dans ton analyse, sinon tu vas sous-estimer le coût.

Traduire la mesure en décisions : budget perf par provider, kill switch, chargement conditionnel

Mesurer, c’est bien. Mais si ça finit en PDF “intéressant” qui n’a aucun impact, tu as juste fait un audit pour te rassurer. La partie utile, c’est de transformer la taxe UX en règles d’équipe.

Le budget perf, je le formule en langage simple et testable. Exemple : « sur la page article mobile, les tiers ne doivent pas ajouter plus de X ms de long tasks médianes, ni plus de Y requêtes, ni dépasser Z Ko de JS exécuté ». Tu peux même l’exprimer en delta “avec vs sans” parce que c’est parlant : « la version monétisée ne doit pas dégrader l’INP proxy au-delà de N% ». L’idée, c’est d’avoir une barre claire quand quelqu’un propose “un nouveau partenaire”.

Le kill switch, c’est non négociable dès que tu as plus de deux scripts tiers critiques business. Un flag serveur ou un remote config qui te permet de désactiver un provider sans redeploy. Pas pour tricher, pour survivre. Le jour où un domaine tiers ralentit tout ou devient instable, tu veux réduire le blast radius en 2 minutes, pas faire une war room.

Le chargement conditionnel est souvent le meilleur compromis. Beaucoup de scripts n’ont pas besoin d’être là au premier paint. Charger à l’idle, après consent, après première interaction, ou uniquement quand l’emplacement pub entre dans le viewport, ça change la vie. Tu ne “supprimes” pas la monétisation, tu la déplaces dans le temps pour protéger l’expérience.

Les erreurs fréquentes qui te flinguent la crédibilité (et les chiffres)

La première erreur, c’est de croire que “adblock = version sans ads”. Un adblock bloque aussi des trackers, des pixels, parfois des endpoints analytics, parfois même des CDN selon les règles. Donc oui, tu isoles une “taxe tiers”, mais pas uniquement “la pub”. Ce n’est pas un défaut si tu l’assumes et si tu cadres : tu mesures l’écosystème tiers tel qu’il existe, pas uniquement la ligne “ad server”.

La deuxième erreur, c’est de comparer deux runs qui n’ont rien à voir. Consentement différent, cache différente, A/B test différent, géo différente, contenu différent. Tu rigoles, mais c’est la réalité sur des gros sites. Si tu veux convaincre, tu dois pouvoir dire « mêmes pages, mêmes conditions, médiane sur 10 runs » sans trembler.

La troisième erreur, c’est de discuter “ressenti” contre “score”. Si ton objectif, c’est l’UX, montre des signaux UX : long tasks, jank visible, interactions qui collent, timeline qui sature. Le score Lighthouse est pratique pour démarrer, pas pour arbitrer une stack pub.

Comment en parler à la monétisation (sans jouer l’ayatollah perf)

Si tu arrives avec « la pub c’est mal », tu perds. Et en plus, c’est faux. Le sujet, c’est la qualité d’exécution et le coût marginal de chaque ajout tiers.

Ce qui marche, c’est de parler en trade-offs concrets. « Voilà le delta de CPU et d’interaction quand on active tel provider. Voilà ce que ça fait sur mobile milieu de gamme. Voilà la différence sur des pages à forte audience. Maintenant, est-ce que le revenu marginal justifie ce coût UX ? ». Si tu poses la question comme ça, tu changes le débat : ce n’est plus une guerre de chapelles, c’est une décision produit.

Et tu peux proposer des compromis intelligents. Par exemple, un provider qui ne se charge que sur des pages longues, ou après un certain scroll. Ou un mode “safe” activable en cas d’incident. Ou un budget qui autorise une expérimentation deux semaines, puis rollback si les métriques ne tiennent pas. La monétisation a besoin de vitesse d’itération. Toi tu as besoin de garde-fous. Les deux peuvent cohabiter.

Mon avis : si tu ne mesures pas la taxe UX des tiers, tu pilotes à l’aveugle

Sur un site monétisé, la perf n’est pas un sujet “frontend” isolé. C’est une chaîne d’approvisionnement. Et tant que tu n’as pas un protocole simple pour isoler l’impact des tiers, tu vas passer ta vie à te disputer avec des intuitions.

Le combo “adblock vs normal” n’est pas parfait, mais il est redoutablement efficace pour mettre un chiffre sur un malaise. Ensuite, tu affines : attribution, budgets, kill switch, chargements conditionnels. Et surtout, tu rends la discussion adulte : on accepte la monétisation, mais on refuse de la laisser conduire la voiture.

Sources

• Reddit (r/adops) — Update: Benchmarking the “True UX” tax