There was an unexpected error authorizing you. Please try again.

Chrome Will Block Heavy Ads Soon: Get Your VAST Video Ads Ready

Solutions to Detect and Report Chrome Intervention; And New Ad Portfolio Guidance for Maintaining Lightweight Ads

Executive Summary

  • An upcoming Chrome browser update will block ad loads that surpass 4MB of network data usage, 15 seconds of CPU usage in a 30 second period, or 60 seconds of total CPU usage.
  • This impacts only a very small percentage of ads today (approximately 0.3%).
  • Video Ad SDKs should implement the Heavy Ad Intervention API to detect and report these interventions so that you can troubleshoot and adjust your ads for proper ad delivery.
  • The IAB Tech Lab’s New Ad Portfolio provides further guidance for developing  lightweight ads with the optimal user experience and device resourcing in mind.


Throughout September 2020, Chrome is planning a wide release of a new browser intervention, which will monitor ad iframes and may redirect them to an error page if resource usage exceeds certain thresholds. Video ads in particular may be vulnerable to this intervention, which will affect iframes which load more than 4 MB of data.

This intervention will not trigger on content which is not iframed (e.g. if the <video> element loads directly on the top page), or if the iframe has received some kind of user interaction (e.g. click-to-play). So, many Video Ad Serving Template (VAST) ads with media files larger than 4 MB may in fact be safe from removal due to the circumstances of how they’re played.

But how can ad servers know whether their ads with larger assets were in fact played successfully, particularly if they’re served programmatically? Chrome has provided an API to detect interventions as they happen, however it requires usage of JavaScript in the client. VAST does not inherently allow for JavaScript, and so it is up to players of VAST ads to provide this support.

SDK Best Practices: Detection and Reporting

Video Ad SDKs should implement Heavy Ad Intervention detection via the ReportingObserver API, as recommended in this Chrome blog post.

This code should be installed in any context where video ad content may be loaded. The handleHeavyAdIntervention method should do several things.

Attempt a graceful cleanup. If this is an instream ad, there may be a risk of content not resuming if ad playback stops unexpectedly. Note that, in the case that coordination with code outside of the iframe being unloaded is needed, a postMessage will still succeed, even when fired from inside the unload handler.

Propagate the intervention as an error. Any URIs provided via <Error> elements in the associated VAST should be triggered. Use of error code* 903 to indicate a HeavyAdIntervention occurred is recommended, so that interventions can be properly tracked and counted. Care should be taken in particular if these error pings are sent from within the same iframe that is being unloaded. In this case, use of the Fetch API with keepalive enabled is strongly recommended, to ensure these events are not lost or cancelled during unload.


But the best way to avoid resource usage thresholds is to build lightweight ads that respect the device’s resources and user experience. The IAB Tech Lab’s New Ad Portfolio provides guidance for lightweight ads to help creative developers build ads that complement fast loading pages. This guidance covers all video creative placements in non-video environments, e.g. video in-display advertisements, video-only creative in between text or image content popularly called out-stream, videos placed in feed or in between content lists. The guidance recommends the following:

Host Initiated Video Autoplay

  1. Max duration: 15 seconds.
  2. Max File size: 1.1 Mb.
  3. File quality: Recommended 24 fps minimum. For lower bandwidth (less than 2 mbps) 18 fps may be used.

For In-Stream Formats the Digital Video In-Stream Ad Format Guidelines (DVAFG) offers guidance on encoding ready-to-serve files recommending methods for achieving a target bitrate. When adhered to typically a file will end up being approximately 1.5 MB per 15 seconds at 1000 kbps bitrate, but this may vary depending on ad content.

For Non-Linear Ad Formats the DVAFG recommends:

  1. Max duration: 5-15 seconds
  2. Max file size: 100k for initial portion of the ad; viewer-initiated portion may be any size.

* Currently proposed, to be defined and added to VAST Error Codes Table in a future update to VAST.


Jon Guarino
Senior Software Engineer

Jon is a software engineer at Google working primarily on the Campaign Manager serving team. He has a passion for technology and design, and is happy to work with the IAB Tech Lab to help write robust standards that bring the industry forward.

Mike Midden
Director, Product Management
IAB Tech Lab