Intros

Yoav: working on RUM APIs to enable optimization features

Todd: Understanding ergonomics

Phil: RUM

Shubhie: Building blocks
... Desktop memory

Harald: Quantum: servo/rust → gecko, with target to optimize perceived performance
... Long Task API

Nic: PerfObserver, Resource Timing

Benoit: Sharing opportunities that we see @ FB

Ryosuke: Finalizing issues in RT and NT issues + tests
... Future: Paint Timing API

Charles: Getting Server-Timing + PerfObserver

Progress since TPAC 2016

igrigorik: [A very brief kick-off deck].

igrigorik: [TPAC 2016 review].

PerformanceObserver

Developer friendliness

Q: How do we motivate developers to use PerformanceObserver?

Nic: New specs are moving towards performanceobserver.

• Found a few edge cases that make it hard to use
• Developer friendliness - how do we make it easier to use?
  • More challenging to play around with - e.g. get all the resources on the page when I open DevTools. You have to start the observer, get the callback, and do much of stuff.

  • Benoit: ditto.

Ryosuke: let’s work on a coherent strategy across specs

Buffers, buffers everywhere

Q: Should we increase individual buffers?

• Always on / circular buffers can become costly (cpu, memory, etc)

Goal

• Minimize overhead for the engine
• Some APIs have a cost
• Consistence
• We don’t want to allocate large buffers for every spec

Proposal

• Each feature defines a buffer with custom buffer size
• Buffer events until max buffer size or end of onload
  When the buffer is full?
  • Keep the first N entries, drop.

  • Do not clear at at end of onload

    Under memory pressure UA can clear buffers

  • Indicate missing entries?

• An API to query available types + properties

  Enumerate observable types

  how many entries you can observe

Iframes + PerfObserver

Nic: With RT we crawl all the iframes and harvest all the data
... - with PO we have to crawl all the observers
... - third party scripts can create same-origin iframes

Ryosuke: in MutationObserver we have subtree monitoring

Todd: all same-origin iframes are observed to the observer
... - Subtree?

Complications

• Time origins would be different?
• We would have to point to document element?

Proposal -- feature request.

• Add subtree flag to observe PO events in same-origin frames
  • Marker to a global where it was capture
    • Long tasks: takes all the interesting attributes + self, cross-origin.
    • We could convey ancestor information.
  • Run time-origin translation logic
• AI: Nick will draft issues

Linking entries -- e.g. Resource Timing and Server Timing

Q1: Linking to ResourceTiming

Q2: Should we be linking Fetch and RT L3 entries?

Charles: There is no way to link ST and RT reliably
... RT resources with same name (existing paint point)
... ST events emitted separately, hard to link

We can merge related entries where it makes sense

We can look for a more generic solution?

• We probably need both
• Best proxy we have today is startTime, which has limitations

• Entry ID?

  Within realm of perf entries this works, but doesn’t work as well across specs and other specs

Guidance

If it’s meaningful to observe entries separately..

Keep them separate but provide an ID to link the entries.

Otherwise, hang it off the parent entry...

Child shouldn’t block creation of the parent

Proposal

Add a hook in ResourceTiming

Server Timing spec populates fields on the RT object

Update ST to populate an array of ST entries on RT

Element Timing API

Need to make sure we’re not exposing any new privacy/security vectors

Double-rAF as a baseline

Start with some simple use cases --

• Images - most wanted; paint time? decoded time? Cycle?

  When is an image painted? What happens with progressive images? Partial paints?

• Webfonts
• Videos - autoplay?

Change strategy?

Start by defining behavior and restrictions for particular types

img, video, fonts, etc.

Lifecycle API

• [Shubhie's Presentation].
  • Answers the question “Is my web app alive or dead?”
  • Not well defined when apps are in the background, especially on mobile
  • Too many tabs => limited resources => poor UX
  • Ideally browsers prevented extreme resource drain while enabling legitimate BG usage
  • Apps have no way to signal to the browser their BG importance
  • There’s also no incentives for web apps to be good BG citizens
  • We have fragmented lifecycle APIs: beforeunload, unload, visibility, page{hide,show}
  • Need a consistent API, enable analytics and wrap-up, handoff to BG work
  • iOS apps get a lot of signals from the platform when they’re BGed
  • Android takes “importance to user” into consideration before killing an app
  • On the web: just visibility state, we can do better
  • Maybe should enable apps to declare what BG work they need to do

  • Lifecycle states: Active, passive, stopped, demoted, terminated

    At stopped, apps should start preparing to die

  • Session wrap up: beacon, save history state, beforeunload replacement
  • Overlaps with SW: backgroundsync?
• Might be able to tie that in with the Budget API to create incentives
• Need to define the “legitimate background work” use cases
• States need to be persistent

Memory pressure

Ryosuke: MP is of interest, we just recently added 4GB memory limit to each web content process (~equivalent to Chrome renderer process)

Shubhie: Unclear if it was targeted at foreground or background?
... There is desire for signals for telemetry..
... - Instead of dynamic (e.g. purge memory), perhaps the outcome is a change in the app for all users

Ryosuke: we are still interested in Memory Pressure, unsure about revealing memory size

Todd: we were thinking of a simple model: 1GB == medium, 2GB == … 4GB = kill

Shubhie: what do we expect sites to do with this signal?

Todd / Ryosuke: All browsers have a stick (2GB/4GB) engine

Todd: My model is “hold this tab accountable for own limits - e.g. you’re using >1GB”
... That would accommodate the “leak detection” use case
... Proposal:
... - Per tab: low, medium, high
... -- Low ~ 50% of the limit on the content process
... -- Medium ~75% of the limit …
... -- High ~90% …

Shubhie: What about OOM reporting?

Todd: use Reporting API to deliver OOM reports?
... - Lack of implementation
... - Design a simple Javascript API

Use Cases

• Leak case
  • Security / privacy implications.. Would have to be very coarse, too coarse to be useful?

  • Spike case

    You’re using a high amount of memory

• Crash case
  • Allow reports to flow back to the site, instead of to the UA
  • We can’t guarantee that all OOMs can’t be delivered, that’s OK

Event Timing

[Shubhie's Presentation]

Long Task

Shubhie: v2: want to make it measurement based
... - If the top level task takes >50ms
... -- If script tasks are running, note which doc frame they belong to, record
... * Name: self, same origin, ancestor, descendent
... * Attribute: [<TaskAttributionTiming>]
... ** Describes what’s happening within the task
... *** > 12ms

v2

• Multiple attribution entries in the array, each of which is > 12ms
• Show array for attribution
  • + style or layout
  • + script with URL

Compression API?

[Yoav's Proposal] -- Motivation, use cases.

Prioritization: which items should we tackle as a group?

Q: which items should we tackle as a group?

• Edge:

  PerfObserver + intertop with other apis

  Buffering, etc.

• Safari:
  • Finalizing PerformanceObserver
  • Memory pressure
  • Paint Timing API + FMP because many sites care about it
• Exploratory:
  • Lifecycle:

    • Define processing model

      What websites would break if sites transitioned to STOPPED?

    • What APIs do we need for how to persist state, background capabilities, etc.
    • Should this be @ WebPlat WG?
  • Timing attacks explainer.. would be nice.
  • Event Timing