Intent to Ship: Heavy Ad Intervention

1246 views
Skip to first unread message

John Delaney

unread,
Sep 1, 2020, 10:38:36 AMSep 1
to blink-dev

Contact emails

john...@chromium.org, jka...@chromium.org, m...@chromium.org


Explainer

https://github.com/johnivdel/heavy-ad-intervention/blob/master/README.md


Spec

No spec.


No TAG review requested as this does not add/alter any API surfaces.


Summary

Chrome will unload ad iframes that use an egregious amount of CPU or network bandwidth. Iframes are labeled as ads heuristically by AdTagging. Limits for this intervention are defined in the explainer


This intervention only targets the heaviest .3% of advertisements as seen by Chrome. More info can be found in the chromium blog post.


Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/pZq73q_Mc-c/chp8ssUKBgAJ


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

The feature is not supported on Android Webview, as Chrome’s AdTagging feature does not work within WebViews.


All other platforms are supported.


Demo link

https://heavy-ads.glitch.me


Debuggability

Heavy ads integrates with the DevTools issue panel to notify developers when a heavy ad is on their site. <iframe> elements that Chrome tags as ads are surfaced in the devtools elements panel(in Chrome 86+) to help debug what is affected. We also expose flags that remove any non-determinism in the thresholds to simplify testing. More info can be found on the developers blog post.


Risks

Interop: No plans to standardize this behavior.

Signals from other implementations (Gecko, WebKit): N/A


We have received positive feedback from Edge.


Compat: We have come across a few false positives, where site content was accidentally misclassified. In cases we have seen, this has been due to sites loading content with their advertiser’s script.


There has been some observed breakage where an in-stream video ad has been unloaded, causing the video player to break.


We have been working with sites to resolve these issues, but due to the rarity of the intervention, these are not considered high impact. The intervention is present on .18% of page loads. The expected number of interventions which break the page are a small fraction of that (based on bug reports and spot checks).


Intervention Guidelines

Predictability

The mechanism and thresholds are well defined and predictable. The noise added to thresholds is purely additive and only relaxes intervention constraints.

Avoidability

Sites can modify their ads to be within limits or acquire a user gesture to avoid intervention entirely.

Transparency

Intervention reports are sent via the Reporting API to notify advertisers that their ads are affected.

Data-driven

Experiment data was positive, showing the ~20% reductions in ad resource usage covered in the blog post, and positive performance gains on mobile.


Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

No, as there are no plans to standardize behavior, this is tested separately.


Entry on the feature dashboard

https://www.chromestatus.com/feature/4800491902992384


Rollout Info

As this is a significant intervention, we intend to roll it out gradually throughout the month of September in Chrome M85. We will monitor any breakage or unintended effects of the intervention as we ramp up.


Domenic Denicola

unread,
Sep 1, 2020, 11:24:30 AMSep 1
to John Delaney, blink-dev
Hi John, this is an exciting intervention!

However, like all other interventions, it would benefit from standardization. In particular, what you'd want here is a carveout in the HTML Standard which allows unloading iframes at implementation-defined points, and details what exactly that unloading means. (Does it fire any events? Does the <iframe> element still exist in the DOM? What happens if you try to access contentWindow? Is there any observable difference from the embedding page? If you unload a same-origin iframe in this way, can the embedding page still access its DOM? Etc.)

You can see previous intervention standardization work along these lines in, for example, https://github.com/whatwg/html/pull/1400.

Domenic Denicola

unread,
Sep 1, 2020, 5:19:21 PMSep 1
to John Delaney, blink-dev
Update: John has quickly worked to put together a specification pull request for this behavior, at https://github.com/whatwg/html/pull/5885. Things are looking great and on track for a successful standardization. I'm also hopeful we'll use this opportunity to get engagement from other browsers which I believe perform similar not-yet-specced interventions.

Yoav Weiss

unread,
Sep 2, 2020, 2:41:44 AMSep 2
to Domenic Denicola, John Delaney, blink-dev
Thanks John and Domenic!!

From the PR, and the fact that at least some dismissal events are fired, this seems web exposed (and hence subject to the Blink process).

John - you mentioned this being applied on 0.18% of pages. Can you estimate what %age of those actually see breakage?
Are we planning a slow rollout that would enable us to fix those cases before they reach a large audience? Is there something developers need to change to avoid breakage, or is it something that detection changes on the browser side would resolve?


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MN2PR13MB361388781B57750CC1EC511CDF2E0%40MN2PR13MB3613.namprd13.prod.outlook.com.

