Minutes (was: Re: [8/30/17] webperf group call @ 10AM PST)

Hi,

The minutes of the 30 August WebPerf Group Call are available at:
https://www.w3.org/2017/08/30-webperf-minutes.html

See also:
Web Performance Working Group

30 Aug 2017

Attendees

Present
igrigorik, shubhie, Yoav, todd, plh, Tim, dale
Regrets
Chair
igrigorik
Scribe
igrigorik
Contents

Topics
RIC to PR
Long Tasks & Paint Timing: move to FPWD?
Preload --> CR?
HR-time → blocked on unload test
Beacon → blocked on CORS tests
User Timing → worker tests
Long Tasks status
web lifecycle
Summary of Action Items
Summary of Resolutions
RIC to PR

igrigorik: ric: updates landed, no substantative changes

plh: will review and chat with director, if there is push back we can 
republish as CR
... also callback suspended test needs two passing implementations

<scribe> ACTION: Ilya + Ross to investigate ric failing test on Chrome 
side
Long Tasks & Paint Timing: move to FPWD?

plh: we'll publish draft to TR
... once we publish FPWD, we need to setup auto-republish

shubhie: did a test for long tasks yesterday, seems to have worked; need 
to setup for first-paint
... also need to setup device memory

RESOLUTION: publish FPWD for Long Tasks and Paint Timing

<scribe> ACTION: plh to setup publishing for LT, PT, Device Memory
plh: what status of tests?

shubhie: we have tests for long tasks
... for paint timing we need some extra work in WPT to land those

Tim: Nicholas (on Chrome side) is working on paint timing tests

shubhie: long tasks tests should be upstreamed in WPT

<plh> http://wpt.fyi/longtask-timing
scribe: failing test for LT: we're simulating long task by running a 
long script, but they get joined together.. and test machinery itself 
generates some long tasks

Yoav: how flaky are LT tests?

Shubhie: seem to be A-ok

Preload --> CR?

Yoav: the big hurdle was defining the preload cache as part of Fetch 
spec
... but this is fetch spec work, which won't impact the behavior of 
preload API
... I think it shouldn't block L1 CR

<plh> http://wpt.fyi/beacon
plh: what kind of tests do we have for caching?

Yoav: we have tests, FF modified their tests when they shipped because 
our tests did not match their caching behavior
... current tests in WPT pass in Chrome and FF
... once Fetch patch for preload cache is merged it will highlight 
implementation differences
... FF changed behavior to pass in both

<yoav> http://wpt.fyi/preload
scribe: current tests ignore caching differences

plh: CR sounds reasonable, we have two implementations.. how long do we 
stay there?

toddreif: preload is coming, eta ~3~4 months in insider builds
... I don't see any good reason to block CR from our side

plh: once we have in CR, how long do we stay in CR?

toddreif: any critical pushback (if any) we'll have before end of year

plh: at TPAC we can put on agenda to move to PR

RESOLUTION: publish preload as CR

<scribe> ACTION: plh to publish CR
<plh> 
https://lists.w3.org/Archives/Public/spec-prod/2017JulSep/0005.html
HR-time → blocked on unload test

dale: found some issues with current test
... there is potential ambiguity in the spec, need to dig in more

todd: one issue is that time origin starts when dialogue prompts.

Beacon → blocked on CORS tests

todd: we're blocked on release, WIP

User Timing → worker tests

todd: Luis was blocked on GitHub, should be coming

Long Tasks status

todd: Long Tasks slipped through for next release, don't have any 
substantive feedback yet
... need to circle back internally with folks for strings describing 
different long tasks

shubhie: current proposal is captured in the latest spec; subset of 
those match our implementation
... also need to check-in with other browsers
... as a starting point, some feedback on current strings

<scribe> ACTION: Todd to gather feedback for next call
web lifecycle

shubhie: too many tabs, limited resources
... background tabs and windows end up hurting user experience
... we want to define lifecycle to allow UA to optimize foreground 
activity, while allowing legitimate background activity
... the goal is to reduce memory pressure, improve user experience
... current lifecycle is fragmented
... ideally, we need to allow apps to persist state, session wrapup, 
analytics and reporting, and background work
... idea is to use native app as inspiration
... iOS has 5 states, android has a number of activity transitions (~5 
with callbacks in each transition)
... on the web we have PV and pagehide/show, bot those have gaps, 
especially on mobile
... core ideas: system initiated termination is normal part of lifecycle
... + apps in background can be stopped and terminted
... + we need callbacks on these transitions
... active -> passive -> backgrounded > stopped
... stopped already exists in soem browsers -- e.g. bfcache
... proposal is to reuse existing callbacks
... use pagehide and show for stopped

stopped to discarded -> unload with reason == discarded

scribe: we considered declarative API: came to conclusion that it'll be 
very complex to meet all the requirements; more info in explainer

todd: what's the best way to catchup with latest thinking?

shubhie: explainer is up to date -- review that

todd: on some platforms the OS state does not map exactly, we may have 
to account for that
... the other gotcha is that there is no limit on callbacks
... longtail (bad) examples are bad code on sites
... existing callbacks may limit our ability

<scribe> ACTION: Todd to review TTI and lifecycle
Summary of Action Items

[NEW] ACTION: Ilya + Ross to investigate ric failing test on Chrome side
[NEW] ACTION: plh to publish CR
[NEW] ACTION: plh to setup publishing for LT, PT, Device Memory
[NEW] ACTION: Todd to gather feedback for next call
[NEW] ACTION: Todd to review TTI and lifecycle

Summary of Resolutions

publish FPWD for Long Tasks and Paint Timing
publish preload as CR

Received on Friday, 1 September 2017 16:25:40 UTC