Contact emailsfdo...@chromium.org, shas...@chromium.org
On a page that has been hidden and silent for >15 minutes, each agent can execute for 50ms per 5 minutes interval. After an agent has exhausted its execution budget, it is frozen until the beginning of the next 5 minutes interval, unless:
- It holds a Web Lock or an IndexedDB transaction which contends with another non-frozen page/worker.
- It captures from a microphone, camera or screen/window/tab.
- It has an RTCPeerConnection with an 'open' RTCDataChannel or a 'live' MediaStreamTrack.
- It uses Web USB, Web Bluetooth, Web HID or Web Serial.
- It received a message (postMessage) from another page/worker in the last 50ms.
A frozen agent may be unfrozen if it starts meeting one of these conditions (e.g. Web Lock held by a frozen agent is requested by another agent).
State transitions will happen as defined in the page lifecycle API.
This proposal is for desktop platforms. On Android, pages are frozen after 5 minutes in the background since M68 (https://chromestatus.com/feature/4639097628917760).
This is a first step towards "Efficient Background Tabs", which aims to eliminate negative impact on user experience from background tabs.
Interoperability and Compatibility
It's fine if a browser does not freeze background pages.
However, if a browser does freeze background pages, complying with the Page Lifecycle spec lets pages handle the state transition consistently across browsers.Gecko
: Under consideration (https://github.com/mozilla/standards-positions/issues/87
: No signalWeb developers
: No signals In the past, Web developers expressed concerns about background page freezing, because it made it difficult to implement background functionality that users care about in a reliable way (e.g. notification for calendar event). Heuristics in this *conservative* page freezing proposal should prevent breakages that were reported in past proposals (e.g. 50ms of execution time per 5 minutes is sufficient to execute a timer which shows a calendar event notification). Additionally, we will listen to Web developers feedback on multiple channels (crbug, blink-dev, stack overflow, twitter, github) and make adjustments to heuristics (or refer Web developers to well-established best practices) if we find that background functionality that users care about is broken.Other signals
: - Chrome on Android freezes background tabs after 5 minutes https://groups.google.com/a/chromium.org/g/blink-dev/c/NKtuFxLsKgo/m/brL3bfS5CAAJ
- Chrome on desktop freezes pages before putting them in the BFCache. - Edge freezes background tabs after a configurable timeout https://www.microsoft.com/en-us/edge/features/sleeping-tabs-at-work?form=MT00D8
No Ergonomics Risks identified.
No special handling is required for browsers which don't freeze pages.
Freezing decisions are taken independently for each agent, to prevent an agent from learning about the execution time or features used by another agent.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
This proposal is for desktop only. It does not affect WebView.
DevTools > Application > Background Services will expose the frozen state of each agent and the underlying reasons. It will also provide a mechanism to override the frozen state.No
Flag nameconservative-page-freezing (not implemented yet)
Requires code in //chrome?False
Development will start in M116.
Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5158599457767424