Function `getBrowserProperties` is too expensive

[rvetere]

Describe the bug My company is currently working to improve INP (Interaction to Next Paint) metrics all over our e-commerce platform. During our analysis, we see track() calls in snowplow that just consume too much time executing.

To Reproduce Create a performance profile of an interaction where tracking is involved with a CPU throttling of 4x - 6x. Zoom into the interaction to see the callstack, as example like this: -> The track() function can eat up to 30% of the entire interaction task! This means, the user has to wait for the track() call to be finished until he sees the result he wanted in the browser.

Expected behavior The track() function should be as fast as possible, that no one has to think about it's impact regarding performance.

Desktop (please complete the following information):

• OS: MacOS Sonoma 14.3.1
• Browser: Chrome
• Version: 119.0.6045.105

Additional context I have found the reason why the track() function is expensive. It is related with the internal beforeTrack() method which calls getBrowserProperties(). While getting these browser properties, very expensive browser calls are involved like document.body.clientHeightor similar. I'm currently working on a change that would fix that by involving a ResizeObserver approach, moving the expensive calls to another place in the call stack where it doesn't affect the track() call anymore.

I would love to hear from you guys what you think about my approach and if this is feasible. Check out my PR to see a "before" and "after" comparison of the measured flame graph: https://github.com/snowplow/snowplow-javascript-tracker/pull/1294

[davidher-mann]

@matus-tomlein have you already had the chance to take a closer look at this optimization? Since the INP (Interaction to Next Paint) officially became a Core Web Vital today, it is all the more important to keep the performance impact of the browser tracker as low as possible.