Intent to Implement: Web Lifecycle - to enable system initiated Discarding & Stopping
Shubhie Panicker
Contact emails
pani...@chromium.org, fme...@chromium.org, oj...@chromium.org
Explainer
https://github.com/spanicker/web-lifecycle/blob/master/README.md
Discourse thread:
Design doc/Spec
(Will update thread when design docs are ready)
Summary
We would like to propose a Lifecycle for Web Apps to enable system initiated termination (Discarding) and CPU suspension (Stopping).
Motivation
With large numbers of web apps (and tabs) running, critical resources such as memory, CPU, battery, network etc easily get oversubscribed, leading to a bad end user experience. Application lifecycle is a key way that modern OS’ manage resources. On Android, iOS and more recent Windows versions, apps can be started and stopped at will by the platform. This lets the platform streamline and re-allocate resources where they best benefit the user.
To fill this gap in the web platform, it is important to create the right incentive structure for web developers, and allow the system to proactively reallocate resources and avoid getting into extreme resource situations. For a platform to support application lifecycle, it needs to:
provide developers with signals about transitions between the lifecycle states
provide lifecycle-compatible APIs that allow key capabilities to work even when the app is backgrounded or stopped.
This proposal defines what the lifecycle of a web page is and adds necessary extensions to enable supporting two important system interventions necessary for resource re-allocation:
Tab Discarding - for memory saving
CPU Stopping - for improving performance of foreground app, and saving data and battery
Risks
Interop risk: medium.
The proposal explicitly attempts to minimize the interop risk. For instance, we reuse existing callbacks (pagehide, pageshow) which already exist in browsers today, and have tried to minimize the implementation work for browsers.
Compat risk: high.
Tab Discarding and CPU Stopping will cause breakage for some types of web apps that need to run in the background. However we plan to enable them to opt-out completely. As new APIs are made available to fill in the gaps, we will gradually remove the opt-outs.
This proposal has been discussed with Edge, Safari and Firefox as Web Perf WG F2F in June, and subsequently in public-web-perf meeting (and in ongoing private threads).
It has also been discussed with developers (and analytics) such as Facebook, Akamai, AMP, Google Docs etc.
Overall the sentiment is positive. Browser vendors and developers are onboard that this proposal is a positive change for the web platform; there is agreement that browsers should have autonomy to move apps to DISCARDED (Tab discarding) and STOPPED (CPU suspension) lifecycle states and web apps should receive clear signals when these lifecycle state transitions occur.
Ergonomics
Are there any other platform APIs this feature will frequently be used in tandem with?
Yes, it will used along with other existing lifecycle APIs such as unload, beforeunload, load, pagehide, pageshow, pagevisibility (hidden / visible) etc.
Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?
No, quite the contrary.
Activation
Will it be challenging for developers to take advantage of this feature immediately, as-is?
No.
Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?
Yes, it would benefit from significant documentation and outreach.
Debuggability
The events that fire when Discarding / Stopping can be simulated and tested against.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5644602711212032
Requesting approval to ship?
No.
Rick Byers
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7ODi9Wdxj7M6d_imuFFxg22ba5nFiSB-zEd1o26VQfZNx2dQ%40mail.gmail.com.
Kentaro Hara
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-_0bSFYfcKVC_xc%3DWAG4Ly0awwNNmqLT38tUoZ27WaLQ%40mail.gmail.com.