Header bidding et Core Web Vitals : monétiser sans ralentir son site

La publicité finance une grande partie du web éditorial, mais elle a un coût pour vos pages. Les Core Web Vitals de Google mesurent précisément ce que le lecteur en ressent : le LCP (Largest Contentful Paint) mesure le temps d’affichage du contenu principal, l’INP (Interaction to Next Paint), qui a remplacé le FID en mars 2024, la réactivité aux clics et aux saisies, le CLS (Cumulative Layout Shift) la stabilité de la mise en page. Google considère une page comme bonne quand, au 75e centile des visites, le LCP est inférieur ou égal à 2,5 secondes, l’INP à 200 millisecondes et le CLS à 0,1. Ces indicateurs comptent aussi parmi les signaux d’expérience de page pris en compte par le moteur de recherche. Bonne nouvelle : header bidding et bons Core Web Vitals ne sont pas incompatibles. Voici les leviers, du plus simple au plus fin.

Ce que la publicité coûte à vos pages

Une page monétisée en header bidding charge plusieurs couches de code : la bibliothèque Prebid.js et ses adaptateurs, la bibliothèque Google Publisher Tag (GPT) qui dialogue avec Google Ad Manager, puis les scripts des créations elles-mêmes. Chacune pèse sur un indicateur différent.

• Le thread principal et l’INP. Préparer les enchères, traiter les réponses, poser les clés-valeurs et afficher les créations : ce travail s’exécute sur le même fil que votre page. Si un lecteur clique pendant ces tâches, la réponse attend, et l’INP se dégrade.
• Les insertions tardives et le CLS. Une publicité qui apparaît après le texte, sans espace prévu, pousse le contenu vers le bas. Le lecteur perd sa ligne, et le CLS grimpe.
• La concurrence pour le réseau et le LCP. Les requêtes publicitaires partagent la bande passante avec vos images et vos polices. Si elles partent trop tôt, l’élément principal de la page s’affiche plus tard.
• Les créations lourdes. Certaines publicités embarquent des vidéos, des animations ou des scripts de mesure volumineux. Chrome peut même décharger les publicités qui consomment trop de ressources.

Réserver l’espace des emplacements

C’est le levier le plus rentable contre le CLS. Chaque emplacement doit disposer de sa hauteur avant l’arrivée de la publicité, grâce à une hauteur minimale en CSS :

.ad-slot--article {
  min-height: 250px; /* format le plus fréquent sur cet emplacement */
}

Quand un emplacement accepte plusieurs formats, Google décrit les compromis possibles : réserver la hauteur du plus grand format supprime les décalages mais laisse parfois un blanc ; réserver celle du plus petit limite les blancs mais accepte quelques décalages. Une voie intermédiaire consiste à réserver la hauteur du format le plus souvent servi, d’après vos rapports.

Deux précautions complètent la règle :

• Les emplacements collants (bandeau en bas d’écran, colonne latérale) se positionnent au-dessus du contenu sans le déplacer ; prévoyez simplement une marge pour qu’ils ne masquent pas le texte ou les boutons.
• La réduction des emplacements vides (collapseEmptyDivs, remplacé dans la référence GPT actuelle par le réglage collapseDiv) doit être utilisée avec prudence. Replier un emplacement déjà affiché décale tout ce qui suit. Google recommande de laisser ouverts les emplacements qui se remplissent généralement, et de ne replier d’emblée que ceux qui se remplissent rarement.

Charger au bon moment

Un emplacement situé tout en bas d’un long article ne sera peut-être jamais vu. Le demander dès l’ouverture de la page consomme du réseau et du temps de calcul pour rien. GPT propose un chargement différé intégré :

googletag.pubads().enableLazyLoad({
  fetchMarginPercent: 500,  // demander l’annonce à 5 hauteurs d’écran
  renderMarginPercent: 200, // l’afficher à 2 hauteurs d’écran
  mobileScaling: 2.0        // marges doublées sur mobile
});

Les marges s’expriment en pourcentage de la hauteur de l’écran ; mobileScaling les multiplie sur mobile, où l’on fait défiler plus vite. La référence GPT marque désormais cette méthode comme dépréciée au profit de googletag.setConfig({ lazyLoad: { … } }), qui accepte les mêmes paramètres : utilisez la forme recommandée par la documentation en vigueur.

