Bundle size increases significantly

[EduardDopler]

Description

We noticed that the bundle size of the loader keeps increasing. Comparing version 1214 to 1222:

• v1214: 31 kB (loader) + 46 kB (nr-spa-x.min.js) = 78 kB
• v1222: 52 kB (loader) + 10 files (59 kB, tested on Chrome 109) = 111 kB

This means an increased JS parse size of +68% for the critical (blocking!) JS loader and an overall increase of +42%. I do understand that you included new valuable features. But especially in light of the recent announcement that the loader supports only browsers with ES6 support and, more so, only the last 10 versions of Chrome, Edge, Safari, and Firefox, I find it difficult to justify the bump in file size.

Looking at the loader file, there are still checks and fallback values for Internet Explorer and there are specific checks for certain JS features which are all present in ES6-based browsers.

Are you using something like browserslist to detect necessary polyfills? If I run browserslist with "last 10 chrome versions, last 10 edge versions, last 10 safari versions, last 10 firefox versions" I get:

> chrome 112-103, edge 112-103, firefox 112-103, safari 16.4-15.1
What is more concerning, loader version v1223 which improves your development experience, introduce another 20% bundle size bump (50.9 kB vs. 60.3 kB).

The most recent v1225 has a blocking loader file size of 66 kB - that's an increase of 112% compared to v1214.

More data:

• v1226 has a blocking loader file size of 66 kB - that's an increase of 112% compared to v1214.
• v1227 has a blocking loader file size of 63 kB - that's an increase of 103% compared to v1214.
  • This is the first release where the file size of the loader file didn't increase.
• v1228 has a blocking loader file size of 63 kB - that's an increase of 103% compared to v1214.
  • approx. same file size, not worse, not better.
  • 11 lazy loaded files (non-blocking), totalling additional 69 kB.
  • the whole bundle (63 kB blocking + 69 kB non-blocking) weighs 132 kB on current Chrome. That's +70% for the overall JS parse size (compared to v1214).

Could you please analyse?

See also https://fosstodon.org/@quotingeddie/109859119757022872

Steps to Reproduce

Inspect and compare bundle sizes

Expected Behavior

Minor bundle size increases are expected as new features are introduced. But double the bundle size is not acceptable. Especially in the blocking script which prevents the site from continue loading.

Relevant Logs / Console output

—

Your Environment

Occurs on every environment running newer versions of the NewRelic browser agent.

Additional context

This problem was reported to Premium Support in February (case #00090825). The support team referred me to the NewRelic Jira; I created ticket NEWRELIC-6940 but received no replies. Your Jira is closing for public eyes today though, this is why I'm taking this here.

[workato-integration]

https://issues.newrelic.com/browse/NEWRELIC-8350

[metal-messiah]

Hi Eduard,

Thanks for reaching out about this. The agent structure has undergone some pretty significant shifts recently to allow for some modifications for future efforts around more modular "dynamic" feature modules. We have an upcoming initiative to clear some of the bloat out that arose from that process, as well as prioritize the removal of vestigial features and shifting toward more async loading where feasible.

While an increase in size over time as new features are added is inevitable, we want to still try to keep loader sizes small. Blocking JS code size in our agent will continue to be a focus in the coming quarter.

To help evaluate this, are you having tangible load performance issues arising from the blocking portion of the agent code? We have not heard reports of this as of yet, but information such as that helps prioritize bundle-size work.

As for target support, you may benefit from implementing our new NPM entry point (@newrelic/browser-agent) and building it into your app with your build tools. While cleanup still needs to happen in various places, it will at least allow you to target the browsers you care about. Within the NPM wrapper, you can also specify which features to use -- which can a pretty significant impact on bundle size if there are features you don't currently utilize.

Cheers

[EduardDopler]

Thank you @metal-messiah for your quick response! Good to hear you have bundle improvements on your backlog. Looking forward to seeing those come to fruition and read about them in the change logs.

Unfortunately, we don't have tangible perf impact comparisons between old and new script structure, as we mostly exclude NewRelic itself from lab perf tests as the instrumentation makes attribution harder.

I did try building the browser agent myself and I could see some improvements in terms of bundle size (49.5 kB vs. 52.6 kB for the initial script) but I ended up with much more separate (lazy loaded) files than you serve. You somehow have aggregated scripts. I wasn't able to reproduce them.

[bjfield]

@EduardDopler, we are glad to hear you were able to see some improvements via the NPM package. Thank you for reaching out with your questions and thoughts on the changes in size. We are continuing to keep loader size in mind as we make changes to the agent.