Skip to content

Emphasize the bounds can be dymanically adjusted by implements #53

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
tunetheweb merged 4 commits into from
Jan 19, 2026
Merged

Emphasize the bounds can be dymanically adjusted by implements #53

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
dc8474f
Emphasize the bounds can be dymanically adjusted by implements
Jan 9, 2026
e498311
Remove "geographic regions".
Jan 16, 2026
9d789e5
Update examples using outdated limits
tunetheweb Jan 19, 2026
fecdce7
Update examples
tunetheweb Jan 19, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 10 additions & 13 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ Developers are interested in the “device class” for the following known use-
2. Normalize Metrics: analytics need to be able to normalize their metrics against the device-class.
For instance, a 100ms long task is a more severe issue on a Pixel 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 a large number of OOM (out-of-memory) crashes 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 (as opposed to crashing due to memory constraints).
Device memory is an interesting signal in this context. Low memory devices devices are widely used in emerging markets. Chrome telemetry indicates a large number of OOM (out-of-memory) crashes 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 (as opposed to crashing due to memory constraints).

## Proposal
We propose a new HTTP Client Hints header and a web exposed API to surface device capabilities for memory (RAM). The mechanism should be extensible to other device capabilities such as CPU i.e. number of cores, clock speed etc.
Expand All @@ -27,21 +27,18 @@ Proposed Client Hints Header for memory: `Sec-CH-Device-Memory`\
where `<value>` is an approximation of the amount of RAM in GiB (floating point number).\
The `<value>` is calculated by using the actual device memory in MiB then rounding it to the nearest number where only the most significant bit can be set and the rest are zeros (nearest power of two). Then dividing that number by 1024.0 to get the value in GiB.

An upper bound and a lower bound should be set on the list of values. While implementations may choose different values, the recommended upper bound is 8GiB and the recommended lower bound is 0.25GiB (or 256MiB).
The upper and lower bounds are not explicit, as they are subject to change over time.
An upper bound and a lower bound should be set on the list of values so the fingerprinting is mitigated. The Implementations may set upper and lower bounds and adjust them dynamically over time. These bounds may even differ on different device types.

The following table illustrates some examples:
The following table illustrates some examples (note no bounds are set in these examples):

| Actual in MiB | Rounded in MiB | Reported in GiB |
|---------------|----------------|-----------------|
| 500 | 512 | 0.5 |
| 512 | 512 | 0.5 |
| 768 | 512 | 0.5 |
| 1000 | 1024 | 1 |
| 1793 | 2048 | 2 |

A full list of possible values is as follows:
0.25, 0.5, 1, 2, 4, 8
| 3000 | 2048 | 2 |
| 3072 | 2048 | 2 |
| 3073 | 4096 | 4 |
| 16384 | 16384 | 16 |
| 24576 | 16384 | 16 |

#### Why separate header and rounding?
HTTP caching doesn't deal well with mixed value headers, therefore separate headers are recommended. Also, rounding down to power of two enables caching and mitigates fingerprinting.
Expand All @@ -60,9 +57,9 @@ Servers can advertise support for Client Hints using the Accept-CH header field
```

The Memory request header field is a number for the client’s device memory i.e. approximate amount of ram in GiB.
eg. 512 MiB will be reported as:
eg. 2024 MiB will be reported as:
```
Sec-CH-Device-Memory: 0.5
Sec-CH-Device-Memory: 2
```

Servers can use this header to customize content for low memory device eg. serve light version of the app or a component such as a video player.
Expand Down
7 changes: 3 additions & 4 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,6 +7,7 @@ Status: ED
ED: https://www.w3.org/TR/device-memory/
TR: https://www.w3.org/TR/device-memory/
Editor: Barry Pollard, Google https://google.com, barrypollard@google.com, w3cid 138839
Editor: Guohui Deng, Microsoft https://microsoft.com, guohuideng@microsoft.com, w3cid 158258
Former Editor: Shubhie Panicker, Google https://google.com
Repository: w3c/device-memory
Abstract: This document defines a HTTP Client Hint header and a JavaScript API to surface device capability for memory i.e. device RAM, in order to enable web apps to customize content depending on device memory constraints.
Expand Down Expand Up @@ -69,9 +70,9 @@ The ABNF (Augmented Backus-Naur Form) syntax for the <code>Sec-CH-Device-Memory<
<h3 dfn>Computing Device Memory Value</h3>
The value is calculated by using the actual device memory in MiB then rounding it to the nearest number where only the most significant bit can be set and the rest are zeros (nearest power of two). Then dividing that number by 1024.0 to get the value in GiB.

An upper bound and a lower bound should be set on the list of values.
An upper bound and a lower bound should be set on the list of values. The range between the upper and the lower bounds should include the majority of device memory values but exclude rare device memory values to mitigate device fingerprinting.

NOTE: While implementations may choose different values, the recommended upper bound is 8GiB and the recommended lower bound is 0.25GiB (or 256MiB).
NOTE: The Implementations may set upper and lower bounds and adjust them dynamically over time. These bounds may even differ on different device types.

If <code>Sec-CH-Device-Memory</code> header field occurs in a message more than once, the last value overrides all previous occurrences.

Expand All @@ -90,8 +91,6 @@ If <code>Sec-CH-Device-Memory</code> header field occurs in a message more than
Sec-CH-Device-Memory: 1
</pre>

A full list of possible values should be as follows: 0.25, 0.5, 1, 2, 4, 8

Device Memory JS API {#sec-device-memory-js-api}
=======================================
<pre class="idl">
Expand Down