Ce chargement différé ne concerne que GPT. Pour que les enchères Prebid soient elles aussi différées, emplacement par emplacement, on désactive le chargement initial de GPT puis on déclenche l’enchère quand l’emplacement approche de l’écran. Comme pour les deux réglages précédents, la méthode googletag.pubads().disableInitialLoad() est dépréciée au profit de googletag.setConfig({ disableInitialLoad: true }) :

// slotsById : emplacements GPT définis au préalable, indexés par identifiant de bloc
googletag.cmd.push(() => {
  // Avant googletag.enableServices() : appliqué après, le réglage arrive trop tard.
  googletag.setConfig({ disableInitialLoad: true });
});

const observer = new IntersectionObserver((entries) => {
  entries.filter((e) => e.isIntersecting).forEach(({ target }) => {
    observer.unobserve(target);
    pbjs.que.push(() => {
      pbjs.requestBids({
        adUnitCodes: [target.id],
        bidsBackHandler: () => {
          googletag.cmd.push(() => {
            pbjs.setTargetingForGPTAsync([target.id]);
            googletag.pubads().refresh([slotsById[target.id]]);
          });
        },
      });
    });
  });
}, { rootMargin: '200% 0px' });

document.querySelectorAll('.ad-slot--lazy').forEach((el) => observer.observe(el));

Les files googletag.cmd et pbjs.que garantissent que chaque appel attend le chargement de la bibliothèque concernée, puisque les deux scripts se chargent en asynchrone.

Une règle ne souffre aucune exception : la publicité ne doit jamais bloquer le contenu principal. Chargez les scripts publicitaires en asynchrone, après le texte et l’image principale, et laissez les emplacements du haut de page partir immédiatement.

Régler les enchères

• Des timeouts adaptés à l’audience. Un timeout trop long retarde l’affichage des publicités ; trop court, il écarte des offres. Examinez les temps de réponse de chaque partenaire, séparément sur mobile et sur ordinateur, avant de choisir.
• Des rendements décroissants. Chaque bidder supplémentaire ajoute des requêtes et du code, pour un gain de revenu qui diminue souvent au-delà des premiers partenaires.
• Le module Price Floors. Les prix planchers de Prebid écartent les offres trop basses, par emplacement, format ou type de média. Ils se règlent sur vos données et se testent, car un plancher trop haut fait baisser le taux de remplissage.
• Le retrait des bidders peu performants. Taux de réponse, taux de victoire, revenu apporté et latence : un partenaire qui ralentit l’enchère sans rien gagner doit partir. La décision se prend sur données, pas sur impression.

Alléger Prebid.js

Prebid.js est modulaire : vous ne devez embarquer que les adaptateurs et modules réellement utilisés. Un build généré depuis la page de téléchargement officielle, ou construit depuis le code source avec la liste exacte de vos modules, évite de livrer du code inutile à chaque visiteur. Revoyez cette liste à chaque retrait de partenaire.

Mettez aussi la bibliothèque à jour régulièrement. Les nouvelles versions corrigent des défauts, suivent les évolutions des navigateurs et du consentement (la version en vigueur du TCF de l’IAB Europe) et améliorent parfois les performances. Une mise à jour se teste sur un environnement de préproduction, puis se déploie progressivement.

Enfin, si le nombre de partenaires reste élevé, déporter une partie des enchères sur un serveur peut alléger encore le navigateur : notre article Prebid.js ou Prebid Server : lequel choisir ? détaille cette option et l’approche hybride.

Rafraîchissement et visibilité

Rafraîchir un emplacement, c’est y afficher une nouvelle publicité sans recharger la page. Bien fait, cela augmente le revenu par session ; mal fait, cela gaspille des enchères et abîme la confiance des acheteurs.

