On a installé notre premier bloc AdSense en 2015 sur un blog WordPress. À l’époque, le LCP n’existait pas dans les rapports, et personne ne faisait le lien entre les trois iframes qui apparaissaient sur la page et le temps de chargement ressenti par les visiteurs. Dix ans plus tard, on débugge encore des sites où un adsbygoogle.js chargé sans stratégie coûte un point de LCP sur mobile, et personne dans l’équipe ne sait pourquoi leur indexation plafonne.
AdSense est structurellement hostile à la performance
Un site affiche son contenu, puis un script tiers vient s’incruster pour afficher une annonce. Cette mécanique de base est à l’opposé de ce que recherchent les Core Web Vitals. Le script AdSense, une fois appelé, déclenche une cascade de sous-requêtes, souvent vers doubleclick.net, google.com ou des régies partenaires. Chacune de ces requêtes négocie un espace, charge une creative parfois animée, et réserve une place dans le DOM. Le tout s’exécute via JavaScript, dans le thread principal.
Quand on regarde un waterfall chart d’une page monétisée, on voit le même schéma : le contenu éditorial est prêt en 1,2 seconde, mais l’annonce au-dessus de la ligne de flottaison continue de charger des ressources pendant 3 ou 4 secondes. Le LCP mesuré n’est pas celui de l’image de l’article, c’est celui de la dernière frame de la bannière publicitaire qui a fini de se peindre. Le navigateur a déjà rendu une partie utile de la page, mais le lab score Lighthouse reste coincé à 4 secondes parce que la creative est lourde.
Google a documenté ce phénomène. Les annonces sont des éléments dynamiques insérés tardivement, et le LCP ne se stabilise qu’une fois que tous les candidats potentiels ont fini de se charger. Afficher une annonce en haut de page, c’est garantir un LCP dégradé, quel que soit le soin apporté au reste du site.
La priorité des ressources : un script tiers ne sera jamais votre allié
Ouvre ton onglet Network, coche “Disable cache”, recharge une page avec trois blocs AdSense. Observe l’ordre des ressources. Le script adsbygoogle.js part souvent en priorité “Low” si tu ne fais rien. Sauf que ce même script injecte des iframes et relance des appels qui, eux, héritent d’une priorité “High” parce qu’ils chargent des éléments visibles. Tu te retrouves avec un contenu principal en concurrence avec des bannières pour la bande passante et le CPU.
Le vrai problème n’est pas le poids du script initial, c’est la cascade non contrôlée qu’il déclenche. Le navigateur ne priorise plus ton contenu, il exécute ce que le tiers lui envoie.
Pour reprendre la main, il faut au minimum baliser les appels publicitaires avec fetchpriority="low" sur les scripts que tu charges toi-même, et retarder l’exécution au maximum sans dépasser le seuil où l’impression n’est plus comptabilisée. C’est un réglage fin, mais celui qui sépare un site à 2,5 secondes d’un site à 3,8 secondes, avant même de toucher aux images.
Lazy loading des annonces : bonne idée, exécution piégeuse
Toutes les docs te diront de charger les annonces en différé. En pratique, ça veut dire déclencher adsbygoogle.push() uniquement quand le bloc entre dans le viewport, via un IntersectionObserver. On l’a fait sur une régie éditoriale qui traînait un LCP de 4,2 secondes sur mobile. Résultat après déploiement : LCP à 2,8 secondes, aucune perte de revenus mesurée sur trente jours. L’annonce se chargeait quand l’utilisateur scrollait, pas avant.
Le piège, c’est la première annonce au-dessus de la ligne de flottaison. Si tu la passes en lazy, elle ne se charge que lorsque le viewport est prêt, donc trop tard pour l’impression. Il faut alors distinguer les emplacements : ceux du haut de page sont chargés de manière asynchrone mais immédiate, avec un data-ad-status que tu vérifies pour ne pas bloquer le rendu, et tous les emplacements sous la ligne de flottaison sont différés. La nuance est rarement documentée, et c’est là que naissent les déceptions.
Variante observée : script AdSense en async, push au DOMContentLoaded. Ce n’est pas du lazy, c’est un décalage minimal qui libère le thread principal pendant les 800 premières millisecondes. Sur une page déjà rapide, ça suffit à basculer l’évaluation LCP du jaune au vert.
Le piège de l’auto-optimisation AdSense
L’auto-optimisation injecte des blocs supplémentaires sans vous consulter, pile entre deux paragraphes que le navigateur avait déjà stabilisés. On a mesuré un CLS de 0,18 sur une page de blog qui en était à 0,02 avant activation. Coupez le toggle dès qu’un dev front sait écrire un IntersectionObserver : la régie enchère sur les mêmes emplacements, qu’ils soient placés automatiquement ou à la main.
Server-side ad insertion : la seule issue pour les sites à fort trafic
Depuis deux ans, quelques hébergeurs edge permettent d’injecter les annonces côté serveur, avant que le HTML n’arrive dans le navigateur. Concrètement, le serveur fait l’appel à la régie, reçoit le contenu de l’annonce, et l’intègre dans le markup initial. Le navigateur ne voit qu’une balise <div> avec l’image et le lien d’affiliation déjà dedans. Plus de script tiers, plus d’iframe, plus de cascade.
Ce n’est pas une solution pour tout le monde. L’insertion serveur casse le ciblage comportemental fin, parce que l’appel à l’ad server se fait sans cookie utilisateur complet. Mais pour un site de contenu qui vit du volume et des CPM contextuels, le gain en performance est massif : LCP instantané, INP quasi nul, et un budget de crawl qui part dans l’indexation de vos pages au lieu de gaspiller du temps dans les scripts publicitaires.
Le INP, cet indicateur que les pubs transforment en cauchemar
Banc d’essai : une page de contenu avec trois emplacements AdSense, conditions mobiles simulées. INP à 280 ms. Le même contenu sans pub : 90 ms. Coupables identifiés : les callbacks de redimensionnement des iframes, qui s’exécutent dans le thread principal et retardent le traitement des événements utilisateur. Un format fixe avec hauteur réservée en CSS via aspect-ratio retire ce coût ; les formats expandables ou qui recalculent leur hauteur en cours de route l’entretiennent.
Questions fréquentes
Est-ce que supprimer AdSense améliore mécaniquement le référencement ?
Non, il n’y a pas de signal de classement direct qui punit les annonces. Mais un LCP et un INP dégradés à cause des scripts pub envoient un signal d’expérience utilisateur négatif que Google mesure. Indirectement, un site lent voit son crawl ralenti et son indexation moins profonde. La relation est indirecte, mais l’effet est réel sur la visibilité à moyen terme.
Faut-il bloquer le bot Googlebot sur les ressources publicitaires ?
Surtout pas. Googlebot doit voir vos annonces telles qu’elles apparaissent pour les utilisateurs, notamment pour détecter un éventuel contenu masqué ou une superposition abusive. Bloquer les scripts publicitaires dans le robots.txt peut conduire à une évaluation erronée de votre page et, dans le pire des cas, à une pénalité manuelle pour contenu différent entre le bot et l’utilisateur.
Peut-on monétiser sans aucun impact sur les Core Web Vitals ?
Pas avec le paradigme actuel des scripts tiers exécutés dans le navigateur. Même avec une insertion serveur, il reste des appels à l’ad server. L’objectif réaliste est de contenir la dégradation sous les seuils d’alerte en maîtrisant le nombre d’emplacements, leur position, et leur mode de chargement. Si votre page est déjà à la limite du rouge, chaque bloc supplémentaire comptera double.
