Presumably the results translate well enough to other browsers, barring some idiosyncrasies with certain features (e.g, canvas has a memory leak in certain situations in Safari).
I work on web.dev and would like your feedback on how we're handling cross-browser compatibility information. I'm aware that it's the biggest frustration for web developers based on the MDN DNA report [1] (overall needs ranking on page 19, items 1, 3, 4, 5).
* Is there an ideal location for cross-browser information? E.g. top of page, bottom of page, middle of page.
* Are we communicating the information effectively? E.g. is there anything important that we're missing.
* (On a more general note) Is there specific guidance related to cross-browser compatibility that you think would be helpful for us to write about? The more specific, the better.
> * Is there an ideal location for cross-browser information? E.g. top of page, bottom of page, middle of page.
Ideally, it'd be right at the top of the article so I understand immediately that this isn't production-ready yet and I can read the rest of the article in that light (as something I can experiment with potentially, via the origin trial).
Your first point surely applies to introducing any browser-specific feature -- and features are generally introduced to one or two or all browsers before becoming part of a standard.
"A website, with JS enabled, can tell what version of what browser you have" is a sailed ship, right?
Secondly, I would be surprised if memory behavior does not differ between certain setups.
In my experience of profiling various web apps, memory usage will differ between sessions of the same app on the same machine in a series of automated test runs with no changes to the code or setup. Web apps are terrible at managing memory and they leave all manner of things lying around that make it hard to get a deterministic number you could use for fingerprinting a user's browser.
It is important to keep in mind that the API only accounts for the objects allocated by the web page itself and does not expose the total memory usage of the browser.
The only information that can be extracted using the API is the browser version (because an object representation may change between different versions) and the bitness of the browser (32-bit vs 64-bit). This information is already exposed by other existing APIs (e.g navigator.userAgent, navigator.deviceMemory)
Thus the API does not add _new_ data bits for tracking. The final spec of the API may include additional protection against fingerprinting. For example, adding a small amount of Gaussian noise would make browser version inference much more difficult.
One issue I came across is that any loaded Chrome extensions get included in browser heap/memory snapshots and measurements. Your site can appear to be more bloated that it actually is. Since Chrome user profiles came out, I created a blank user without extensions, similar to incognito, but without the history clearing effects. it would be nice to track memory/snapshots without needing to do that, to allow using other dev tool extensions etc.
As an example, If I open dev tools and check memory usage of Hacker News, it's 4Mb in my current Chrome user, but in a clean user with no extensions it's <1Mb.
Similar to this, I’ve often wished for an onError that automatically excludes browser extensions somehow, to try and reduce the noise. There’s only so much I can control, and errors triggered by page extension code should somehow be reported back to the extension instead. If we had that, we wouldn’t need as much of this list of errors to ignore: https://github.com/tlk/window.onerror-ignore
I must be missing something because I only see 37 lines and that’s a very short list. On an extremely small website’s checkout page alone we have seen ten times that.
Good point, I posted this from a phone, so I didn’t see how long the list was: I was speaking from my own experience of having to deal with more such errors.
I regularly encounter scenarios where extensions break sites, or at least frustrate debugging efforts. I generally make sure all extensions are off prior to doing anything development-related.
18 comments
[ 2.9 ms ] story [ 49.8 ms ] thread> The performance.measureMemory() API is available as an origin trial in Chrome 83. The origin trial is expected to end in Chrome 84.
Chrome 83 will be released as stable on May 19: https://www.chromestatus.com/features/schedule
* Is there an ideal location for cross-browser information? E.g. top of page, bottom of page, middle of page.
* Are we communicating the information effectively? E.g. is there anything important that we're missing.
* (On a more general note) Is there specific guidance related to cross-browser compatibility that you think would be helpful for us to write about? The more specific, the better.
[1] https://mdn-web-dna.s3-us-west-2.amazonaws.com/MDN-Web-DNA-R...
Ideally, it'd be right at the top of the article so I understand immediately that this isn't production-ready yet and I can read the rest of the article in that light (as something I can experiment with potentially, via the origin trial).
Question: can this functionality be exposed in Lighthouse/PageSpeed audit results?
First of all it tells the page if you run the dev version of Chrome with a certain version.
Secondly, I would be surprised if memory behavior does not differ between certain setups.
"A website, with JS enabled, can tell what version of what browser you have" is a sailed ship, right?
In my experience of profiling various web apps, memory usage will differ between sessions of the same app on the same machine in a series of automated test runs with no changes to the code or setup. Web apps are terrible at managing memory and they leave all manner of things lying around that make it hard to get a deterministic number you could use for fingerprinting a user's browser.
It is important to keep in mind that the API only accounts for the objects allocated by the web page itself and does not expose the total memory usage of the browser.
The only information that can be extracted using the API is the browser version (because an object representation may change between different versions) and the bitness of the browser (32-bit vs 64-bit). This information is already exposed by other existing APIs (e.g navigator.userAgent, navigator.deviceMemory)
Thus the API does not add _new_ data bits for tracking. The final spec of the API may include additional protection against fingerprinting. For example, adding a small amount of Gaussian noise would make browser version inference much more difficult.
One issue I came across is that any loaded Chrome extensions get included in browser heap/memory snapshots and measurements. Your site can appear to be more bloated that it actually is. Since Chrome user profiles came out, I created a blank user without extensions, similar to incognito, but without the history clearing effects. it would be nice to track memory/snapshots without needing to do that, to allow using other dev tool extensions etc.
As an example, If I open dev tools and check memory usage of Hacker News, it's 4Mb in my current Chrome user, but in a clean user with no extensions it's <1Mb.
The new API excludes the objects allocated by extensions, so the results should be more stable and actionable compared to the existing tools.
I filed a feature request for DevTools heap snapshot to do the same: https://bugs.chromium.org/p/chromium/issues/detail?id=107093...