Proposal: Device Class and Device Memory

##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:

1. 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

2. 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

The Header

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.

@Nic_Jansma, @igrigorik, @toddreifsteck, @yoavweiss

Why round down to the nearest power of 2 instead of the actual value?

The iPhone 4S was a high-end device released in 2011, and had just 512MB RAM. So isn’t it likely that in a few years all the low-end devices will have 2GB RAM like today’s iPhone 7? Could that not make this irrelevant?

Also if the goal is to identify low-end devices, then this feature needlessly helps fingerprint high-end devices by whether they have e.g. 4 GB, 8 GB or 16 GB RAM, which likely makes no difference to what would be served in the page.

Would it not be better just to use say “low”, “medium” and “high” classifications with vendor-determined definitions? For example a browser could easily map these to <= 512MB RAM, <= 1 GB, > 1 GB.

Rounding to power of 2 is to:

• prevent cache explosion for CDNs using Vary for client hints header
• mitigate fingerprinting

The reason for exposing (rounded) ram values is actually for future-proofing. Having opinionated “low”, “medium” and “high” classifications requires ongoing work on keeping classification updated and there will be inconsistencies across vendors and versions. In the future, it may make sense to have an opinionated classification for “device class” on the whole, not just memory. Please see the section on “Why not surface Device Class directly?” for context.

Re: " … in a few years all the low-end devices will have 2GB RAM " Yes exactly, and apps will update their triggers (for lite mode etc) to take that into consideration.

Re: "… needlessly helps fingerprint high-end devices" Yes that is a tradeoff here.

For reference, there is also a companion “Memory Pressure” proposal: Proposal: Memory Pressure API

I’d like to propose moving this repo to WICG: https://github.com/spanicker/device-ram @yoavweiss

I strongly support that API moving forward to the WICG