Handling Heavy Ad Interventions

Ads that consume a disproportionate amount of resources on a device negatively
impact the user’s experience—from the obvious effects of degrading performance
to less visible consequences such as draining the battery or eating up bandwidth
allowances. These ads range from the actively malicious, such as cryptocurrency
miners, through to genuine content with inadvertent bugs or performance issues.

Chrome is experimenting with setting limits on the resources an ad may use and
unloading that ad if the limits are exceeded. You can read
.

Heavy Ad criteria

An ad is considered heavy if the user has not interacted with it (for
example, has not tapped or clicked it) and it meets any of the following
criteria:

• Uses the main thread for more than 60 seconds in total


• Uses the main thread for more than 15 seconds in any 30 second window


• Uses more than 4 megabytes of network bandwidth

All resources used by any descendant iframes of the ad frame count against the
limits for intervening on that ad. It’s important to note that the main thread
time limits are not the same as elapsed time since loading the ad. The limits
are on how long the CPU takes to execute the ad's code.

Testing the intervention

You can test the new intervention in Chrome 84 and upwards.

• Enable chrome://flags/#enable-heavy-ad-intervention


• Disable chrome://flags/#heavy-ad-privacy-mitigations

Setting chrome://flags/#enable-heavy-ad-intervention to Enabled activates
the new behavior, but by default there is some noise and variability added to
the thresholds to protect user privacy. Setting
chrome://flags/#heavy-ad-privacy-mitigations to Disabled prevents this,
meaning the restrictions are applied deterministically, purely according to the
limits. This should make debugging and testing easier.

Note: Earlier versions of Chrome include the
#heavy-ad-privacy-mitigations-opt-out flag which should be set to Enabled
for testing.

When the intervention is triggered you should see the content in the iframe for
a heavy ad replaced with an Ad removed message. If you follow the included
Details link, you will see a message explaining: "This ad uses too many
resources for your device, so Chrome removed it."

You can see the intervention applied to sample content on
.
Consider building configurable thresholds directly into your authoring tools to
prevent poor performing ads escaping into the wild.

What happens when an ad is removed?

An intervention in Chrome is reported via the aptly named
to audit the overall performance of your
content. The resulting audits provide inline guidance on improvements. You can
also refer to the to test this with a
ready-made, ad-tagged iframe. You can use Chrome DevTools to validate content
has been tagged as an ad. In the Rendering panel (accessible via the three
dot ⋮ menu then More Tools > Rendering) select "Highlight Ad
Frames". If testing content in the top-level window or other context where it
is not tagged as an ad the intervention will not be triggered, but you can still
manually check against the thresholds.

Network usage

Bring up the Network panel in Chrome DevTools to see the overall network
activity for the ad. You will want to ensure the "Disable cache" option is
checked to get consistent results over repeated loads.

The transferred value at the bottom of the page will show you the amount
transferred for the entire page. Consider using the
.
Use the CPU dropdown to slow down the CPU as much as possible. The
interventions for CPU are far more likely to trigger on lower-powered devices
than high-end development machines.

Next, click the Record button to begin recording activity. You may want to
experiment with when and how long you record for, as a long trace can take quite
a while to load. Once the recording is loaded you can use the top timeline to
,

tabs at the bottom. Sorting those columns by Self Time and Total Time
can help identify bottlenecks in the code.

The associated source file is also linked there, so you can follow it through to
the Sources panel to examine the cost of each line.

Note: DevTools may not always display the timing information if the frame has
already been unloaded, so you may want to capture the traces with the ad
isolated or with the intervention disabled.

Common issues to look for here are
.
If non-ad content has been tagged, consider changing that code to avoid matching
the filtering rules. If you suspect an intervention has been incorrectly
applied, then you can
raise an issue via this template. Please
ensure you have captured an example of the intervention report and have a sample
URL to reproduce the issue.