Chrome Heavy Ad Intervention: 4 MB Limit and Banners

Chrome removes an ad that the user has not interacted with when it uses more than four megabytes of network bandwidth, uses the main thread for more than 15 seconds in any 30-second window, or uses the main thread for more than 60 seconds in total. The Chrome heavy ads intervention page (Opens in a new tab) lists these three limits. If you build banners for an online chess coaching business, or run a site where ads keep disappearing, the fix is to cut file weight and CPU work.

How the intervention works

Chrome sets resource limits for ads and unloads an ad that exceeds them. The aim is to stop one ad from draining a visitor's device, data plan and battery. The intervention applies to the ad frame, and the rest of the publisher's page stays in place.

Example scenario: An online chess coaching business runs a banner for a beginner course on a hobby site. The banner autoloads a large lesson preview video and runs a looping board animation. On a low-powered phone the ad frame is replaced by a gray box. The coaching business has spent budget, and the visitor never saw the ad.

Three limits and their conditions

Table: Chrome heavy ad thresholds

Applicable conditions

• The criteria apply to ads that the user has not interacted with.
• If a user clicks or taps the ad, the resource limits no longer apply.
• All resources used by any descendant iframes of the ad frame count against the limits.

The iframe rule matters. If your banner embeds a third-party measurement frame or a video player, everything it downloads and runs is counted against your ad. Do not judge the limit by looking at your own file alone.

Chrome and Google pages can change, so verify the numbers on the current pages before delivery.

Decision table: symptom to probable threshold

Practical suggestion: start with the symptom. The table is a first screening order built from the three Chrome limits and the interaction exception; a measurement in developer tools gives the real diagnosis.

Decision table: symptom, likely threshold and first check

Decision rule: if the symptom points to the network threshold, cut video and image weight first. If it points to a CPU threshold, limit the animation first. If it is unclear, take all three measurements together.

The gray box: a removed ad on screen

The ad is unloaded and replaced by a gray box with an Ad removed message, with a Details link. The visitor sees an empty box where the ad was. For a publisher that means a gap in the layout and lost ad revenue. For an advertiser it means paying for an ad nobody saw.

Who carries the problem

Because the intervention happens in the browser, Chrome can remove an ad even when the ad platform accepted it. Responsibility is shared. The designer lightens the file, the advertiser asks for a light package, and the publisher watches the reports and states the thresholds in its spec.

Reproducing the intervention in developer tools

The Chrome page suggests enabling network and CPU throttling in the Performance panel and checking the Disable cache option for consistent results. It adds that DevTools may not always display timing information if the frame has already been unloaded. If you use the interface in another language, the labels may look different.

1. Open the page that holds the banner and start DevTools.
2. Turn on network and CPU throttling in the Performance panel.
3. Select Disable cache.
4. Reload and watch the total data the ad downloads and its main-thread time.
5. If the ad is removed, note when it happened and which resources had loaded by then.

Locating the heavy files

The Chrome page recommends disabling the cache for consistent results. Practical suggestion: sort the requests by size in the network panel and focus on the largest five. The sorting shows which files carry the weight; if the first measurement surprises you, trust the measurement.

Table: weight source and where to look

Duplicate requests

Many small requests can add up past the limit. The same resource requested several times, measurement calls that repeat and small uncached files belong in this group. Group requests by domain in the network panel and look for ways to reduce their number.

Cutting banner file weight

Platform limits also favor light files. The Google Ads uploaded display ads specifications (Opens in a new tab) list 150 KB for image ads, 600 KB for HTML5 ads and no more than 40 files in a ZIP. These limits sit far under the Chrome network threshold, so a package that respects them stays well clear of the 4 MB line, unless the ad fetches more data while it runs.

Image weight

Practical suggestion: crop images to the target size, avoid uploading higher resolution than the banner needs and compress. Use plain color for flat areas instead of an image. Load a repeated image once and reuse it.

Video weight

The Chrome page advises avoiding the automatic loading of large video files and using lightweight placeholders until the user engages. Heavy content tied to user interaction is another option, because the limits stop applying once the user interacts with the ad. Practical suggestion: start the banner with a single still frame and load the lesson preview only after a click.

Fonts and script libraries

Include only the font weights you use. Evaluate animation libraries one by one. The Chrome page recommends auditing CPU use to find main-thread bottlenecks, but it does not name any particular library as heavy.

Pixels and sub-frames from third parties

The Chrome page notes that third-party pixels and sub-frames count against your limits. Every measurement pixel you add to a banner increases network use and main-thread time. Practical suggestion: count the pixels and keep only the ones you need. For the page-level effect of third-party code, see third-party scripts performance audit.

