Core Web Vitals pour les sites d’information et d’édition : publicité, défilement infini et emplacements publicitaires sans CLS

Des annonces qui décalent le texte, des enchères qui monopolisent le processeur, le défilement infini et les paywalls : comment concilier revenus publicitaires et expérience de lecture.

La page d’un journal en ligne avec un article et deux emplacements publicitaires en pointillés dans la colonne latérale, avec la règle CSS min-height

Les sites d’information et d’édition vivent une contradiction qu’aucun autre type de site ne connaît avec la même intensité. Leur modèle économique repose en grande partie sur la publicité, qui exige des scripts, des enchères en temps réel, des annonces qui arrivent tard et prennent de la place. En même temps, ils dépendent du trafic organique et des canaux de Google comme Discover et les À la une, où l’expérience de page compte, et de lecteurs qui abandonnent vite une page lente ou instable. Chaque annonce ajoutée apporte des revenus et enlève de la performance.

Cette tension ne se résout pas en renonçant à la publicité, mais en la gérant bien. Dans cet article, nous examinons les problèmes de Core Web Vitals typiques des sites d’information, des magazines et des blogs chargés de publicité, et les solutions qui permettent de concilier revenus et expérience de lecture : des emplacements publicitaires qui ne déplacent pas le texte, des annonces chargées au bon moment, de l’attention portée au défilement infini et des mesures qui relient les métriques aux revenus.

CLS et emplacements publicitaires

Le problème le plus visible, et celui qui fait le plus souvent sortir un site éditorial des seuils, est le CLS. Une annonce arrive après le texte : la page est affichée, le lecteur commence à lire, puis l’enchère se termine, l’annonce se charge et repousse vers le bas tout ce qui suit. Le lecteur perd sa place, et parfois touche l’annonce par erreur. Sur une page avec cinq ou six emplacements publicitaires dans le corps de l’article, ces décalages s’additionnent vite.

Comparaison entre deux articles : sans espace réservé, une annonce de 300 par 250 arrive après deux secondes et repousse le texte de 250 pixels vers le bas, faisant sauter ce que l’on était en train de lire ; avec un espace réservé, un encadré intitulé publicité occupe déjà la hauteur de l’annonce et le texte reste immobile à l’arrivée de l’annonce
L’espace doit être réservé avant la fin de l’enchère, avec la hauteur du format le plus fréquent.

La solution consiste à réserver l’espace dès le départ : chaque conteneur publicitaire doit avoir une hauteur minimale égale à celle du format qui y apparaît le plus souvent. Le chiffre provient des rapports du système publicitaire, qui montrent pour chaque emplacement la répartition des formats servis. Si un emplacement reçoit des formats différents, par exemple 300×250 et 300×600, vous réservez la hauteur du plus fréquent, en n’acceptant un décalage que dans les cas les moins courants, ou vous choisissez de limiter l’emplacement à des formats de tailles voisines. Une mention « Publicité » et un fond neutre dans le conteneur rendent l’espace vide compréhensible pour le lecteur pendant qu’il attend.

.slot-pubblicita {
	min-height: 250px;           /* format le plus fréquent pour cet emplacement */
	display: flex;
	align-items: center;
	justify-content: center;
	background: #f5f7fa;
}

@media ( min-width: 1024px ) {
	.slot-pubblicita--laterale {
		min-height: 600px;       /* sur desktop, l’emplacement de la colonne latérale sert des formats hauts */
	}
}

Reste à décider que faire lorsque l’emplacement n’est pas rempli, parce que l’enchère n’a produit aucune annonce. Replier le conteneur vide génère un décalage ; le laisser ouvert laisse un trou. Le choix raisonnable dépend de la position : les emplacements situés au-dessus de la partie visible ou à proximité sont mieux laissés ouverts, éventuellement avec un contenu de substitution comme une promotion interne ; ceux qui sont beaucoup plus bas peuvent être repliés avant que le lecteur n’y arrive. Les systèmes publicitaires les plus répandus proposent des options pour gérer le repli des emplacements vides, à configurer selon cette logique.

Certains formats sont intrinsèquement plus problématiques. Les annonces extensibles, les bannières insérées en haut de la page après le chargement et les formats qui s’ouvrent entre les paragraphes repoussent le contenu par construction. Les annonces ancrées en bas, en position fixe, et les interstitiels plein écran ne décalent pas la mise en page, mais ces derniers nuisent à l’expérience et Google les juge intrusifs lorsqu’ils recouvrent le contenu dès l’arrivée sur la page.

Le poids de la publicité programmatique

