Device Memory

### WebKittens @rniwa @othermaciej ### Title of the proposal Device Memory ### URL to the spec https://www.w3.org/TR/device-memory/ ### URL to the spec's repository https://github.com/w3c/device-memory/ ### Issue Tracker URL _No response_ ### Explainer URL _No response_ ### TAG Design Review URL https://github.com/w3ctag/design-reviews/issues/190 ### Mozilla standards-positions issue URL https://groups.google.com/g/mozilla.dev.platform/c/cfydu35XdnY/m/3IqYn0oJAQAJ ### WebKit Bugzilla URL https://bugs.webkit.org/show_bug.cgi?id=199084 ### Radar URL _No response_ ### Description Moving this over from this issue on the repo: https://github.com/w3c/device-memory/issues/24 as doing some housekeeping over there. @rniwa previously opened that issue with: > We don't support this API because: > > - RAM is not a direct estimate of whether the device can run a website with good performance - Some generations of iPads, for example, has an old generation CPU with more RAM. > - Amount of RAM device has is no indicative of how much RAM a website can use - the amount of memory WebContent process can use is > limited by a number of variables beyond just the amount that's physically available on a given device. > - It adds a new reliable fingerprinting surface - 100% reliability to disambiguate one device from another based on RAM size is a new fingerprinting surface we don't want to add. Let me know if this opinion has changed, but even if not, it's better to have the position listed in this repo IMHO. In which case feel free to close this issue with the appropriate labels. From the Chrome point of view, I'd reply to above comments with: > - RAM is not a direct estimate of whether the device can run a website with good performance - Some generations of iPads, for example, has an old generation CPU with more RAM. Agreed, but it is one of the more important signals. In my own experience [there is a clear correlation with Device Memory and web performance](https://www.smashingmagazine.com/2022/03/signals-customizing-website-user-experience/#device-capability-signals). Discussions with multiple RUM providers, when I recently worked on updating the limits in Chrome, have shown the same correlations. > - Amount of RAM device has is no indicative of how much RAM a website can use - the amount of memory WebContent process can use is > limited by a number of variables beyond just the amount that's physically available on a given device. I also agree to a point. Again, this is one signal. We see two use cases for this API—both of which we hear successful use of in the wild: - To adapt website capabilities for lower end, or higher end. Often sites choose a cut off (e.g. below 2GB gets a lite version), rather than fine tune to every value. But different sites may choose different "cut offs" so a low/high signal is less useful here. - To explain performance metrics for analytics (e.g. there is an decrease in performance despite no changes, but this correlates with an increase in users with lower RAM — the reason for the degradation can therefore be explained). > - It adds a new reliable fingerprinting surface - 100% reliability to disambiguate one device from another based on RAM size is a new fingerprinting surface we don't want to add. The values are coarsened and capped to reduce the risk of finger printing. Recent updates to the spec give the user-agent control over how to cap the values exposed. In the [Webkit bug](https://bugs.webkit.org/show_bug.cgi?id=199084) @othermaciej suggested: > Maybe we could expose 2GB as a fixed value for macOS, iOS and iPadOS devices, since all currently supported models would likely meet the true "high end" criteria. That would now be permitted by the updated spec. An extreme interpretation of the capping, but permitted none-the-less. Though in these days you may wish to choose a higher value than 2GB and review that over time. Thanks for your consideration.