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
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.
--
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.
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.
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.
--
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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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.
--
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.
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
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.
--
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.
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
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-j3iwF%3DHydRdVyt7-xYC3V9H3SMgsaZyfMaCc5RvXSOQ%40mail.gmail.com.
Question: is there a mechanism for ad creators to test whether their ad meets the criteria offline before starting to serve it?
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?
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!
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALW6VLxG3dz094-YuSvDGq0x0yGUC3Qg-J2iMiozBWax3fN2AA%40mail.gmail.com.
11.09.2020, 21:24, "John Delaney" <john...@chromium.org>:
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
same we noticed on network usage also. I already created one more ticket here
Do you still expect to be at 100% activation before the 17th of November?
Could you share some details on when exactly it will be and how fast it will increase?