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

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

From: Shubhie Panicker <panicker@google.com>
Date: Thu, 23 Mar 2017 13:02:39 -0700
Message-ID: <CAK7ODi8bBM0vYstSjc1rWYAW4c+kxoa3S0A6cWMUzQhye3m=iQ@mail.gmail.com>
To: Dru Knox <dknox@google.com>, Nathan Schloss <n8s@fb.com>
Cc: Philippe Le Hégaret <plh@w3.org>, Kingston Tam <kingston@google.com>, public-web-perf <public-web-perf@w3.org>, Jake Archibald <jakearchibald@google.com>
+Nate

On Wed, Mar 22, 2017 at 5:16 PM, Dru Knox <dknox@google.com> wrote:

>
>
> On Wed, Mar 22, 2017 at 5:08 PM Shubhie Panicker <panicker@google.com>
> wrote:
>
>>
>>
>> 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/1O0fKj5q4U8EF2LZdScXB6c02laQmi
>> xPekG-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.
>>
>
> +kingston@google.com <kingston@google.com> has been driving the research
> around loading indicator, so he might be a good person to chat with about
> Facebook's use cases.
>
>
>>
>>
>> ... 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/
>> performance-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
>>
>>
>>
Received on Thursday, 23 March 2017 20:03:44 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 23 March 2017 20:03:44 UTC