Gérer les interventions sur les annonces lourdes

Les annonces qui consomment une quantité disproportionnée de ressources sur un appareil ont un impact négatif sur l'expérience utilisateur, allant des effets évidents de la dégradation des performances à des conséquences moins visibles telles que la décharge de la batterie ou l'utilisation de la bande passante. Ces annonces vont des annonces activement malveillantes, comme les mineurs de cryptomonnaies, aux contenus authentiques présentant des bugs involontaires ou des problèmes de performances.

Chrome définit des limites sur les ressources qu'une annonce peut utiliser et décharge cette annonce si les limites sont dépassées. Pour en savoir plus, consultez l'annonce sur le blog Chromium. Le mécanisme utilisé pour décharger les annonces est l'intervention sur les annonces intensives.

Critères d'annonces gourmandes en ressources

Une annonce est considérée comme lourde si l'utilisateur n'a pas interagi avec elle (par exemple, s'il n'a pas appuyé dessus ni cliqué dessus) et si elle répond à l'un des critères suivants:

  • Utilise le thread principal pendant plus de 60 secondes au total
  • Utilise le thread principal pendant plus de 15 secondes dans une période de 30 secondes
  • utilise plus de 4 mégaoctets de bande passante réseau ;

Toutes les ressources utilisées par les iframes descendants du frame de l'annonce sont comptabilisées dans les limites d'intervention sur cette annonce. Il est important de noter que les limites de temps du thread principal ne sont pas les mêmes que le temps écoulé depuis le chargement de l'annonce. Les limites concernent le temps nécessaire au processeur pour exécuter le code de l'annonce.

Tester l'intervention

L'intervention a été publiée dans Chrome 85, mais par défaut, un bruit et une variabilité sont ajoutés aux seuils pour protéger la confidentialité des utilisateurs.

Si chrome://flags/#heavy-ad-privacy-mitigations est Désactivé, ces protections sont supprimées, ce qui signifie que les restrictions sont appliquées de manière déterministe, uniquement en fonction des limites. Cela devrait faciliter le débogage et les tests.

Lorsque l'intervention est déclenchée, le contenu de l'iFrame doit être remplacé par le message Annonce supprimée. Si vous cliquez sur le lien Détails inclus, un message s'affiche pour vous expliquer : Cette annonce utilise trop de ressources pour votre appareil. Chrome l'a donc supprimée.

Vous pouvez voir l'intervention appliquée à un exemple de contenu sur heavy-ads.glitch.me. Vous pouvez également utiliser ce site de test pour charger une URL arbitraire afin de tester rapidement votre propre contenu.

Sachez que lors des tests, plusieurs raisons peuvent empêcher l'application d'une intervention.

  • Si vous rechargez la même annonce sur la même page, cette combinaison sera exemptée de l'intervention. Vous pouvez essayer de vider votre historique de navigation et d'ouvrir la page dans une nouvelle balise.
  • Assurez-vous que la page reste au premier plan. Si vous passez en arrière-plan (en basculant vers une autre fenêtre), les files d'attente de tâches de la page seront mises en pause et ne déclencheront donc pas l'intervention du processeur.
  • Assurez-vous de ne pas appuyer ni cliquer sur le contenu de l'annonce pendant les tests. L'intervention ne sera pas appliquée au contenu qui reçoit une interaction utilisateur.

Que devez-vous faire ?

Vous diffusez des annonces d'un fournisseur tiers sur votre site

Aucune action n'est requise. Sachez simplement que les utilisateurs peuvent voir des annonces qui dépassent les limites supprimées sur votre site.

Vous diffusez des annonces propriétaires sur votre site ou vous fournissez des annonces display tierces.

Pour vous assurer d'implémenter la surveillance nécessaire via l'API Reporting pour les interventions liées aux annonces volumineuses, poursuivez votre lecture.

Vous créez du contenu publicitaire ou gérez un outil permettant de le faire

Pour savoir comment tester votre contenu afin de détecter les problèmes de performances et d'utilisation des ressources, poursuivez votre lecture. Reportez-vous également aux conseils concernant les plates-formes publicitaires de votre choix, car elles peuvent vous fournir des conseils techniques supplémentaires ou des restrictions. Par exemple, reportez-vous aux Consignes Google pour les créations display. Envisagez de créer des seuils configurables directement dans vos outils de création pour éviter que les annonces peu performantes ne soient diffusées.