Lowering CPU use

A banner that stays under the network threshold can still hit the CPU threshold. The Chrome page recommends auditing CPU use to find main-thread bottlenecks. Continuous animation, layout work repeated on every frame and heavy calculation all fill the budget.

Stop endless work

Practical suggestion: stop the animation after a set time, design it without a loop and leave no background timer running. The Google Ads page already requires that animations stop after 30 seconds, which also limits CPU time.

Allow for weaker devices

According to the Chrome page, CPU interventions are far more likely to trigger on lower-powered devices than on high-end development machines. A banner that runs fine on the designer's computer can still be removed on a visitor's phone. Turn on CPU throttling during testing.

Choosing the animation to keep

Practical suggestion: test each animation with three questions. Does it carry the message? Does it stop after a set time? Does it put measurable load on the main thread? An animation that cannot answer yes to all three comes out.

Example scenario: the chess coaching business removes the endlessly spinning knight icon behind the headline and keeps a single entrance move on the call to action button.

Which fix to try first

Practical suggestion: order the measures by cost and effect.

1. Cut image and video weight first; it is the easiest step to start with.
2. Then reduce third-party pixels and sub-frames.
3. Then limit the animation and remove the loop.
4. Finally, profile the main thread to find bottlenecks.

Second test on a weak device

After each step, repeat the low-powered profile test. Confirm that a measure worked with test results and not only with the count of removal reports.

The chess banner, fixed step by step

Example scenario: The first version of the chess coaching banner has four parts: a lesson preview video, a board photograph, two font families and a measurement pixel. The publisher's reports show it being removed. The business works through the parts one at a time.

Table: lightening plan

The order matters. The video is the largest network item, so it comes first. Image size and fonts follow. Stopping the animation targets the CPU threshold and not the network one. After each action, repeat the test with CPU throttling and the cache disabled.

Pre-launch verification

Run three checks before the lightened banner goes live. First, measure the total data the running ad downloads and compare it with the platform limits. Second, record main-thread activity and look for a bottleneck while the animation plays. Third, open the page with a low-powered device profile and confirm the ad stays in place. If any one check fails, the banner does not launch.

Sign-off on version two

Example scenario: the chess coaching business compares both versions under the same conditions. Every check must pass for acceptance.

Table: version one against version two

Decision rule: if one check fails, the version does not launch, the note is updated and the test runs again. Base the decision on measurements alone, and write the version number, test conditions and result in the hand-back note.

Reports through the Reporting API and pagehide

The Chrome page says Chrome generates an intervention report with the Reporting API that tells you exactly what happened. Reports are now sent to the embedding frame as well as to the ad frame. A pagehide handler is recommended so the report goes out before the frame unloads.

This gives a publisher a direct way to see which ad frames were removed on its page. Building the reporting setup is a developer task. Third-party ad providers handle reports for their own cross-site ads, and a publisher may not reach all of them directly.

A publisher monitoring routine

Practical suggestion: set up three steps.

Table: publisher monitoring steps

Example scenario: The hobby site sees the chess coaching banner among the removed ads. It matches the creative code and sends it to the business. The business replaces the video with a still frame and limits the animation. The new version goes live and no removal report arrives in its first week.

Decision rule: owner of a removed ad

1. If the weight comes from the ad's own files, the designer lightens it.
2. If the weight comes from an embedded third-party frame, the advertiser removes the frame or asks the provider for a lighter version, because sub-frame resources count against the ad.
3. If a removed ad matches no creative code, the publisher serves the ads one at a time on a test page to find it.
4. A corrected package goes live under an increased version number, not the old one.

Putting the thresholds into the publisher spec

If a publisher tells advertisers the thresholds up front, lighter packages arrive. Practical suggestion: list the platform limit and the browser threshold on separate lines in the spec. The platform limit describes rejection at delivery. The browser threshold describes the risk of removal after launch.

Table: lines to add to the spec

The rest of a spec, such as formats, HTTPS, audio and motion, belongs to a separate guide; the focus here stays on weight and CPU. The design advice in banner ad design tips supports the same lightweight goal.

Return note template

When a lightened package returns to the publisher, a short note filled with the same fields saves repeated questions.

• Creative code, banner size and version number
• Total data the running ad downloaded, with the cache disabled and network and CPU throttling on
• The second the animation ends
• List of sub-frames and measurement pixels
• The placeholder frame shown first and the moment the video loads
• Whether the ad stayed in place on a low-powered profile
• What changed since the previous version

