- From: Shubhie Panicker <panicker@google.com>
- Date: Thu, 23 Mar 2017 13:02:39 -0700
- 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>
- Message-ID: <CAK7ODi8bBM0vYstSjc1rWYAW4c+kxoa3S0A6cWMUzQhye3m=iQ@mail.gmail.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