Re: WebPerfWG design call - August 8th @ 11am PST

Thanks for all who joined us on yesterday's call.
Minutes
<https://docs.google.com/document/d/e/2PACX-1vRYpBBk4ZGkjHofRa6e8vYxHtoKOP6yNPvKSjs8mT-cYPdE-AlDwOIAQf7JLyrFzi44qew_h2XGXURY/pub>
and video <https://www.youtube.com/watch?v=8zPp8TIJW2Q> are available.
Copying the minutes here for safe keeping:

WebPerfWG design call - August 8th 2019

Participants: Utkarsh Goel, Todd Reifsteck, Yoav Weiss, Ilya Grigorik,
Benjamin De Kosnik, Eric Lawrence, Beng Eu, Ryosuke Niwa, Nic Jansma, Will
Hawkins, Addy Osmani

Next call

   - Sept 5th @ 10-noon AM PST


   - Design follow by triage call

TPAC

   - WIP document: bit.ly/webperf-tpac19
   <https://www.google.com/url?q=http://bit.ly/webperf-tpac19&sa=D&ust=1565368118390000>
—
   please sign up!


   - Please sign up, let us know which days you’re attending or remote
   - Please add topics you’d like to discuss


   - Agenda


   - Day 1:


   - Followup on F2F topics: CPU reporting, SPA, Frame Timing
   - Nic: would like to dig into Resource Timing: bubbles, cross-origin


   - Dau 2:


   - Issue triage


   - Ryosuke (FYI): Web Components WG on Tuesday, if you need my input,
   let’s tackle on monday

CPU reporting

Utkarsh: UA’s are not indicative of the current CPU load

… we heard interest at f2f about exposing some signals to the site

… what makes a device slow?

… the device can have fast cores but be under heavy load

… the numbers can have slow cores

… utilization spikes, etc.

… We’ve been trying to collect some use cases and examples

… First one: blocking certain requests when we know device is constrained,
e.g. 3p apps or modules that may hurt user experience

… Second: deliver less complex pages, where you can avoid delivering
complex pages

… Third: run computation on the cloud (offload) - e.g. AMP SSR renders on
the cloud

 … Puffin browser tries to do some JS execution in the cloud to offload

 … there is some academic research in this as well, there are definite
limitations

… Media: one can adapt delivered media (e.g. vary resolution or entire
creative for ads, etc)

… we also don’t have to fixate on slow devices, there are use cases for
faster devices

… e.g. we can run certain tasks only on high-end devices (e.g. speculative
execution)

… (some overlap with rIC / long tasks?)

… lots of open questions on what to report and how

… from RUM perspective, having better visibility into slow vs fast can be
helpful for optimizing how the site is built, their audience, etc.

… is there a “fast enough” signal that we could consider?

  … any device that has >XGHz as fast? Might differ for different apps

  … number of CPU cores or processors can be a signal

… fast device today is not fast tomorrow; requirements change

… if we were to classify, they would need to be updated

… What could browser expose?

… one option is browser bucketed classification: fast, slow, etc, or some
1-10 scale

… number of CPU instructions run in last Y seconds, is that even possible?

Ben: unlikely

Yoav: the concern here is number of bits information can expose

Utkarsh: looking at the use cases, I didn’t see a need for granular
hardware information

… e.g. battery saver mode has an impact on this discussion

… JS API vs HTTP request?

… There are implications here with device abuse and fingerprinting to
consider

 … e.g. fast device is asked to run crypto mining scripts

 … cross-origin tracking and number of bits that is exposed

 … some thinking to do here about fuzz and reduce granularity

Ryosuke: right now, script can’t tell which device is running and we don’t
want to expose this.

Eric: the big problem with this space is that you can’t predict the future,
the only way to find out is to do it.. The crypto script would (and does)
just run the benchmark. Also browsers try to hide this information as it
may reveal cross-origin information — e.g. amount of CPU cycles consumed by
a page can leak info.

Ryosuke: many of the use cases are affected by browser, which version,
where and how CPU decoding is done. In some browsers some operations may
run a lot of faster or slower.

Eric: the overall point.. The notion of distilling to a single signal is
not useful.

Ben: is there any consensus on power saver or clamped?

Ryosuke: this is a showstopper, exposing battery status or power saver is
not something we can do… there is a recent paper that explores this space.

Eric: are websites reacting to signals like save-data?

Addy: there are a number of large sites that are exploring differential
serving - e.g. ECT, etc.

… lacking platform support, some are exploring running benchmarks

… others are building and integrating device databases

Ryosuke: let’s say you’re showing a chat pane on the site, you can observe
if you’re missing frames then you can adjust your runtime.. You can do many
things today without any additional information.

Yoav: in the past there’s been discussion on device year / class

… would that satisfy some use cases?

Utkarsh: from what I remember, they look at when a device was released and
what average CPU was for particular year

Ben: we’ve thought about this space from RUM use case for internal use
case.. E.g. could we bucket based on such signal for internal use

Ilya: short of exposing new APIs, could we provide some recipes?

… e.g. for speculative execution in Excel, what existing signal can they
use to arrive at right outcome? Long tasks, input pending?

[missing notes]

Utkarsh: wonder if developer might want a historical perspective?

Yoav: maybe as a next step, we can break down the use cases and see how we
address them today?

Utkarsh: yep


On Tue, Aug 6, 2019 at 6:41 AM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey all!
>
> Join us on this Thursday for our design call. We'll use the usual hangouts
> link <https://meet.google.com/agz-fbji-spp>.
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.9zg0epmqn75n> we're
> currently planning to talk about TPAC, CPU reporting, and the implications
> of Web Packaging and Portals on WebPerf APIs.
>
> Note that as always, the call will be recorded and posted online.
>
> See y'all there! :)
> Yoav
>