Two memory values, two resolutions
navigator.deviceMemory is the standard way for a page to learn about memory, and it is deliberately coarse: a 12 GB laptop, a 16 GB desktop and a 64 GB workstation all report 8. performance.memory is older and non-standard but still present in Chromium-based browsers. Its usedJSHeapSize and totalJSHeapSize change constantly; its jsHeapSizeLimit is a constant for a given browser on a given machine, set by V8 from the physical memory the OS reports.
| Usable RAM | jsHeapSizeLimit (64-bit desktop Chrome) | deviceMemory |
|---|---|---|
| 7.5 GB | 4,127,195,136 | 8 |
| About 7.8 GiB (sold as 8 GB) | 4,303,880,192 | 8 |
| 16 GB, 32 GB | 4,395,630,592 (cap) | 8 |
A machine sold as 8 GB usually reports a little under 8 GiB because firmware and integrated graphics reserve part of it, so its limit lands just below the cap.
How the two values constrain each other
A session that reports deviceMemory 4 should have a heap limit from the lower range, not the cap. A session that reports 8 should have one of the top values. A heap limit at the cap with deviceMemory 2 describes a machine that does not exist. The heap limit also separates machines deviceMemory lumps together: an 8 GB laptop and a 16 GB desktop both say 8, but only one reports the cap.
Bot-check widgets read it. One widely deployed widget reads performance.memory inside a probe that also builds isolated iframes, and sends the limit to its server; see what a challenge widget collects.
Changing one without the other
A common pattern is to override navigator.deviceMemory and leave performance.memory alone. On a 32 GB server presenting a 4 GB laptop, the heap limit stays at the cap: one value says small machine, the other says large. Overriding the heap limit in JavaScript has the usual problems of page-level patches, covered in native function integrity checking, and has to happen in every realm, workers included.
Memory shows up in more places than these two: in the storage quota, in how many workers a page can run in parallel and in how a proof of work performs. The consistent approach is to present one machine whose memory is reflected everywhere, as described under hardware fingerprinting. A managed web data API that runs browsers on real, matching hardware gets this for free.