Intent to Implement: Device RAM header & API

[Shubhie Panicker]

Contact emails

pani...@chromium.org, mariak...@chromium.org

Spec

Link to explainer: https://github.com/spanicker/device-ram

Summary

A header and API to surface device capability for memory i.e. device RAM.

This is to enable web apps to customize content depending on device RAM constraint.

Motivation

Developers need “device-class” signal for:

1. Serving “light” version of the site or specific components, for low end devices:

• Serve Google "search lite" - a 10KB search results page used in EM.

• Serve a light version of video player in Facebook

• Serve lightweight tile images in Google Maps

2. Normalizing Metrics: analytics need to be able to normalize their metrics against the device-class. For instance, a 100ms long task on a Pixel is a more severe issue vs. on a low end device.

Device memory is an especially useful signal for this. Low memory devices devices (under 512MB, 512MB - 1GB) are widely used in emerging markets.

(For details on why “Device Class” is not directly exposed, see here)

Privacy

Restricting to a ceiling value (rounded down to the nearest power of two), as opposed to exact value, significantly mitigates fingerprinting. This could be further restricted, if necessary, to returning values only for low memory cases (eg. 1GB or less).

Interoperability and Compatibility Risk

Low. The header would not be sent on browsers where this is not available, and the API would not be available -- for customizing content.

Edge: Positive signal (public-web-perf meeting agenda - doc comments)

Firefox: No signals

Safari: No signals

Web developers: Positive (positive signals from Facebook, Google Search, Google Maps, Akamai  etc.)

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=710702

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5741299856572416

Requesting approval to ship?

No

[PhistucK]

The explainer reads, "The mechanism should be extensible to other device capabilities such as CPU i.e. number of cores, clock speed etc", however, the proposed API and header names are overly specific.

How does this related to performance.memory? Does it replace it? Does it complement it?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Shubhie Panicker]

We are starting with memory because it is a good proxy for "device class" and we know exactly what to expose here.

While we know we want a similar signal for CPU its unclear exactly what to expose (cores / clock-speed / family etc.), so some work is needed to make a concrete proposal.

When that proposal is made it should use the same mechanism (header and API) as current proposal. Does that clarify your question?

<<"How does this related to performance.memory? Does it replace it? Does it complement it?"

This is orthogonal to performance.memory - which is about memory usage rather than (constant) device RAM. In that sense it is related to the Memory Pressure API proposal.

Note that performance.memory itself was never standardized (and not planned).

[Kentaro Hara]

I strongly support this API, from the perspective of memory reduction.

As far as I investigate memory usage of low-end devices, I begin to think more and more that it's key to collaborate with web developers. In some websites, it's hard to achieve a massive memory reduction without getting web developers to change their websites (e.g., decrease # of cached tiles from Google Maps on low-end devices, decrease # of displayed images on Flipkart etc). It makes a lot of sense to expose an API that enables web developers to optimize their websites for low-end devices.

--

Kentaro Hara, Tokyo, Japan

[PhistucK]

It clarifies, but I think it makes sense to group all of this device class related information together (navigator.deviceInformation? navigator.deviceClass?) but simply add them one by one into the API.

The API is mostly my concern, not the header (though a combined header would be good, the the proxy concerns were mentioned).

While it is not the same, there is performance.memory.jsHeapSizeLimit which kind of hints at the same goal in a way.

Oh, if there are no plans to standardize it, when will it be removed? :)

Off topic, yeah.

☆PhistucK

[PhistucK]

I have a notebook with 4 GB RAM. It is very slow most of the time and having the same benefits as low-end devices in this regard would probably slow it down less. Though this API will not reveal that fact. I guess the memory pressure API will try to resolve that? But I am not sure memory is always the problem, it is not necessarily so high when it is slow.

Can this proposal accommodate such cases as well somehow?

☆PhistucK

[Philip Jägenstedt]

On Thu, Apr 13, 2017 at 12:51 PM PhistucK <phis...@gmail.com> wrote:

It clarifies, but I think it makes sense to group all of this device class related information together (navigator.deviceInformation? navigator.deviceClass?) but simply add them one by one into the API.

The API is mostly my concern, not the header (though a combined header would be good, the the proxy concerns were mentioned).

While it is not the same, there is performance.memory.jsHeapSizeLimit which kind of hints at the same goal in a way.

Oh, if there are no plans to standardize it, when will it be removed? :)

Off topic, yeah.

Tracked by https://bugs.chromium.org/p/chromium/issues/detail?id=709008, recently filed and not triaged yet. 

[Kentaro Hara]

As far as I understand:

- The device RAM API is for static memory optimizations. The API just tells how much memory the device has.

- The memory pressure API is for dynamic memory optimizations. The API tells how much memory is available at each point.

I think both are useful.

[Yoav Weiss]

I'd also like state strong support for this API. A while back, I wrote too many words about the need for better content adaptation. This API will enable adaptation based on device capabilities, and enable developers to avoid sending large media to devices who do not have the memory to handle them.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--

Kentaro Hara, Tokyo, Japan

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Shubhie Panicker]

I commented in the bug (and added Rick), unfortunately performance.memory is widely used and removing may be complicated.