Example scenario: the chess coaching business sends version two with this note: the lesson preview loads after a click, the board animation stops after a few seconds, one measurement pixel is gone and the ad stayed in place on the low-powered profile.

Handoff checklist for designers

• Was the total data downloaded measured on the running ad?
• Are sub-frames and third-party pixels included in the measurement?
• Does the video start as a placeholder frame and load only after a click?
• Is the animation free of loops and does it stop after a set time?
• Was the test run with CPU throttling?
• Was the measurement repeated with the cache disabled?
• Is the package inside the platform limits: 150 KB for image ads, 600 KB for HTML5?

Checklist for the first week live

• Do intervention reports reach the reporting endpoint?
• Has every removed ad been matched to a creative code?
• Is the live version number the one that was approved?
• Does any page show an empty gray box where the ad should be?
• Were impression counts read together with the removal reports?

Pre-campaign test day

If the intervention is discovered after launch, the budget is already spent. Plan a test day before launch and fix the roles and outputs in advance.

1. The designer delivers the final package with a weight measurement.
2. The publisher runs the package on a test page and opens it with a low-powered device profile.
3. If the ad stays in place, the launch is approved; if it is removed, the time of removal and the resources loaded by then are recorded.
4. The advertiser lightens the package from the notes and the test repeats.
5. The approved version goes live with its version number.

Ad weight against page speed

A removed ad is not only an advertiser problem; it also concerns the publisher's page performance, since a heavy ad slows the page down. For that balance from the publisher's side, see ads and Core Web Vitals: the publisher balance. To learn how to measure the banner once it is live, read measuring banner ad performance.

Measurement is affected too. A removed ad may have been counted as an impression while the visitor never saw it, so the impression count in a report can differ from true visibility. Watching removal reports gives you a data source that explains the difference.

Confusions to avoid

Platform sign-off versus the Chrome intervention

A platform accepting an ad does not mean Chrome will keep it. They are separate rules.

File size versus CPU time

A small file can still cross the CPU threshold if it does heavy calculation. The thresholds are independent.

Limits relaxing after interaction

The limits lift when the user clicks, but that does not make it fine to load heavy content before the click. Load it after the interaction and the limit does not apply.

Taking LEAN for a threshold

The IAB Tech Lab LEAN page (Opens in a new tab) describes the Lightweight ads principle as one of the most critical for user experience, but it gives no numeric file limit. The page also says IAB Tech Lab has stopped work on LEAN Scoring and LEAN Seal while the principles still apply.

Treating a missing report as clean

The Chrome page says the intervention report is generated through the Reporting API, and building the reporting setup is a developer task. Without that setup no report arrives, so silence does not prove that nothing was removed. Reports for third-party cross-site ads are a separate conversation with each provider.

Signing off on one measurement

According to the Chrome page, CPU interventions are far more likely to trigger on lower-powered devices. One passing run on a strong computer is therefore weak evidence. Practical suggestion: tie approval to a repeated measurement on a low-powered profile with the cache disabled.

Frequently Asked Questions

What replaces a removed ad?

The ad is unloaded and replaced by a gray box with an Ad removed message, with a Details link.

Which limits make Chrome remove an ad?

According to the Chrome page, an ad the user has not interacted with is removed if it uses more than 4 MB of network bandwidth, uses the main thread for more than 15 seconds in any 30-second window, or uses the main thread for more than 60 seconds in total.

Are sub-frame resources counted?

Yes. The Chrome page says all resources used by any descendant iframes of the ad frame count against the limits.

How can I reproduce the intervention?

The Chrome page suggests enabling network and CPU throttling in the Performance panel and checking Disable cache. DevTools may not always show timing information if the frame has already been unloaded.

Are the limits lifted after a click?

Yes. The Chrome page says that once a user clicks or taps the ad, the resource limits no longer apply.

Can a publisher watch for removals?

According to the Chrome page, intervention reports are produced through the Reporting API and are now sent to the embedding frame as well as the ad frame. A pagehide handler is recommended so the report is sent before the frame unloads.

Conclusion

Chrome's heavy ad intervention applies three limits to ads without user interaction: 4 MB of network bandwidth, 15 seconds of main-thread time in any 30-second window and 60 seconds in total. Sub-frame resources count too. When you build banners, lighten images and video, cut third-party pixels, limit the animation and test on a low-powered device profile.

If you publish, watch the intervention reports and match them to creative codes. To plan a campaign whose creative arrives light and at the right size, you can explore ad spaces.