Add browser_memory_used metric

[dgzlopes]

It's pretty usual for modern front-ends to be real memory hungry.

Maybe this could be a good metric to track performance-wise!

[imiric]

Thanks for the suggestion. As mentioned on Slack, we think it's a good idea, we just need to flesh out some details.

Here are my notes from Slack:

---

CDP has a Memory domain which might help us to gather this information. And there's the Performance.memory API, but only for Chrome.

So hopefully we can use one of those and not have to implement it ourselves at the process level, which could get messy on all platforms. :crossed_fingers:

There's also a Performance CDP domain, which has some other interesting data. Puppeteer exposes it as page.metrics(), but Playwright removed it a couple of years ago for some reason.

---

One pending question I have is when should this metric be emitted? Currently we emit metrics on requests/responses and some CDP events. But I think the usefulness of this metric would be if it's emitted periodically in the background at a set interval. Is this correct, or do you have other suggestions?

[dgzlopes]

But I think the usefulness of this metric would be if it's emitted periodically in the background at a set interval. Is this correct, or do you have other suggestions?

From my POV, yeah, that makes sense. That way, even with no requests, a user should be able to capture/understand how the browser behaves.

[ankur22]

But I think the usefulness of this metric would be if it's emitted periodically in the background at a set interval. Is this correct, or do you have other suggestions?

Would it be useful to measure the memory usage before and after actions are performed? Actually what if there is an animation running or a video 🤔

[imiric]

@ankur22 If we implement Page.metrics() like Puppeteer has, the script can get the value of JSHeapUsedSize and emit a custom metric sample any time it's needed. This would track JS memory usage per page, which is usually the highest consumer, but as you say, I'm also not sure if the memory used by <video> or <canvas> elements (e.g. WebGL) would show up in JSHeapUsedSize.

So I think we should first agree on the scope of the memory tracking that we want to expose, and then on how/when to emit this new metric.

If we only care about JS heap size (per page), then we should implement Page.metrics() first, and allow the user to create custom metrics and emit samples as they need it. I think this would fulfill Daniel's suggestion of tracking frontend memory usage.

If, OTOH, we want to track the memory usage of all Chrome processes on a system level, then we can't get this via CDP, and would need a custom implementation of it, which is very messy, as determining that is different on each platform.

To simplify, I think we should settle for whatever we can get via CDP and expose it via Page.metrics(), and not do periodic metric emission of an internal metric, but allow the user to create one and emit it when needed. WDYT?