John Delaney

unread,
Sep 2, 2020, 2:39:09 PMSep 2
to blink-dev, d...@domenic.me, john...@chromium.org

Many thanks to Domenic for help with getting that PR ready!


Can you estimate what %age of those actually see breakage?

Not holistically. We manually reviewed ~100 sites with the highest intervention rates and did not come across broken non-ad content.


In our finch trial, we did not observe significant changes in page reloads that would indicate broken site experiences.


Three bugs have been filed showing site breakage:

  - misclassified content [1, 2]

  - broken video content due to acquiring a user gesture outside of an ad iframe


Anecdotally these issues seem to be fairly isolated. Generally, Chrome cannot distinguish between site content that is loaded by advertising javascript from ad content. So frames that share regular content and ad content are at risk of being unloaded incorrectly. For instance, this might happen with instream video ads in frames.


It's worth noting that during experimentation we did make changes to our AdTagging heuristic which fixed a large amount of false-positives we found in initial analysis. So while we have confidence in the current state of the intervention, it is not easily quantifiable.


Are we planning a slow rollout that would enable us to fix those cases before they reach a large audience?

Yes, as noted at the bottom of the I2S, we plan to rollout over the month of September and respond to new reports/breakage accordingly.


Is there something developers need to change to avoid breakage, or is it something that detection changes on the browser side would resolve?

Fixing intentional(heavy ads) and unintentional(misclassified content, etc.) breakage is mostly on the developers side. We have provided developer guidance (generally either acquire a user gesture or separate ad content from other content frames). For unintentional breakage we have observed, detection changes would not be able to fix false-positives without allowing a disproportionate number of false-negatives.


That being said, we are continuously working on improving our AdTagging heuristic where possible as we learn new information.


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Yoav Weiss

unread,
Sep 2, 2020, 3:16:23 PMSep 2
to John Delaney, blink-dev, Domenic Denicola
That all sounds reasonable to me.
LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c4b99f00-c861-4084-ba3e-81c94d59d4c2o%40chromium.org.

sligh...@chromium.org

unread,
Sep 3, 2020, 3:29:54 PMSep 3
to blink-dev, john...@chromium.org, d...@domenic.me
LGTM2
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Chris Harrelson

unread,
Sep 3, 2020, 3:37:11 PMSep 3
to John Delaney, blink-dev
Question: is there a mechanism for ad creators to test whether their ad meets the criteria offline before starting to serve it?

On Tue, Sep 1, 2020 at 7:38 AM John Delaney <john...@chromium.org> wrote:

Contact emails

john...@chromium.org, jka...@chromium.org, m...@chromium.org


Explainer

https://github.com/johnivdel/heavy-ad-intervention/blob/master/README.md


Spec

No spec.


No TAG review requested as this does not add/alter any API surfaces.


Summary

Chrome will unload ad iframes that use an egregious amount of CPU or network bandwidth. Iframes are labeled as ads heuristically by AdTagging. Limits for this intervention are defined in the explainer


This intervention only targets the heaviest .3% of advertisements as seen by Chrome. More info can be found in the chromium blog post.


Link to “Intent to Prototype” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/pZq73q_Mc-c/chp8ssUKBgAJ


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

The feature is not supported on Android Webview, as Chrome’s AdTagging feature does not work within WebViews.


All other platforms are supported.


Demo link

https://heavy-ads.glitch.me


Debuggability

Heavy ads integrates with the DevTools issue panel to notify developers when a heavy ad is on their site. <iframe> elements that Chrome tags as ads are surfaced in the devtools elements panel(in Chrome 86+) to help debug what is affected. We also expose flags that remove any non-determinism in the thresholds to simplify testing. More info can be found on the developers blog post.


Risks

Interop: No plans to standardize this behavior.

Signals from other implementations (Gecko, WebKit): N/A


I don't think it's Not Applicable. Could you ask Gecko and WebKit their position on this intervention, as well as the proposed web-exposed spec behavior?
 

We have received positive feedback from Edge.


Compat: We have come across a few false positives, where site content was accidentally misclassified. In cases we have seen, this has been due to sites loading content with their advertiser’s script.


There has been some observed breakage where an in-stream video ad has been unloaded, causing the video player to break.


