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

On Wed, Mar 22, 2017 at 11:15 AM, Philippe Le Hégaret <plh@w3.org> wrote:

> --- Memory APIs
>
> Shubhie: curious to hear feedback on exposing device classes, looking for
> feedback
> ... surface device memory capability (exploration) doc:
> https://docs.google.com/document/d/1O0fKj5q4U8EF2LZdScXB6c02
> laQmixPekG-fuCQUHys/edit
> ... 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
> signals
> ... 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: https://github.com/w3c/charter
> -webperf/issues/27
> ... 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
>
BTW - Dru and Jake have been thinking about this space, around navigation
transitions <https://github.com/jakearchibald/navigation-transitions> and
UI. Dru has been working with UX IIRC, would be good to make sure your case
is considered.


> ... 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
> PerfObserver
> ... 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?
> https://github.com/w3c/performance-timeline/issues/56#
> issuecomment-268922807
>
> --- 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
> approvals
>
> --- Install PR preview and diff tool on all perf repos?
>
> https://github.com/tobie/pr-preview#install
> 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
> compliant)
>
> 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: https://github.com/w3c/perform
> ance-timeline/pull/75
>
> 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
>
>