Que se passe-t-il lorsqu'une annonce est supprimée ?

Une intervention dans Chrome est signalée via l'API Reporting (API de création de rapports) avec un type de rapport intervention. Vous pouvez utiliser l'API Reporting pour être averti des interventions, soit par une requête POST à un point de terminaison de création de rapports, soit dans votre code JavaScript.

Ces rapports sont déclenchés sur l'iFrame racine taguée avec des annonces, ainsi que sur tous ses descendants, c'est-à-dire sur chaque frame désinstallé par l'intervention. Cela signifie que si une annonce provient d'une source tierce, c'est-à-dire d'une iframe intersites, c'est à ce tiers (par exemple, le fournisseur d'annonces) de gérer le rapport.

Pour configurer la page pour les rapports HTTP, la réponse doit inclure l'en-tête Report-To:

Report-To: { "url": "https://example.com/reports", "max_age": 86400 }

La requête POST déclenchée inclura un rapport comme suit:

POST /reports HTTP/1.1
Host: example.com

Content-Type: application/report

[{
 "type": "intervention",
 "age": 60,
 "url": "https://example.com/url/of/ad.html",
 "body": {
   "sourceFile": null,
   "lineNumber": null,
   "columnNumber": null,
   "id": "HeavyAdIntervention",
   "message": "Ad was removed because its CPU usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384"
 }
}]

L'API JavaScript fournit à ReportingObserver une méthode observe() qui peut être utilisée pour déclencher un rappel fourni lors d'une intervention. Cela peut être utile si vous souhaitez joindre des informations supplémentaires au rapport pour faciliter le débogage.

// callback that will handle intervention reports
function sendReports(reports) {
  for (let report of reports) {
    // Log the `report` json via your own reporting process
    navigator.sendBeacon('https://report.example/your-endpoint', report);
  }
}

// create the observer with the callback
const observer = new ReportingObserver(
  (reports, observer) => {
    sendReports(reports);
  },
  { buffered: true }
);

// start watching for interventions
observer.observe();

Toutefois, comme l'intervention supprime littéralement la page de l'iFrame, vous devez ajouter un système de secours pour vous assurer que le rapport est définitivement capturé avant que la page ne disparaisse complètement, par exemple une annonce dans un iFrame. Pour ce faire, vous pouvez associer le même rappel à l'événement pagehide.

window.addEventListener('pagehide', (event) => {
  // pull all pending reports from the queue
  let reports = observer.takeRecords();
  sendReports(reports);
});

N'oubliez pas que, pour protéger l'expérience utilisateur, l'événement pagehide limite la quantité de travail pouvant être effectuée. Par exemple, si vous essayez d'envoyer une requête fetch() avec les rapports, cette requête sera annulée. Vous devez utiliser navigator.sendBeacon() pour envoyer ce rapport. Même dans ce cas, le navigateur ne peut pas garantir que le rapport sera envoyé.

Le JSON généré par le code JavaScript est semblable à celui envoyé dans la requête POST:

[
  {
    type: 'intervention',
    url: 'https://example.com/url/of/ad.html',
    body: {
      sourceFile: null,
      lineNumber: null,
      columnNumber: null,
      id: 'HeavyAdIntervention',
      message:
        'Ad was removed because its network usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384',
    },
  },
];

Diagnostiquer la cause d'une intervention

Le contenu des annonces n'est qu'un contenu Web. Utilisez donc des outils tels que Lighthouse pour auditer les performances globales de votre contenu. Les audits qui en résultent fournissent des conseils intégrés sur les améliorations à apporter. Vous pouvez également consulter la collection web.dev/fast.

Vous pouvez trouver utile de tester votre annonce dans un contexte plus isolé. Vous pouvez utiliser l'option d'URL personnalisée sur https://heavy-ads.glitch.me pour tester cela avec une iframe taguée avec des annonces prête à l'emploi. Vous pouvez utiliser les outils pour les développeurs Chrome pour vérifier qu'un contenu a été tagué comme une annonce. Dans le panneau Rendering (Affichage), accessible via le menu à trois points , puis More Tools > Rendering (Autres outils > Affichage), sélectionnez Highlight Ad Frames (Mettre en surbrillance les cadres d'annonces). Si vous testez du contenu dans la fenêtre de premier niveau ou dans un autre contexte où il n'est pas tagué comme une annonce, l'intervention ne sera pas déclenchée, mais vous pouvez toujours vérifier manuellement les seuils.