We have been working with sites to resolve these issues, but due to the rarity of the intervention, these are not considered high impact. The intervention is present on .18% of page loads. The expected number of interventions which break the page are a small fraction of that (based on bug reports and spot checks).


Intervention Guidelines

Predictability

The mechanism and thresholds are well defined and predictable. The noise added to thresholds is purely additive and only relaxes intervention constraints.

Avoidability

Sites can modify their ads to be within limits or acquire a user gesture to avoid intervention entirely.

Transparency

Intervention reports are sent via the Reporting API to notify advertisers that their ads are affected.

Data-driven

Experiment data was positive, showing the ~20% reductions in ad resource usage covered in the blog post, and positive performance gains on mobile.


Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

No, as there are no plans to standardize behavior, this is tested separately.


Entry on the feature dashboard

https://www.chromestatus.com/feature/4800491902992384


Rollout Info

As this is a significant intervention, we intend to roll it out gradually throughout the month of September in Chrome M85. We will monitor any breakage or unintended effects of the intervention as we ramp up.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b8c7262a-02df-42b0-b5a4-4dab548ae727o%40chromium.org.

Daniel Bratell

unread,
Sep 3, 2020, 3:46:12 PMSep 3
to Chris Harrelson, John Delaney, blink-dev

It might be important to see how close you are to the limit since "15 seconds of CPU usage" heavily depends on the CPU and load of the computer. If you are close to the limit under normal circumstance you will end up with randomly failing content (ads). Also, I think it can't hurt to encourage everyone to push to be as far away from the limit as possible.

/Daniel

John Delaney

