You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NOTE: While implementations may choose different values, the recommended upper bound is 8GiB and the recommended lower bound is 0.25GiB (or 256MiB).
8GiB is the bare minimum for many AI applications, so knowing if a device has actually just 8GiB of RAM or more makes a huge difference. The meaningful values I heard when discussing this with engineering were 16, 32, and 64 GiB.
The current lower bound of 0.25GiB has become a tracking vector in itself. It would likely make sense to adjust to 2GiB as the lower bound as even low-end devices have caught up.
16GiB+ is still rare on mobile.
64GiB also still seems rare enough on desktop.
I wonder should be have separate limits for mobile (2GiB-8GiB) and desktop (2GiB-32GiB) because of that? Or would that be more confusing/limiting?
However, when this API was first launched, 8GiB was probably as rare on mobile so maybe going to 16 (or even 32) on mobile is no worse off than it was then (and certainly no worse off than 0.25GiB and 0.5GiB is now).
Does the spec need to enumerate the list of supported values? Could we not just define that the values are powers of 2, with a specified minimum value but no maximum? (and specific implementations could under-report if they find some reason to)
(FYI the Examples section also specifically says "A full list of possible values should be as follows: 0.25, 0.5, 1, 2, 4, 8")
I guess you need some upper/lower bound to merge small population of users together and not enable fingerprinting. Ideally that would come from a dynamic usage stat, but I guess just leaving the spec wording and updating the NOTE periodically, works?
I am planning to update the spec, giving rational and guidance on how the upper and lower bounds should be adjusted/decided as the memory on the device increase over time.
I think we can keep the restriction that the value must be a subset of {0.25 x 2^n} (because it has been there before and there is nothing wrong with it.
@tomayac could you raise a crbug for the Chrome implementation side now that the spec issues is resolved (or at least agreed and will be updated soon!).
@tomayac could you raise a crbug for the Chrome implementation side now that the spec issues is resolved (or at least agreed and will be updated soon!).
Activity
tunetheweb commentedon Jan 7, 2026
16GiB+ is still rare on mobile.
64GiB also still seems rare enough on desktop.
I wonder should be have separate limits for mobile (2GiB-8GiB) and desktop (2GiB-32GiB) because of that? Or would that be more confusing/limiting?
However, when this API was first launched, 8GiB was probably as rare on mobile so maybe going to 16 (or even 32) on mobile is no worse off than it was then (and certainly no worse off than 0.25GiB and 0.5GiB is now).
mmocny commentedon Jan 7, 2026
Does the spec need to enumerate the list of supported values? Could we not just define that the values are powers of 2, with a specified minimum value but no maximum? (and specific implementations could under-report if they find some reason to)
tunetheweb commentedon Jan 7, 2026
The spec currently doesn't "define" them, but does give recommendations:
So I guess there's two questions here:
mmocny commentedon Jan 7, 2026
(FYI the Examples section also specifically says "A full list of possible values should be as follows: 0.25, 0.5, 1, 2, 4, 8")
I guess you need some upper/lower bound to merge small population of users together and not enable fingerprinting. Ideally that would come from a dynamic usage stat, but I guess just leaving the spec wording and updating the NOTE periodically, works?
guohuideng2024 commentedon Jan 8, 2026
I am planning to update the spec, giving rational and guidance on how the upper and lower bounds should be adjusted/decided as the memory on the device increase over time.
I think we can keep the restriction that the value must be a subset of {0.25 x 2^n} (because it has been there before and there is nothing wrong with it.
tunetheweb commentedon Jan 15, 2026
Discussed in WebPerfWG on 15th Jan 2026 and agreed to update spec to make this implementor specific.
Will close this with #53
@tomayac could you raise a crbug for the Chrome implementation side now that the spec issues is resolved (or at least agreed and will be updated soon!).
tomayac commentedon Jan 16, 2026
We have https://crbug.com/454354290 already. I just made the bug thread aware of the spec change.
Emphasize the bounds can be dymanically adjusted by implements (#53)
tunetheweb commentedon Jan 23, 2026
This change will be included in Chrome 146: https://chromestatus.com/feature/6330376953921536