L'état de l'annonce d'un frame est également affiché dans le panneau Éléments, où une annotation ad est ajoutée après la balise <iframe> d'ouverture. Vous pouvez également le voir dans le panneau Application sous la section Frames, où les frames avec tags d'emplacement publicitaire incluront un attribut Ad Status.

Utilisation du réseau

Affichez le panneau Network (Réseau) dans Chrome DevTools pour afficher l'activité réseau globale de l'annonce. Assurez-vous que l'option Désactiver le cache est cochée pour obtenir des résultats cohérents lors de chargements répétés.

Panneau &quot;Network&quot; (Réseau) dans les outils de développement
Panneau "Network" (Réseau) dans DevTools.

La valeur transférée au bas de la page indique le montant transféré pour l'ensemble de la page. Pensez à utiliser le champ Filtrer en haut de la page pour limiter les requêtes à celles liées à l'annonce.

Si vous trouvez la requête initiale de l'annonce, par exemple la source de l'iFrame, vous pouvez également utiliser l'onglet Initiator (Initiateur) de la requête pour afficher toutes les requêtes qu'elle déclenche.

Onglet &quot;Initiateur&quot; d&#39;une requête.
Onglet "Initiateur" d'une requête.

Le tri de la liste globale des requêtes par taille est un bon moyen de repérer les ressources trop volumineuses. Les images et les vidéos non optimisées sont souvent en cause.

Triez les requêtes par taille de réponse.
Triez les requêtes par taille de réponse.

De plus, le tri par nom peut être un bon moyen de repérer les requêtes répétées. Ce n'est pas nécessairement une seule grande ressource qui déclenche l'intervention, mais un grand nombre de requêtes répétées qui dépassent progressivement la limite.

Utilisation du processeur

Le panneau Performances de DevTools vous aidera à diagnostiquer les problèmes d'utilisation du processeur. La première étape consiste à ouvrir le menu des paramètres de capture. Utilisez le menu déroulant CPU pour ralentir le processeur autant que possible. Les interventions pour le processeur sont beaucoup plus susceptibles de se déclencher sur des appareils moins puissants que sur des machines de développement haut de gamme.

Activez la limitation de la bande passante du réseau et du processeur dans le panneau &quot;Performances&quot;.
Activez la limitation du réseau et du processeur dans le panneau "Performances".

Cliquez ensuite sur le bouton Record (Enregistrer) pour commencer à enregistrer l'activité. Vous pouvez tester le moment et la durée d'enregistrement, car le chargement d'une longue trace peut prendre un certain temps. Une fois l'enregistrement chargé, vous pouvez utiliser la chronologie supérieure pour sélectionner une partie de l'enregistrement. Concentrez-vous sur les zones du graphique en jaune, violet ou vert unis qui représentent la mise en script, le rendu et la peinture.

Résumé d&#39;une trace dans le panneau &quot;Performances&quot;.
Résumé d'une trace dans le panneau "Performances".

Explorez les onglets De bas en haut, Arbre d'appels et Journal des événements en bas. Le tri de ces colonnes par Self Time (Temps propre) et Total Time (Temps total) peut vous aider à identifier les goulots d'étranglement dans le code.

Triez par &quot;Temps propre&quot; dans l&#39;onglet &quot;De bas en haut&quot;.
Triez par "Temps de l'utilisateur" dans l'onglet "De bas en haut".

Le fichier source associé est également associé à ce lien. Vous pouvez donc le suivre jusqu'au panneau Sources pour examiner le coût de chaque ligne.

Durée d&#39;exécution affichée dans le panneau &quot;Sources&quot;.
Temps d'exécution affiché dans le panneau "Sources".

Les problèmes courants à rechercher ici sont les animations mal optimisées qui déclenchent une mise en page et une peinture continues, ou des opérations coûteuses masquées dans une bibliothèque incluse.

Signaler des interventions incorrectes

Chrome marque un contenu comme une annonce en faisant correspondre les requêtes de ressources à une liste de filtres. Si du contenu autre qu'une annonce a été tagué, envisagez de modifier ce code pour éviter qu'il ne corresponde aux règles de filtrage. Si vous pensez qu'une intervention a été incorrectement appliquée, vous pouvez signaler un problème via ce modèle. Veuillez vous assurer d'avoir capturé un exemple du rapport d'intervention et d'avoir un exemple d'URL pour reproduire le problème.