Thanks for this! We've just had a quick preliminary look at it, and will address it more thoroughly soon.

Quick question though: If your primary use case is for improving the user experience in developing countries, what evidence do we have that the problem is indeed memory and not just bandwidth? Are you considering bandwidth in a separate vein? It was great to see your comment in the explainer about Chrome telemetry showing OOM crashes... anything from other UAs? Or other causes of bad UX? (ping @torgo)

The primary usecase is addressing the wide range of devices, which continues to grow due to competing on price. The main evidence for bad user experience on low end devices is telemetry data (internal UMA metrics, not public, but we may be to jump through some hoops to share publicly) indicating higher OOM crashes on foreground tab on these devices. Also in simple local testing many modern sites are unusable on a 512MB device.

Bandwidth / connection quality is a big problem as well, it is addressed with recent extensions to NetInfo for "effective connection type", rtt and downlink: https://wicg.github.io/netinfo/#-dfn-networkinformation-dfn-interface

Updated spec url: https://w3c.github.io/device-memory/

[With my Microsoft hat on.] We (at Microsoft) see very similar patterns in our telemetry streams. Websites are often just too-big/complicated to function well with less-memory. Of course, we are continuously working to make our browser more efficient and use less-memory, but it's really easy for a web-site to consume lots of memory and then reach a threshold that the device force-terminates the browser due to high-memory usage.

Links above should probably be updated to https://github.com/w3c/device-memory/blob/master/index.bs and https://w3c.github.io/device-memory/.

Hey @spanicker; thanks for filing the review request!

We discussed the explainer at today's F2F meeting in Nice and had some thoughts:

• There's a lot of enthusiasm for this. Looks like a solid addition to the platform.
• Which requests are eligible for getting the header? All requests? Top-level navigations? All requests to the source origin? All document requests (e.g., iframes)? Service worker script requests? All scripts?
• Great to see the secure context restriction! Thanks for making that hard call in favor of user privacy.
• What's the anticipated behavior of the navigator.deviceMemory API when the Accept-CH = Device-Memory header isn't set?
• For consistency, do you anticipate also extending the hardwareConcurrency information with a similar header?
• Why is sending this header restricted to requests that have the Accept-CH header? If the response value is restricted (e.g. to top-level navigation requests), it seems like requiring the opt-in will just add more bloat for production services (like Google) that are likely to query for this data pervasively.
• Have there been discussions about how related values (e.g., video memory) might be surfaced?

Thanks again; looking forward to discussing this more.

Also, cc: @mnot for discussion of HTTP aspects.

Thanks for the feedback!

Which requests are eligible for getting the header? All requests?

Yes - all requests. This is the same as what applies to Client Hints in general, we are not restricting request type for Device Memory. Suggestions here are welcome, but would likely apply to Client Hints in general.

What's the anticipated behavior of the navigator.deviceMemory API when the Accept-CH = Device-Memory header isn't set?

navigator.deviceMemory API will work even without Accept-CH header (for HTTPS secure contexts only). The usecase for navigator.deviceMemory API is bit different from the header - the API will be used by analytics for device class and for normalizing metrics against etc.

For consistency, do you anticipate also extending the hardwareConcurrency information with a similar header?

Yes. @n8schloss is planning to drive this work.

Why is sending this header restricted to requests that have the Accept-CH header? If the response value is restricted (e.g. to top-level navigation requests), it seems like requiring the opt-in will just add more bloat for production services (like Google) that are likely to query for this data pervasively.

The opt-in with Accept-CH is needed to avoid request overhead / bloat from sending lots of uninteresting headers that are not useful or needed. Most apps will need this header on the very first request (eg. to serve Google Search Lite), and the Accept-CH-Lifetime addition addresses this need: http://httpwg.org/http-extensions/client-hints.html#accept-ch-lifetime

Have there been discussions about how related values (e.g., video memory) might be surfaced?

Not yet. Developers have not yet requested this AFAIK.

\cc @fmeawad

LGTM. Thank you for the thorough response!