[Minutes] WebPerf WG F2F Meeting 2017-Jun-20

The minutes from the 2017-Jun-20 f2f meeting are available at:
https://www.w3.org/2017/06/20-webperf-minutes.html
or
https://docs.google.com/document/d/1fcWpKZhJdrmBlpYUB2wIx42svo9zqojoJMZg8aY7E7Y/edit

also as text below.

Thanks to the scribes, the chairs, the host, and anyone who contributed 
their ideas to the topics.

-xiaoqian

--------------------
WebPerf WG F2F Meeting

20 Jun 2017

Agenda: 
https://docs.google.com/document/d/1fcWpKZhJdrmBlpYUB2wIx42svo9zqojoJMZg8aY7E7Y/edit

See also: Notes on Google Doc

Attendees

Present
igrigorik, shubhie, Todd, Yoav, Phil, Harald, Nic, Benoit, xiaoqian, 
Colin, Ryosuke, Charles
Regrets
Chair
igrigorik, Todd
Scribe
igrigorik, Yoav
Contents

Topics
Intros
Progress since TPAC 2016
PerformanceObserver
Linking entries -- e.g. Resource Timing and Server Timing
Element Timing API
Lifecycle API
Memory pressure
Event Timing
Long Task
Compression API?
Prioritization: which items should we tackle as a group?
Summary of Resolutions
Proposal for PerformanceObserver buffer logic
Proposal for PerformanceObserver Iframes bubble
Proposal for linking entries
Change strategy of Element Timing API
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] (feel free to request access to this).
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
--------------------

Received on Monday, 26 June 2017 16:25:55 UTC