##Motivation To support a diverse web ecosystem that is inclusive of users on low end devices, apps need to be able to tailor their content to the device constraints. This allows users to consume content suited to their device, and ensures they have a good experience and fewer frustrations.
Developers & Analytics have indicated interest in the “device-class” for the following known use-cases:
- Serve a “lite” version of the site or specific components, for low end devices. Eg.
- Google “search lite” in emerging markets - a 10KB search results page
- A light version of video player
- Normalize Metrics: analytics need to be able to normalize their metrics against the device-class. Eg. 100ms long tasks on a Pixel is a more severe issue vs. on a low end device.
Device memory is an interesting signal in this context. Low memory devices devices (under 512MB, 512MB - 1GB) are widely used in emerging markets. Chrome telemetry indicates significant OOMs on foreground tabs on these devices. In this case, serving a lite version not only improves the user experience, it is necessary for the site to be usable at all.
##Proposal We propose a header and web exposed API to surface device capability for memory (RAM). The mechanism should be extensible to other device capabilities such as CPU i.e. number of cores, clock speed etc. A header will enable the server to deliver appropriate content, eg. a lite version of the site. The JS API will be used by analytics and by apps for branching in JS. ASIDE: the JS API for CPU Cores is already available via hardwareConcurrency API
Proposed Header for memory: device-ram
device-ram : <value>
where is the number of GiB of ram (floating point number) rounded down to the nearest power of two.
For example, if the user has the total of 512 MiB of RAM the value would be 0.5. If they have 768 MiB of ram it would also be 0.5. If they have 3 GiB of RAM the value would be 2.
Rounding prevents cache explosion for CDNs using Vary for client hints header and also mitigates fingerprinting.
####When is the header sent? Currently Client Hints cannot be used to enable providing network performance data on the first request, however this is being actively addressed with this proposal. Once this is resolved, the header is sent after an explicit per-origin opt-in via Client Hints mechanism. The following new hint will be added: Accept-CH: device-ram
For background, Client Hints provides a set of HTTP request header fields, known as Client Hints, to deliver content that is optimized for the device. In that sense using Client Hints is a great fit for this proposal.
The web exposed API
We propose adding the following API to navigator: navigator.deviceRam which returns number of GiB of ram (floating point number) rounded down to the nearest power of two (same as the header).
Why not surface Device Class directly?
While exposing a composite “Device Class” would be useful for developers, it has a number of challenges: it’s hard to specify in a future-proof manner as it is constantly changing, it requires significant and ongoing work (constantly update algorithm OR classify known devices), it is difficult to reach agreement amongst vendors, and come up with something that works for all web sites etc. While this may be something worth considering down the road, we think we can get most of the benefit by exposing a couple of specific signals device memory and device CPU cores. In particular device memory is a reasonable proxy for device class.