W3C home > Mailing lists > Public > public-web-perf@w3.org > March 2017

Minutes (was: [3/22/17] webperf group call @ 10AM PST)

From: Philippe Le Hégaret <plh@w3.org>
Date: Wed, 22 Mar 2017 14:15:53 -0400
To: public-web-perf <public-web-perf@w3.org>
Message-ID: <4936b0a8-4861-ec8e-68f3-f5b6db9222f6@w3.org>
--- Memory APIs

Shubhie: curious to hear feedback on exposing device classes, looking 
for feedback
... surface device memory capability (exploration) doc: 
... e.g. 100ms task on a high-end phone is not the same as a low-end 
mobile device
... broader device classifications seems hard to future-proof; perhaps 
we can focus on couple of basic signals (e.g. cores, memory, etc), and 
allow libraries to build their own "device class"
n8s: that makes a lot of sense, defining device class can be very arbitrary
... big fan of this, would like to see some CPU information - e.g. make 
and model?
Shubhie: if you only had memory, is that still useful?
n8s: guessing, still useful, but hard to say without seeing the data
igrigorik: higher level API for "lite mode" that captures battery, 
memory pressure, etc?
n8s: all of the signals serve different purposes
... for video performance, the thresholds and use cases are different
n8s: you can go from lots of data to lite mode, but not the other way
yoav: we probably need both the high-level dynamic API and the low-level 
... there is a set of use cases that want this data as a Client Hint on 
the navigation
... vs. run time use case
Shubhie: memory pressure feedback so far is that it's unclear what to do
n8s: we'd probably use it as a signal for what we shouldn't do - e.g. 
mount certain component
nolan: there are two parts to the proposal (1) header and the (2) 
runtime API
Yoav: we'd certainly use the JS api for analytics
n8s: application branching in JS; FB would use both
AI: shubhie will start a thread on WICG on device class reporting


n8s: SPA's indicators
... we should all catch up on: 
... it's hard to get good telemetry on navigations
... if you navigate on FB, we don't reload the page, we trick the 
browser to show loading indicator (by injecting the iframe)
... it'd be nice to control the loading indicators
... we'd like to get rid of the iframe hack
(works across all the browsers)
AI: n8s to write a summary on loading indicator use case

--- Server-Timing

Yoav: Charles started implementing ST in blink
... got feedback in the i2i thread that it should be implemented with 
... current implementation is doing buffering of events until onload 
fires and then delivers to observers
... bufferring is unbounded
... we need to spec this behavior in Perf Timeline
Charles: was planning to update Server-Timing, and can work on perf 
timeline bits
... should the buffer be clearable?

--- migrating Server-Timing, Long-Tasks

plh: need a green light from WICG
<yoav> https://wicg.github.io/admin/intent-to-migrate.html
plh: we're good to adopt
AI: Ilya to send out intent to migrate to webperf + cc wicg

--- Next steps on charter?

plh: the update is in scope, so we don't need to go through additional 

--- Install PR preview and diff tool on all perf repos?

AI: need to figure out config file + how to trigger
* tobie for pr-preview, you should do a blanket install for the org. 
Then adding a config file to the repo is all you need to get it running 
for that repo. There's a tool for testing your config file and creating 
a PR for it.

--- Beacon API

igrigorik: propose we move to CR
plh: sgtm
AI: xiaoqian will send out transition request

--- Page visibility: https://github.com/w3c/web-platform-tests/pull/5185

xiaoqian: only one browser passed that test
... we need to test in IE11
plh: we only have one implementation for "prerender" in PV
igrigorik: I'd consider prerender as an at-risk feature
yoav: for spec compliance, how do we test optional behavior (no-op is 

AI: update PV spec and mark prerender at risk

Nolan: want to check w/ Todd; it appears that it may be broken in Win10

AI: Nolan/Todd to review the test

--- HR Time L2

prompt to unload test: xiaoqian has a test WIP; we'll iterate on Github

--- Performance Timeline L2

Editorial + cleanup updates PR: 

AI: plh@ to review the PR and land if all is good

--- Resource Timing

TAO tests: https://github.com/w3c/resource-timing/issues/92

plh: we should merge in TAO update into L1
AI: plh@ to merge TAO update into L1
AI: republish L1 with update
AI: Nolan/Todd to review TAO tests

next sync on April 12
Received on Wednesday, 22 March 2017 18:16:06 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 22 March 2017 18:16:06 UTC