Le deuxième problème est le travail que la publicité demande au navigateur. Dans la publicité programmatique, avant qu’une annonce soit affichée, une enchère a lieu, à laquelle participent plusieurs acheteurs : chacun a son propre script, ses propres requêtes réseau, ses propres vérifications. À cela s’ajoutent les scripts du système de gestion publicitaire, ceux de vérification de la visibilité et de la sécurité, et le code des annonces elles-mêmes, parfois lourd. Sur de nombreux sites éditoriaux, la publicité est le premier poste de travail du processeur.

Répartition illustrative du temps de processeur dans un article typique : publicité et enchères 55 pour cent, analytics et suivi 15, thème et plugins 12, réseaux sociaux et commentaires 10, autre 8 ; causes fréquentes de travail excessif : enchères avec de nombreux participants et de longs délais d’attente, annonces toutes chargées au démarrage, annonces rechargées périodiquement, scripts de visibilité pour chaque annonce
Sur de nombreux sites éditoriaux, la publicité est le premier poste de travail du thread principal.

L’effet se voit surtout sur l’INP : les scripts publicitaires produisent des tâches longues sur le thread principal au moment même où le lecteur fait défiler la page, touche un lien ou ouvre le menu. Mais ils touchent aussi le LCP, quand les ressources publicitaires entrent en concurrence avec l’image d’ouverture de l’article, ainsi que la consommation de données et de batterie des appareils mobiles.

Leviers pour le réduire

  • Moins de participants aux enchères. Chaque acheteur supplémentaire apporte des revenus marginaux décroissants et un coût de performance constant. Analyser quels participants remportent réellement des enchères permet souvent d’en retirer plusieurs sans perte significative.
  • Délais d’attente plus courts. L’enchère a un temps maximal au-delà duquel elle se poursuit avec les offres reçues. Des délais longs attendent les acheteurs lents aux dépens de tous ; des délais plus courts réduisent l’attente, avec des effets souvent négligeables sur les revenus.
  • Lazy loading des annonces. Les annonces en bas de l’article ne doivent pas être demandées à l’ouverture de la page. Les principaux systèmes de gestion publicitaire permettent de les demander quand l’emplacement approche de la zone visible, avec des bénéfices aussi pour la visibilité mesurée et donc pour la valeur des annonces elles-mêmes.
  • Rechargement avec modération. Recharger les annonces au bout d’un certain temps augmente les impressions, mais répète tout le travail d’enchère pendant que l’utilisateur lit. Il faut le limiter aux emplacements réellement visibles et à des intervalles raisonnables.
  • Scripts au bon moment. Le code publicitaire doit être chargé de manière asynchrone et après les ressources critiques de l’article, jamais d’une façon qui bloque le rendu du texte.

L’image d’ouverture et le LCP

Dans les articles, l’élément LCP est presque toujours l’image d’ouverture ou, à défaut, le titre. Les règles sont les règles générales : image dans le HTML avec une priorité élevée, pas de lazy loading, dimensions et formats corrects, comme l’explique l’article sur le lazy loading. Les sites éditoriaux ajoutent deux pièges récurrents. Le premier, ce sont les bannières en haut de la page, au-dessus du titre, qui peuvent elles-mêmes devenir le plus grand élément ou repousser l’article hors de la zone visible. Le second, ce sont les systèmes d’abonnement et les paywalls, qui masquent parfois le contenu puis l’affichent après une vérification JavaScript, ce qui retarde l’affichage du texte.

Défilement infini des articles

De nombreux sites d’information chargent automatiquement, à la fin d’un article, l’article suivant, puis un autre, en changeant l’adresse dans la barre du navigateur. L’objectif est d’augmenter les pages vues et les impressions publicitaires. Du point de vue de la performance, pourtant, ce modèle se comporte comme une Single Page Application : la page ne cesse de grossir, avec des dizaines d’images et d’emplacements publicitaires en mémoire ; le CLS et l’INP s’accumulent sur toute la session et sont attribués au premier article ; chaque nouvel article apporte de nouvelles enchères et de nouveaux scripts. Après quelques articles, sur les smartphones moins puissants, le défilement devient lent et les interactions pénibles.

Une alternative consiste à proposer, en bas de l’article, une sélection de lectures associées sous forme de liens normaux, et à rendre la transition instantanée avec les Speculation Rules : chaque article reste une page à part entière, avec des métriques mesurées correctement et une mémoire libérée à chaque navigation, et le lecteur garde pourtant l’impression d’une lecture continue. Si le défilement infini est conservé, il vaut au moins la peine de limiter le nombre d’articles chargés à la suite et de retirer du document ceux qui ont déjà été lus.

AMP et après

