Background tabs & offscreen frames

Background tabs contribute almost a third to average browser power usage, thereby shortening battery life. In many cases, work that is being done in the background is unnecessary for providing the desired user experience. For example, before Intersection Observer API, it was common practice to use setInterval regularly to check if an element is visible by comparing its boundaries with the viewport. This frequently continued even when the tab was backgrounded.

Chrome wants to protect user from this by ensuring that only relevant work in done in background. This document discusses long-term vision and future plans. An overview of current Chrome policies around background tabs can be found here.

Our vision for background tabs

Our vision for the web ecosystem is to be able to suspend background tabs completely. This will result not only in significant power usage improvements, but also will save memory — Chrome will be able to optimize and purge memory knowing that the main thread is suspended and DOM interactions are not possible until page is foregrounded again.

But Chrome is committed to the web as an application platform and believes that web developers should be able to continue to provide all varieties of user experiences. Some of them require a background tab at the moment, such as playing audio in the background.

The work is underway on a set of APIs that developers will be able to use to specify which work needs to be done in the background, similar to what’s possible on Android and iOS. Service Workers will take the central place in this, with their capabilities enhanced by new features like being able to play audio, update page title & favicon, silent push notifications, and more. Note that we are not planning to throttle service workers because they are already active only when needed by design.In M57, Chrome only throttles DOM timers (set via setInterval and setTimeout) in background tabs and offscreen cross-origin iframes. Find more details here although note that the plans are subject to change based on developer feedback.

Future plans

Below is our sketch of the steps we’ll take in Chrome to suspend background tabs completely.

Our vision for the web ecosystem is to be able to suspend background tabs completely over the next few years. Later steps are subject to change as we learn about real-world compatibility constraints from each incremental step.

Explicit opt-outs (~Q2 2017, when FeaturePolicy ships)

While some of APIs for background work are missing, applications should be able to opt-out via FeaturePolicy from some forms of aggressive throttling.

Suspend all tasks on mobile (~Q2 2017)

Currently all background timers are suspended on mobile after 5 minutes. All tasks should be suspended to improve battery and data usage guarantees.

Throttling non-timer tasks (~Q2 2017)

Currently Chrome throttles only timer tasks.Loading tasks are not throttled to avoid regressing load time in background tabs. We plan to explore ways of throttling loading tasks as well that maintain the ability for pages to load efficiently in background tabs.

Budget-based throttling for offscreen frames (~Q3 2017)

Timers in cross-origin offscreen frames are limited to running once per second. Chrome will additionally extend budget-based throttling to offscreen frames.

Throttling web workers (~2018)

We are currently instrumenting web workers to better understand their CPU usage and power impact. We consider throttling web workers as well, being thoughtful about minimizing broken content.

Suspend all background tabs (~2018)

Fully pause a tab in the background after N minutes unless a web developer states that the tab should continue to run via an explicit opt-out.

Remove opt-outs (~2020+)

Remove the opt-out and pause all pages. We’ll be able to do this once we’ve (1) ensured that the web platform provides the APIs needed for major use cases and (2) given developers a sufficient deprecation period.