Web Performance Working Group

30 Aug 2017


igrigorik, shubhie, Yoav, todd, plh, Tim, dale



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

  1. publish FPWD for Long Tasks and Paint Timing
  2. publish preload as CR
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/09/01 14:30:17 $