Publié le 22 septembre 2025, dernière mise à jour le 7 janvier 2026
Pour les utilisateurs, peu de choses sont plus frustrantes qu'une page Web qui ralentit soudainement, décharge leur batterie ou consomme leur forfait de données mensuel. Parfois, le problème n'est pas le contenu qu'ils sont venus consulter, mais une publicité diffusée en arrière-plan.
Pour protéger l'expérience utilisateur, Chrome impose des limites aux ressources qu'une annonce peut utiliser. Lorsqu'une annonce dépasse ces limites et devient une annonce lourde, Chrome la décharge pour libérer les ressources de l'appareil.
Cette documentation explique le fonctionnement de cette intervention, les seuils spécifiques impliqués et certaines bonnes pratiques que vous pouvez utiliser pour vous assurer que les annonces fonctionnent correctement.
Qu'est-ce que l'intervention sur les annonces lourdes ?
L'intervention sur les annonces lourdes est un mécanisme de Chrome qui surveille l'utilisation des ressources des cadres d'annonces. Si une annonce consomme une quantité disproportionnée de bande passante ou de puissance de traitement du processeur, Chrome décharge ce cadre d'annonce spécifique.
Au lieu de l'annonce, l'utilisateur voit une zone grise avec le message Annonce supprimée , généralement accompagné d'un lien Détails expliquant que l'annonce a utilisé trop de ressources.
Quand une annonce est-elle considérée comme lourde ?
Chrome détermine qu'une annonce est lourde en fonction de trois seuils spécifiques. Si un utilisateur n'a pas interagi avec une annonce et qu'elle répond à l'un des critères suivants, elle est déchargée :
- Utilisation du réseau : l'annonce utilise plus de quatre mégaoctets de bande passante.
- Utilisation maximale du processeur : l'annonce utilise le thread principal pendant plus de 15 secondes dans une fenêtre de 30 secondes.
- Utilisation totale du processeur : l'annonce utilise le thread principal pendant plus de 60 secondes au total. Toutes les ressources utilisées par les iFrames descendants du cadre d'annonce sont comptabilisées dans les limites de l'intervention sur cette annonce.
Quels sont les déclencheurs courants de cette intervention ?
Certains types de comportements d'annonces sont plus susceptibles de déclencher ces interventions que d'autres. Causes courantes :
- Contenu multimédia non compressé : chargement d'images extrêmement volumineuses et mal compressées.
- JavaScript lourd : exécution d'opérations étendues, telles que le décodage de fichiers vidéo à l'aide de JavaScript.
- Calculs lourds : exécution de calculs complexes en arrière-plan.
- Contenu vidéo sans gestes : chargement de fichiers vidéo volumineux avant qu'un utilisateur n'interagisse avec une annonce.
Que se passe-t-il lorsqu'une annonce est supprimée ?
Lorsque Chrome détecte qu'une annonce a dépassé les seuils d'annonces lourdes, il prend des mesures immédiates pour protéger les ressources de l'appareil de l'utilisateur.
L'expérience utilisateur
Du point de vue de l'utilisateur, l'annonce est immédiatement déchargée. À la place, Chrome affiche une zone grise avec le message Annonce supprimée. Si l'utilisateur clique sur Détails dans le conteneur, une explication spécifique s'affiche.
L'expérience développeur
Chrome génère également un rapport d'intervention avec l'API Reporting pour vous indiquer exactement ce qui s'est passé. Auparavant, ces rapports n'étaient envoyés qu'au cadre d'annonce lui-même et à ses cadres descendants. Toutefois, les éditeurs n'avaient souvent aucun moyen de savoir que des annonces étaient supprimées de leurs propres pages. Pour résoudre ce problème, Chrome a étendu le mécanisme de création de rapports. Les rapports d'intervention sont désormais envoyés au cadre d'intégration (le parent du cadre d'annonce racine) en plus du cadre d'annonce lui-même. Les rapports envoyés au cadre d'intégration incluent l'ID du cadre enfant et l'URL du cadre d'annonce.
Pour configurer la page pour les rapports HTTP, la réponse doit inclure l'en-tête Report-To :
Reporting-Endpoints: default="https://example.com/reports"
La requête POST déclenchée inclura un rapport comme celui-ci :
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?utm_source=devtools"
}
}]
Le cadre d'intégration recevra un rapport semblable, adressé à l'URL du cadre d'intégration, mais le message contiendra également l'ID du cadre enfant et l'URL spécifique du cadre enfant :
...
"message": "Ad was removed because its CPU usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384?utm_source=devtools (id=123;url=http://example2.com/pre-redirect-ad-url.html)"
...
L'API JavaScript fournit le ReportingObserver avec une méthode observe() qui peut être utilisée pour déclencher un rappel fourni sur les interventions. 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 using 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();
Étant donné que l'intervention décharge la page iFrame (par exemple, une annonce), utilisez l'événement pagehide pour vous assurer que le rappel de création de rapports capture le rapport d'intervention avant que la page ne disparaisse.
window.addEventListener('pagehide', (event) => {
// pull all pending reports from the queue
let reports = observer.takeRecords();
sendReports(reports);
});
Le JSON résultant de 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',
},
},
];
Bonnes pratiques pour les développeurs
Pour éviter que vos annonces ne soient placées sous la bannière d'annonces lourdes, tenez compte des bonnes pratiques suivantes :
- Exiger une interaction de l'utilisateur pour le contenu lourd : les critères d'intervention s'appliquent aux annonces avec lesquelles l'utilisateur n'a pas interagi. Si un utilisateur clique ou appuie sur votre annonce, les limites de ressources ne s'appliquent plus. Pour les expériences vidéo ou rich media, attendez un geste de l'utilisateur (comme un "clic pour lire") avant de charger des composants lourds.
- Optimiser les images et les vidéos : assurez-vous que les images sont compressées et que les vidéos sont optimisées pour le Web. Évitez de charger automatiquement des fichiers vidéo volumineux. Utilisez plutôt des espaces réservés légers jusqu'à ce que l'utilisateur s'engage.
- Vérifier l'utilisation du processeur : les animations complexes ou les opérations JavaScript qui déclenchent une mise en page et une peinture continues peuvent entraîner une augmentation de l'utilisation du processeur. Utilisez des outils pour identifier les goulots d'étranglement dans votre code qui pourraient occuper le thread principal pendant de longues périodes.
- Surveiller les cadres descendants : n'oubliez pas que le nombre de ressources inclut tout ce qui se trouve dans l'iFrame de votre annonce. Si votre annonce charge des pixels de suivi ou des sous-cadres tiers, leur utilisation des ressources est comptabilisée dans votre limite.
- Isoler le contenu non publicitaire : séparez les cadres de contenu non publicitaire en différents domaines ou en patterns reconnaissables qui ne sont pas susceptibles d'être considérés comme des domaines publicitaires par le règlement du fournisseur de la liste de filtres.
Comment déboguer et diagnostiquer la cause d'une intervention ?
Pour dépanner et résoudre efficacement les interventions sur les annonces lourdes, vous devez d'abord comprendre comment la logique de détection de Chrome identifie le contenu comme une annonce, puis utiliser les outils de développement intégrés pour vérifier les déclencheurs de ressources spécifiques qui ont entraîné la suppression.
Comment Chrome détecte-t-il la présence d'une annonce ?
Chrome balise le contenu comme une annonce en comparant les requêtes de ressources à une liste de filtres. La logique de détection s'applique au contenu des iFrames. Le cadre de la page principale n'est jamais considéré comme lié à une annonce, même s'il contient des scripts publicitaires. Notez qu'un iFrame chargé à partir d'une ressource correspondant à la liste de filtres sera considéré comme une annonce, même si d'autres contenus non publicitaires sont également chargés à partir de ce cadre. Par exemple, un lecteur vidéo chargé dans un iFrame balisé comme une annonce peut également charger du contenu non publicitaire.
Comment vérifier la détection des annonces ?
En tant que développeur, vous pouvez vérifier visuellement si Chrome a détecté votre contenu comme une annonce à l'aide des Outils pour les développeurs Chrome.
- Mise en surbrillance des cadres d'annonces : dans le panneau "Rendering", sélectionnez Highlight Ad Frames (Mettre en surbrillance les cadres d'annonces). Les cadres d'annonces détectés sont mis en surbrillance en rouge à l'écran.
- Annotation d'élément : dans le panneau "Elements" (Éléments), les iFrames d'annonces détectés affichent une annotation d'annonce à côté de la balise
<iframe>d'ouverture. - Activité réseau : dans le panneau Réseau, filtrez les requêtes en fonction d'un booléen
Is ad-related(Est lié à une annonce). - État de l'annonce : dans le panneau "Application", sous la section Frames (Cadres), les cadres balisés comme des annonces incluent un attribut
Ad Status(État de l'annonce).
Comment diagnostiquer la cause d'une intervention ?
Chrome fournit des outils pour vérifier et améliorer la qualité et les performances des pages Web. Exécutez Lighthouse dans les Outils pour les développeurs Chrome pour obtenir des rapports sur les performances de votre page. Vous pouvez également consulter la collection web.dev/fast et en savoir plus sur les Core Web Vitals.
Utilisation du réseau
Affichez le panneau Network (Réseau) dans les Outils pour les développeurs Chrome pour afficher l'activité réseau globale de l'annonce. Cochez l'option Disable cache (Désactiver le cache) pour obtenir des résultats cohérents lors des chargements répétés.
La valeur transférée en bas de la page indique la quantité transférée pour l'ensemble de la page. Pour limiter les requêtes à celles liées à l'annonce, utilisez l'entrée Filter (Filtrer) en haut.
Si vous trouvez la requête initiale de l'annonce, par exemple la source de l'iFrame, utilisez l'onglet "Initiator" (Initiateur) dans la requête pour afficher toutes les requêtes qu'elle déclenche.
Trier la liste globale des requêtes par taille est un bon moyen de repérer les ressources trop volumineuses. Les causes courantes incluent les images et les vidéos qui n'ont pas été optimisées.
De plus, le tri par nom peut être un bon moyen de repérer les requêtes répétées. Il peut s'agir non pas d'une seule ressource volumineuse déclenchant l'intervention, mais d'un grand nombre de requêtes répétées qui dépassent progressivement la limite.
Utilisation du processeur
Le panneau Performance des Outils pour les développeurs vous aidera à diagnostiquer les problèmes d'utilisation du processeur. Ouvrez le menu "Capture Settings" (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 les appareils moins puissants que sur les machines de développement haut de gamme.
Cliquez ensuite sur le bouton Record (Enregistrer) pour commencer à enregistrer l'activité. Vous pouvez essayer différentes durées et différents moments d'enregistrement, car une trace longue peut prendre un certain temps à charger. Une fois l'enregistrement chargé, vous pouvez utiliser la chronologie en haut pour sélectionner une partie de l'enregistrement. Concentrez-vous sur les zones du graphique en jaune, violet ou vert uni qui représentent les scripts, le rendu et la peinture.
Explorez les onglets "Bottom-Up" (De bas en haut), "Call Tree" (Arborescence des appels) et "Event Log" (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.
Le fichier source associé est également lié, ce qui vous permet de le suivre jusqu'au panneau Sources pour examiner le coût de chaque ligne.
Les problèmes courants à rechercher ici sont les animations mal optimisées qui déclenchent une mise en page et une peinture continues, ou les opérations coûteuses qui sont masquées dans une bibliothèque incluse.
Comment signaler des interventions incorrectes ?
Si du contenu non publicitaire a été balisé comme tel, envisagez de modifier le code pour éviter de correspondre aux règles de filtrage ou contactez directement les responsables d'EasyList pour modifier les règles de filtrage. N'oubliez pas que l'intervention sur les annonces lourdes n'a pas d'impact sur les cadres avec un geste de l'utilisateur. Vous pouvez donc exclure les vidéos en demandant de cliquer sur un bouton de lecture avant de charger le contenu. Si EasyList ne correspond pas à votre contenu et que Chrome a classé par erreur le contenu comme lié à une annonce, vous pouvez signaler un problème à Chrome à l'aide de ce modèle. Lorsque vous signalez un problème, incluez un exemple capturé du rapport d'intervention et un exemple d'URL pour reproduire le problème.