1 of 23

A Lifecycle for the web

Web Perf F2F, Jun 20

Shubhie Panicker

2 of 23

Life & Death for a Web App

  • alive: visible in foreground
  • dead: user closes tab
  • dead: user navigates away
  • dead: OOM, browser crash, out of battery ....

​

What about apps in the background?

3 of 23

App in Background: Dead or Alive?

  • How long is it alive?
  • No well defined lifecycle
  • On mobile: quickly stop execution in background
    • OS may kill it under memory pressure
  • On desktop: alive indefinitely
    • OS or Chrome may kill it under pressure

4 of 23

Why Bother?

5 of 23

Too Many Tabs. Limited Resources.

  • Limited: memory, CPU, battery
    • Yes, even on desktop
  • More windows & tabs open than available memory
  • Hurts the end user experience
  • Background tabs hurt foreground experience
  • What is okay to do in background, anyway?

6 of 23

Ideally ...

  • browser will proactively re-allocate resources
  • improve the foreground / primary user experience
  • legitimate background activity continues uninterrupted
    • Audio: Spotify, Hangouts, YouTube
    • sync, IM clients, Gmail etc.
  • reduce / prevent extreme situations: memory pressure

7 of 23

Problem: App does not know ...

(Without APIs) App cannot know:

  • its importance to the user
  • current resource situation
  • when to wrap up and persist state

Well intentioned developers unable to build optimal user experiences.

8 of 23

Problem: Lack of Incentive

Why should I be a good citizen in background to help the foreground tab?

On Desktop - why should I:

  • release memory
  • give up CPU
  • conserve battery

On Mobile - the OS will stop execution & kill the app anyway.

​

​

​

9 of 23

Problem: Lifecycle Fragments

  • beforeunload | unload
    • inconsistent; missing on mobile
    • work in handlers can delay navigation
    • source of browser bugs - esp. around navigation
      • Use-after-free, UXSS bugs
    • modal dialog: really?
  • pagevisibility
    • no distinction between visible window that lost input focus vs. background tab
  • pagehide | pageshow
    • bfcache inconsistent support (unsupported in chrome)

10 of 23

Ideally ...

Ideally there’d be a consistent way to:

  • persist state and wrap up on session end
  • perform analytics & report to server
  • handoff for background work

​

​

11 of 23

Recap

Problems:

  • Limited resources cause bad user experiences.
    • Even desktop. Especially desktop
  • Lack of APIs to support optimal user experience under constraints.
  • No incentive structure for apps to be resource efficient.
  • Existing APIs are insufficient, inconsistent, error-prone.

​

​

​

12 of 23

This is hurting the web platform.

13 of 23

What can we learn from Mobile Platforms?

14 of 23

iOS Lifecycle

15 of 23

Android

“...fundamental feature of Android is that an application process's lifetime is not directly controlled by the application itself.

Instead, it is determined by the system through a combination of the parts of the application that the system knows are running, how important these things are to the user, and how much overall memory is available in the system.”

16 of 23

Android

Activity

Lifecycle

17 of 23

Over on the web ...

Pending State?

(unreliable) beforeunload Modal Dialog ¯\_(ツ)_/¯

VisibilityState

visible

VisibilityState

hidden

18 of 23

Proposal: Web Lifecycle

19 of 23

Core Ideas

  • System-initiated termination is normal part of app life cycle.
  • Apps in background can be stopped & terminated, depending on:
    • importance to the user
    • resource availability
    • app behavior & responsiveness
  • Callbacks invoked on state transitions, enabling app to:
    • Persist & restore state
    • Reporting & analytics
  • Distinction between tab that lost input focus vs. backgrounded

20 of 23

Core Ideas (continued)

  • App declares type of work needed in background
    • Audio
    • Video capture / cast
    • Updating tab title
    • Periodic Fetch / Sync
    • Network Upload
    • etc.
  • Enable legitimate work in background
    • leverage service worker
    • grant resources to renderer when necessary

21 of 23

22 of 23

23 of 23

Challenges & What’s Ahead

  • Story for session wrap up & persisting state
    • API for reporting to server: use beacon, disallow xhr
    • API for persisting & restoring state: like History.state
    • Plug escape hatch for pending state: beforeunload modal dialog
    • Handling navigation
  • When to require Service worker vs. running the renderer ?
    • APIs to enable legitimate work in background