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 ne vient pas du contenu qu'ils souhaitent regarder, mais d'une publicité diffusée en arrière-plan.
Pour protéger l'expérience utilisateur, Chrome impose des limites sur les 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 concerné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 pour 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échargera ce frame d'annonce spécifique.
À la place de l'annonce, l'utilisateur verra une boîte grise avec le message Annonce supprimée, généralement accompagné d'un lien Détails expliquant que l'annonce utilisait 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 que celle-ci répond à l'un des critères suivants, elle sera déchargée :
- Utilisation du réseau : l'annonce utilise plus de quatre mégaoctets de bande passante réseau.
- 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 frame 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 publicitaires sont plus susceptibles que d'autres de déclencher ces interventions. Voici quelques causes courantes :
- Contenu multimédia non compressé : chargement d'images extrêmement volumineuses et mal compressées.
- JavaScript lourd : exécution d'opérations complexes, comme 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 immédiatement des mesures 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 boîte grise avec le message Annonce supprimée. Si l'utilisateur clique sur Détails dans le conteneur, une explication spécifique s'affiche.
Expérience des développeurs
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 frame d'annonce lui-même et à ses frames 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 signalement. Les rapports d'intervention sont désormais envoyés au frame d'intégration (le parent du frame d'annonce racine) en plus du frame d'annonce lui-même. Les rapports envoyés au frame d'intégration incluent l'ID du frame enfant et l'URL du frame 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 frame d'intégration recevra un rapport similaire, adressé à l'URL du frame d'intégration, mais le message contiendra en plus l'ID du frame enfant et l'URL spécifique du frame 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 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 du 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 "Annonces lourdes", tenez compte des bonnes pratiques suivantes :
- Exiger une interaction de l'utilisateur pour les contenus lourds : 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 lancer la lecture) avant de charger des assets volumineux.
- Optimisez 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 interagisse.
- Vérifiez 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 peuvent occuper le thread principal pendant de longues périodes.
- Surveillez les frames 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-frames tiers, leur utilisation de ressources est comptabilisée dans votre limite.
- Isoler le contenu non publicitaire : séparez les frames de contenu non publicitaire dans différents domaines ou selon des schémas reconnaissables qui ne sont pas susceptibles d'être considérés comme des domaines publicitaires par les règles du fournisseur de listes de filtres.
Comment déboguer et diagnostiquer la cause d'une intervention ?
Pour résoudre efficacement les problèmes liés aux 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 auditer 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 identifie le contenu comme une annonce en comparant les demandes de ressources à une liste de filtres. La logique de détection s'applique au contenu des iFrames. Le frame de page principal n'est jamais considéré comme lié à une annonce, même s'il contient des scripts d'annonces. 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 frame. Par exemple, un lecteur vidéo chargé dans un iFrame tagué comme 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 bien détecté votre contenu comme une annonce à l'aide des outils de développement Chrome.
- Mise en surbrillance des frames d'annonces : dans le panneau "Rendering" (Rendu), sélectionnez Highlight Ad Frames (Mettre en surbrillance les frames d'annonces). Les frames d'annonces détectés sont alors mis en surbrillance en rouge à l'écran.
- Annotation d'élément : dans le panneau "Éléments", les iframes d'annonces détectées affichent une annotation d'annonce à côté de la balise d'ouverture
<iframe>. - Activité réseau : dans le panneau "Réseau", filtrez les requêtes en fonction d'un booléen
Is ad-related. - État de l'annonce : dans le panneau "Application", sous la section Frames (Frames), les frames tagués avec des annonces incluent un attribut
Ad Status.
Comment diagnostiquer la cause d'une intervention ?
Chrome fournit des outils permettant d'auditer et d'améliorer la qualité et les performances des pages Web. Exécutez Lighthouse dans les outils pour les développeurs Chrome afin d'obtenir des rapports sur les performances de votre page. Vous pouvez également consulter la collection web.dev/fast et en savoir plus sur les statistiques Web.
Utilisation du réseau
Ouvrez le panneau 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 de chargements répétés.
La valeur transférée en bas de la page indique le montant transféré pour l'ensemble de la page. Pour limiter les requêtes à celles liées à l'annonce, utilisez le champ de saisie Filtrer en haut de la page.
Si vous trouvez la demande initiale pour l'annonce (par exemple, la source de l'iFrame), utilisez l'onglet "Initiateur" de la demande pour afficher toutes les demandes 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 images et les vidéos qui n'ont pas été optimisées sont souvent en cause.
De plus, le tri par nom peut être un bon moyen de repérer les demandes répétées. Il peut s'agir d'une seule ressource volumineuse qui déclenche l'intervention, mais aussi d'un grand nombre de requêtes répétées qui dépassent progressivement la limite.
Utilisation du processeur
Le panneau Performances des outils de développement vous aidera à diagnostiquer les problèmes d'utilisation du processeur. Ouvrez 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 les appareils peu puissants que sur les machines de développement haut de gamme.
Cliquez ensuite sur le bouton Enregistrer pour commencer à enregistrer l'activité. Vous pouvez tester différentes durées et différents moments d'enregistrement, car le chargement d'une trace longue peut prendre un certain temps. Une fois l'enregistrement chargé, vous pouvez utiliser la timeline en haut de l'écran pour sélectionner une partie de l'enregistrement. Concentrez-vous sur les zones du graphique en jaune, violet ou vert uni, qui représentent le script, le rendu et la peinture.
Explorez les onglets De bas en haut, Arborescence des appels et Journal des événements en bas de l'écran. Trier ces colonnes par Temps propre et 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é tagué comme tel, envisagez de modifier le code pour éviter de correspondre aux règles de filtrage ou contactez directement les responsables de la EasyList pour modifier les règles de filtrage. N'oubliez pas que l'intervention sur les annonces lourdes n'a pas d'incidence sur les frames avec geste de l'utilisateur. Vous pouvez donc exclure les vidéos en exigeant de cliquer sur un bouton de lecture avant de charger le contenu. Si l'EasyList ne correspond pas à votre contenu et que Chrome l'a classé à tort comme lié à des annonces, vous pouvez signaler un problème à Chrome à l'aide de ce modèle. Lorsque vous signalez un problème, incluez une capture d'écran du rapport d'intervention et un exemple d'URL permettant de reproduire le problème.