• Ne rafraîchissez que les emplacements vus. GPT signale quand une impression est visible (événement impressionViewable) et quelle part d’un emplacement est à l’écran (événement slotVisibilityChanged). Un emplacement hors écran ne doit pas être rafraîchi.
• Signalez le rafraîchissement aux acheteurs, par exemple avec une clé-valeur dédiée, pour qu’ils puissent ajuster leurs offres.
• Respectez les règles de Google. Google Ad Manager demande de déclarer l’inventaire rafraîchi dans les règles d’inventaire, avec le type de déclencheur (action de l’utilisateur, événement ou intervalle de temps) et l’intervalle minimal entre deux rafraîchissements. Pour les rafraîchissements déclenchés par le temps ou par un événement, cet intervalle ne peut pas descendre sous 30 secondes. Une absence de déclaration ou une déclaration inexacte constitue une infraction à ses règles.

Chaque rafraîchissement relance aussi une enchère Prebid : il doit respecter les mêmes précautions que le premier affichage.

Mesurer

• CrUX et Search Console. Le rapport Core Web Vitals de la Search Console s’appuie sur les données de terrain du Chrome UX Report (CrUX), agrégées sur 28 jours glissants. C’est la vue la plus proche de ce que Google observe, mais elle réagit lentement.

• La mesure terrain avec web-vitals. La bibliothèque open source web-vitals mesure LCP, INP et CLS chez vos vrais visiteurs ; sa version d’attribution indique quel élément ou quel script est en cause. Envoyez ces données à votre outil d’analyse, avec la configuration publicitaire en vigueur.

  Pour l’INP, la version d’attribution fournit, pour l’interaction la plus lente, l’élément concerné, le type d’événement et la décomposition du délai : attente avant traitement, traitement, puis affichage. Dans les navigateurs qui prennent en charge l’API Long Animation Frames, elle joint aussi les longues frames d’animation, avec l’adresse des scripts qui les ont occupées. C’est le moyen le plus direct de savoir si la lenteur vient de Prebid.js, de GPT, du script d’une création ou de votre propre code. Regroupez ces données par type de page et selon l’état de la publicité au moment de l’interaction : un INP qui ne se dégrade que pendant les enchères désigne clairement la chaîne publicitaire, et oriente vers le bon levier (build allégé, moins de bidders ou enchères différées).

• Les rapports Google Ad Manager. Revenu, taux de remplissage, visibilité et CPM, par emplacement et par partenaire.

• Les tests A/B. Chaque changement significatif se teste sur une partie des visiteurs, assez longtemps pour que l’écart soit fiable, en suivant à la fois le revenu par session et les Core Web Vitals.

La checklist

1. Chaque emplacement a une hauteur minimale réservée en CSS.
2. Aucun emplacement n’est replié après affichage : seuls ceux qui se remplissent rarement démarrent repliés.
3. Les emplacements collants ne masquent ni le texte ni les boutons.
4. Les scripts publicitaires se chargent en asynchrone, après le contenu principal.
5. Les emplacements du haut de page sont demandés immédiatement ; les autres en différé.
6. Les enchères Prebid sont, elles aussi, différées pour les emplacements éloignés.
7. Les timeouts sont fixés à partir des temps de réponse mesurés, mobile et ordinateur séparés.
8. Chaque bidder justifie sa place par son revenu et sa latence.
9. Le build de Prebid.js ne contient que les modules utiles et reste à jour.
10. Le rafraîchissement ne touche que les emplacements vus et est déclaré dans Google Ad Manager.

Conclusion

Concilier revenus et vitesse n’a rien de magique : de l’espace réservé, un chargement au bon moment, des enchères réglées sur vos données et une mesure continue. La plupart de ces leviers s’activent sans changer de partenaires ni d’architecture ; et si le navigateur reste trop chargé, Prebid Server et l’approche hybride prennent le relais.

Ces réglages s’inscrivent dans un travail plus large sur le site : SEO technique, UX de lecture et performance, que détaille notre offre pour les éditeurs et médias. Pour un audit de votre chaîne publicitaire et de son effet sur vos Core Web Vitals, découvrez notre expertise AdTech et monétisation ou contactez-nous.

Pour aller plus loin

• Les Core Web Vitals (web.dev)
• Optimiser le CLS (web.dev)
• Chargement différé avec Google Publisher Tag (Google for Developers)
• Réduire les décalages de mise en page dus aux publicités (Google for Developers)
• Déclarer l’inventaire qui se rafraîchit (aide Google Ad Manager)
• Module Price Floors (documentation Prebid)
• Bibliothèque web-vitals (GitHub)