Pendant des années, de nombreux éditeurs ont publié des versions AMP de leurs articles, aussi parce qu’elles étaient exigées pour apparaître dans certaines rubriques d’actualité des résultats de recherche. Depuis 2021, cette exigence n’existe plus : des pages normales peuvent apparaître à ces emplacements, et l’expérience de page est évaluée avec les mêmes Core Web Vitals. De nombreux éditeurs ont abandonné AMP pour se concentrer sur une seule version du site, rapide pour tout le monde. C’est la voie la plus durable : une seule version à maintenir, optimisée avec les techniques décrites dans cet article, au lieu de deux avec des compromis différents.

Commentaires, publications intégrées et vidéo

Outre la publicité, les articles contiennent souvent des éléments externes : des publications de réseaux sociaux intégrées pour citer une déclaration, des vidéos provenant de services de partage, des systèmes de commentaires tiers, des sondages. Chacun apporte son propre JavaScript et, souvent, une hauteur qui change à l’arrivée du contenu. Les solutions sont celles déjà vues pour les iframes tierces et pour la vidéo : des façades qui chargent le contenu au clic, de l’espace réservé, un chargement différé. Pour les publications de réseaux sociaux, une citation en HTML avec un lien vers l’original conserve la valeur journalistique sans le poids du widget ; pour les commentaires, ne charger le système que lorsque le lecteur atteint le bas de l’article, ou au clic sur un bouton, évite de faire payer le coût à ceux qui ne les lisent pas.

Un exemple

Un magazine en ligne au trafic majoritairement mobile a, sur ses articles, un CLS au 75e percentile de 0,32 et un INP de 380 millisecondes. L’analyse montre six emplacements publicitaires dans le corps de l’article sans hauteur réservée, une bannière en haut qui apparaît après le titre, une douzaine de participants aux enchères avec un délai d’attente de trois secondes et des annonces rechargées toutes les trente secondes même en dehors de la zone visible. Les modifications réservent la hauteur de chaque emplacement d’après les rapports de formats, déplacent la bannière du haut sous le titre avec de l’espace réservé, réduisent les participants aux six plus rentables avec un délai d’attente d’une seconde et demie, activent le lazy loading des annonces et limitent le rechargement aux emplacements visibles. Au bout d’un mois, le CLS tombe à 0,05 et l’INP passe sous 200 millisecondes ; les impressions visibles augmentent et les revenus par session restent sensiblement inchangés, avec plus de pages vues par visite.

Mesurer ensemble revenus et expérience

La façon la plus efficace de sortir de l’opposition entre publicité et performance est de mesurer les deux avec les mêmes données. Un système de Real User Monitoring, relié aux données d’analytics et de publicité, permet de voir pour chaque modèle de page les Core Web Vitals, les pages vues par session, le temps de lecture et les revenus par session. Il en ressort souvent que les sessions avec des pages plus rapides et plus stables produisent plus de pages vues et plus d’impressions visibles, compensant en partie ou totalement la réduction des emplacements ou des participants aux enchères.

La méthode la plus rigoureuse est un test contrôlé : une configuration publicitaire plus légère, par exemple avec moins d’emplacements ou moins de participants aux enchères, est servie à une partie des lecteurs, et les revenus par session, les pages vues et les métriques sont comparés à ceux de la configuration actuelle. Un test de quelques semaines donne une réponse fondée sur vos propres données, bien plus convaincante que n’importe quelle estimation externe, comme nous l’avons vu en parlant du retour économique de la performance.

En résumé

Sur les sites éditoriaux, les Core Web Vitals sont mis à l’épreuve surtout par la publicité : des annonces qui arrivent tard et décalent le texte, des enchères et des scripts qui occupent le processeur, des bannières qui concurrencent l’image d’ouverture. À cela s’ajoutent le défilement infini, qui accumule du travail et de la mémoire, et les paywalls qui retardent le contenu.

Les solutions permettent de préserver les revenus : un espace réservé pour chaque annonce, avec la hauteur du format le plus fréquent, moins de participants aux enchères et des délais d’attente plus courts, des annonces chargées quand elles sont sur le point de devenir visibles, un rechargement modéré, des articles en pages distinctes avec prerendering plutôt qu’un défilement infini. Et surtout des mesures qui réunissent expérience et revenus, pour que la décision sur la quantité de publicité soutenable soit prise sur des données et non sur des impressions.

L’ÉTAPE SUIVANTE

Commençons
par votre site.

Parlez-nous du projet, des problèmes que vous constatez et de vos objectifs. Ensemble, nous définirons une intervention sur mesure.

Demander une analyse

Vous mène au formulaire de la page Contact.

MANAGED SERVER S.R.L.info@corewebvitals.fr +39 02 5656 9681

Du lundi au vendredi · 9 h 30 – 19 h 30 (CET)

Vous préférez un formulaire en ligne ?
Contactez-nous sur managedserver.it ↗