Link to github proposal
Developers currently have no mechanism to obtain the memory usage of their site.
This proposal provides an API with the following properties:
- Consistent semantics across different OSes and browser vendors
- No/minimal performance overhead when not used
- Very fast to compute
This proposal relies on process-specific memory counters. It provides the most utility when the site is being hosted in a process by itself. This is an implementation detail that depends on both the browser vendor and the browsing context [e.g. # of tabs that user has open]. Despite this limitation, the API is still expected to provide utility when collected in aggregate.
2 Likes
Would this be subject to the same “restriction” as the API for available memory? That is, rounding to the two most significant bits.
This API would be very useful for engineers at Facebook. We need to understand Facebook.com’s memory usage on real end-user devices and we need to be able to evaluate the effectiveness of our fixes in a reliable way. This API would be a great help.
2 Likes
There will be no rounding.
This seems okay from a privacy perspective since we’re limiting the API to only return non-null numbers when the website is being hosted by itself in a process.
The original repo looks like its been archived. Where does most updated proposal live?