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

TPAC

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