unread,
Sep 3, 2020, 5:26:28 PMSep 3
to Daniel Bratell, Chris Harrelson, blink-dev
Question: is there a mechanism for ad creators to test whether their ad meets the criteria offline before starting to serve it?
The demo site [https://heavy-ads.glitch.me] allows devs to upload a creative to test out whether it would trigger the intervention. This simply loads the creative into a Chrome detected ad iframe and checks for the intervention to fire.

It's worth noting that we have received feedback from creative authoring platforms that they are intending to build out functionality to flag/reject heavy ads on their platform directly.

Regarding Daniel's point on seeing how close creatives are to the limit, that is a more difficult problem. In our dev-rel blog, we suggest that developers/authors use the Network & Performance panels in DevTools to investigate usage of their creatives directly.

A more automatic mechanism is not currently available. The CPU measurement that Chrome uses for the intervention is not web-exposed. The network usage of an ad is not easily calculated due to CORS restrictions on the ResourceTiming API. Specifically, transferSize of resources loaded by the ad is used for the intervention.

I don't think it's Not Applicable. Could you ask Gecko and WebKit their position on this intervention, as well as the proposed web-exposed spec behavior?
Yes, we will solicit feedback on the spec pull request & WICG/Interventions issue and update accordingly, thanks!

John Delaney

unread,
Sep 10, 2020, 11:40:34 AMSep 10
to Daniel Bratell, Chris Harrelson, blink-dev
I don't think it's Not Applicable. Could you ask Gecko and WebKit their position on this intervention, as well as the proposed web-exposed spec behavior?
Yes, we will solicit feedback on the spec pull request & WICG/Interventions issue and update accordingly, thanks!
Update: The requests for positions are on mozilla/standards-positions and webkit-dev,

Chris Harrelson

unread,
Sep 10, 2020, 11:48:29 AMSep 10
to John Delaney, Daniel Bratell, blink-dev

Marko Ivanovich

unread,
Sep 11, 2020, 2:10:19 PMSep 11
to blink-dev, blink-dev, john...@chromium.org
Hi!

Sorry if this is not the right place to post this question.

I've came across interesting behavior. There is ad frame, that notifies its parent about end of video ad. There might be more than one video ad, one after the other inside that frame, and when they all finish, JavaScript code inside that ad frame calls parent.postMessage, to inform parent that it has finished displaying ads.
Parent gets the message, destroys that frame and creates another frame with YouTube video. YouTube video frame gets marked as ad and if HeavyAdIntervetion is enabled, it get unloaded. It only happens if ad frame is not OOPIF. That is because, if frame is tagged as ad, but is not OOPIF, and it calls postMessage, creation of async task is registered within AdTracker. It then tags that AsyncTask as ad task, since postMessage is called from ad frame. When message handler gets called, AdTracker increases count of running async ad tasks and every frame creating from within message handler shall be tagged as ad. If ad frame is in OOPIF,  postMessage does not inform AdTracker about async task creation.

Main question: should we consider frames created from message handler ads, if messages are posted from ad code?

If yes, then:
1. What would be a good pattern for libraries providing mechanism to show ads in iframe, to inform parent page that it has finished, or anything?
2. What about difference between OOPIF and non OOPIF frames? How can this difference be justified? Or should this be fixed to work with OOPIFs too?

Thanks.

John Delaney

unread,
Sep 11, 2020, 3:24:41 PMSep 11
to Marko Ivanovich, blink-dev
Hi Marko,

This does look like an issue. Could you file a bug for this (feel free to copy/paste)? You can use this template so it gets routed correctly: crbug. We can follow up there, thanks for looking into this!

Марко Иванович

unread,
Sep 14, 2020, 11:29:25 AMSep 14
to John Delaney, blink-dev
Sorry, I've accidentally added 'a' at the end of link.
 
14.09.2020, 12:56, "Марко Иванович" <ivan...@yandex-team.ru>:
 
 
11.09.2020, 21:24, "John Delaney" <john...@chromium.org>:

shreyas ubale

unread,
Sep 16, 2020, 11:48:59 AMSep 16
to blink-dev, ivan...@yandex-team.ru, blink-dev, john...@chromium.org
Hello All!

After going through all threads, i am still confused by "15 seconds of cpu usage". is it per unit of time, if yes what unit, if not is it calculated during the whole lifecycle of the page ? Also is there any way of measuring cpu usage in seconds rather than the percentage that chrome task manager provides.

Regards
Shreyas

John Delaney

unread,
Sep 17, 2020, 12:51:45 PMSep 17
to shreyas ubale, blink-dev, ivan...@yandex-team.ru
Hi Shreyas,

The intervention uses the wall clock-time of main thread tasks to measure CPU. The 15 seconds of CPU usage limit is per 30 second sliding window. There is also a 30 second CPU limit scoped to the entire page load. This section of the explainer covers these limits:


You can use the Performance panel in Devtools to analyze the CPU usage of a page in a similar manner to the intervention (in wall clock time). More information can be found in our developers blog post here: 

Loic Chambard

unread,
Sep 22, 2020, 1:31:27 PMSep 22
to blink-dev, john...@chromium.org, blink-dev, ivan...@yandex-team.ru, shreyas ubale
Hi John,

Is the roll-out of Heavy Ad to all users still plan in September?
Could you share some details on how/when you plan to do it? That would help us a lot to prepare and monitor it.

Thanks a lot,
Loïc

vishwabandhu pachauri

unread,
Sep 23, 2020, 11:13:06 AMSep 23
to blink-dev, Loic Chambard, john...@chromium.org, blink-dev, ivan...@yandex-team.ru, shreyas ubale
Hi john,

Currently, we are doing analysis on production data and happy to share our observation here 

1. our few adunits which run only on desktop environment(has better CPU comparison to mobile device) getting offload signal around 1 to 3% due to CPU usage. we throttle the CPU by 6 suggested by you but still adunit doesn't offload and works perfectly. seeing that we have few inputs and suggestions. 

1. if adunit pass during rigorous testing suggested on blogs but still getting offload signal? what is the next steps to debugging and fixing such kind of issues. ideally we should prefer clear testing guidelines and steps which can assure that adunit work perfectly in production without getting offload signal.
2. it will be great, if we can have bench mark of % of offload signal which can come in production environment even adunit pass in all the test case suggested on article. it will help us community to justify their end users and clients in case they seen offload screen.  
3. please checked attached video of google.com, with given guideline that is also showing >85% of CPU usage with CPU throttling.. but without throttling it's showing <1%. it is happening on other website also. not sure if it's bug in dev tool. it's better to have clear testing guideline for testing.  
4. have we gathered any production data from other advertisers , ad network or partner to double sure that they are not getting any kind of false signal of offload events to be double sure that things are working as expected.  

  
same we noticed on network usage also. I already created one more ticket here 
sharing couple of example for testing example 1 example 2

please let me know if any thing missing which need to be considered during testing. 

we are fine to share more information from our side if you need to investigate this issue further like domain , environment details etc. please look into it and help us to resolve.

overall, we want to know how to justify those issues to end user and clients which are not able to captured in any testing. 
zoom_0.mp4

John Delaney

unread,
Sep 23, 2020, 3:35:47 PMSep 23
to vishwabandhu pachauri, blink-dev, Loic Chambard, ivan...@yandex-team.ru, shreyas ubale
Is the roll-out of Heavy Ad to all users still plan in September?
Could you share some details on how/when you plan to do it? That would help us a lot to prepare and monitor it.

Thanks a lot,
Loïc
Hi  Loïc,

The intervention rollout is still planned for September, and has started as of September 14th, after this Intent was approved. We plan to rollout over ~4 weeks to 100% of users, incrementally from the start date.

same we noticed on network usage also. I already created one more ticket here 
Hi  Vishwabandhu,

I responded on the crbug, and addressed the above questions there. I am happy to follow-up on the bug with any additional questions.



Loic Chambard

unread,
Oct 5, 2020, 6:36:33 AMOct 5
to blink-dev, john...@chromium.org, blink-dev, Loic Chambard, ivan...@yandex-team.ru, shreyas ubale, vbp...@gmail.com
Thanks for the details John.

We have not seen any increase in the volume of Heavy Ad Intervention since the 14th of September.
Could you share the % of users with the feature activated and the plan regarding the increase?
Is it still plan to be at 100% on the 15th of October?

Best,
Loïc

Loic Chambard

unread,
Oct 12, 2020, 4:57:32 AM (11 days ago) Oct 12
to blink-dev, Loic Chambard, john...@chromium.org, blink-dev, ivan...@yandex-team.ru, shreyas ubale, vbp...@gmail.com
Hi John,

sorry to ask again, but would you have an update on the rollout plan? Is it still scheduled for full release this week?
On our side, we haven't seen an increase in the number of Heavy Ad intervention yet.

Thanks a lot,
Loïc

John Delaney

unread,
Oct 13, 2020, 4:34:52 PM (10 days ago) Oct 13
to Loic Chambard, blink-dev, ivan...@yandex-team.ru, shreyas ubale, vbp...@gmail.com
Hi Loïc,

My apologies for the delay in responding to this.

Regarding the rollout for the intervention: we plan on finishing the rollout throughout Chrome 86 (https://chromiumdash.appspot.com/schedule), as we are proceeding very carefully.

Could you comment on how you are measuring the volume of interventions? 

One thing to note is that we send reports for warnings for users that do not have the intervention enabled. We would expect the total number of intervention reports with `id` == "HeavyAdIntervention" to be consistent. However the fraction of reports with the `message`: "Ad was removed because its network usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384" should increase in comparison to the warning message.

Thanks,
John

Loic Chambard

unread,
Oct 14, 2020, 8:55:38 AM (9 days ago) Oct 14
to blink-dev, john...@chromium.org, blink-dev, ivan...@yandex-team.ru, shreyas ubale, vbp...@gmail.com, Loic Chambard
Hi John,

Thanks for the response!

We are currently collecting every Heavy Ad Intervention (HAI) happening through our Teads player running on our publishers.
But we currently don't differentiate between Warnings and "real blocking". We'll really soon update our system to do so.

We thought that the warning+blocking was not activated yet on all Chrome users, hence we were expecting an increase of the total over the last weeks.
But thanks to your comment, we now know that we are already receiving the full volume of HAI, and that only the repartition of warning vs blocking will change.

volume HAI.png


Some extra questions:
  1. As you can see in the volume of HAI we are recording above, we reached the full volume in June with the release of Chrome 84. Can you confirm that HAI was fully released in that version and that only the repartition of Warning vs Blocking has changed since then?
  2. How do you plan the rollout throughout Chrome 86? Will it be a linear increase of the Blocking vs Warning until November the 17th (release date of Chrome 87)?

Thanks again,
Loïc

John Delaney

unread,
Oct 15, 2020, 4:04:55 PM (8 days ago) Oct 15
to Loic Chambard, blink-dev, ivan...@yandex-team.ru, shreyas ubale, vbp...@gmail.com
Thanks for the info, this looks great!

1. Yes, the Heavy Ad Intervention warning was enabled by default in Chrome 84+. And since full intervention rollout started, only the Warning / Blocking ratio has been adjusted.

2. We will gradually increase the ratio of blocking vs warning as we monitor the rollout throughout Chrome 86. We will post an update to blink-dev when the intervention is fully launched, but I cannot speak to when that specific date will be.
Reply all
Reply to author
Forward
0 new messages