Browser library bundle size is very large.

[threehams]

Hi! While looking into using Datadog RUM, I noticed the bundle size is much bigger than I'd expect: @datadog/browser-rum bundle analysis. Currently it's about half the size of our entire UI component library, including styles.

Most of this comes from @datadog/browser-core and its dependencies.

While there's a lot of code in the packages themselves, the size is mostly inefficiency in dependencies and bundling. This is good! It's the easiest to cut down.

Likely highest gains:

• Inline merge and assign functions in the project instead of using lodash. The two lodash imports account for almost 25% of the total size.
• Consider switching from tsc to rollup, possibly using tsdx to save headaches. Rollup is specifically designed for building self-contained libraries, and will avoid the tslib dependency (the second largest after lodash).

[bcaudan]

Hi @threehams, thanks a lot for your feedbacks.

We have not put too much effort on bundle size analysis for now but it is definitely something that we have planned to work on. Thanks for pointing that up.

[bcaudan]

Hello,

Thanks to @thibthib, lodash dependencies have been remove with #396. It is available in 1.12.0 version.

[isaachinman]

I've just pulled v1.25.2 into a project, and was also surprised at the size – still 30kb of minified JS.

@bcaudan I would be happy to contribute if you would like to point me in the right direction.

[vikingair]

Update: According to Bundlephobia and I also tested it in my projects version 3.9.0 is now at almost 40 kB gzipped. That makes a significant amount of all optimized apps. Roughly 25% my total bundle size.

Could you somehow put a little more focus to the bundle size?

[threehams]

We've removed browser logging and RUM from our project due to the bundle size. It doesn't make sense to slow down a page in order to check if it's fast.

Bundle size is something that needs monitoring to keep under control. There are a lot of projects out there to do this.

[bcaudan]

Hello,

Since version 3, the RUM SDK also include session replay logic which has legitimately increased our RUM bundle size. In order to avoid this size bump for customers who don't want to use session replay, we provide a browser-rum-slim version which is smaller.

You can find links about this bundle in the packages section of the README.md.

[vikingair]

@bcaudan I was not aware of a smaller variant. Thanks for the hint. How likely is the chance that the slim becomes even smaller? 😁

[BenoitZugmeyer]

We just realized an audit of our SDK bundled size. Here are the main efforts that we will work in the coming weeks/months:

• [x] #1335 Drop old browsers support when computing stack traces. While the SDK support only IE11 and newer browsers, we still have some code to support very old browsers when computing stack traces. Let's remove it.

• [x] #1354 Tweak build-env setup to improve dead code removal. We currently have build flags to produce slightly different bundles for tests. This setups could be improve to allow more dead code removal in release bundles.

• [x] #1364 Use const enum when possible. We currently have large TS enums that are used accross the SDK, using const enums would help to reduce the bundle size.

• [x] #1347 Remove TSLib usage. We barely use it and could cause a big size overhead if it's not tree-shaken (depending on NPM users build setup)

• [ ] Avoid using class syntax. This syntax is hard to mangle, especially when transpiled to ES3

• [ ] Avoid using optional chaining and nullish coalescing operators, which often produce more code than expected when transpiled.

Other notes:

• we experimented using another bundler (ex: rollup), and it didn't have a significant impact size-wize. We are using a custom ESLint rule to ensure that most of our codebase is side-effect free and can be tress-shaken by terser almost as well.

• we are considering using code-splitting, so various parts of the SDK could be loaded only if needed. This would be a breaking change, so not actionable right now, but definitely something to keep in mind when the occasion presents itself.

[vikingair]

@BenoitZugmeyer Nice. Thank you very much for so much transparency ⭐

Do you also consider to ship a variant that doesn't support IE11? In most projects, we stopped supporting it, so we could possibly benefit here as well.

[BenoitZugmeyer]

@fdc-viktor-luft We did consider creating a package supporting only ES6 syntax. It didn't yield significant-enough results to justify maintaining such package right now. Because IE11 will be retired in june, we will reconsider it and may drop IE11 altogether.

[mb21]

We don't even need RUM at the moment, but only some basic logging in the browser, and with datadog on the server we are happy, so it would be a natural choice.

But already browser-logs alone is 14.2kb gzipped :-( I'm guessing mostly due to what's in browser-core? If so, code-splitting would be welcomed a great deal.

Or is there a documented API for logging events, similar to https://bugsnagerrorreportingapi.docs.apiary.io/#reference/0/notify/send-error-reports, so that we could roll our own minimal version of browser-logs?

[bcaudan]

But already browser-logs alone is 14.2kb gzipped :-( I'm guessing mostly due to what's in browser-core?

Indeed, from bundlephobia link, browser-core represents 76,3% of browser-logs size.

If so, code-splitting would be welcomed a great deal.

We could consider extract some features as plugins at some point but it is not in our current priorities.

Or is there a documented API for logging events, similar to https://bugsnagerrorreportingapi.docs.apiary.io/#reference/0/notify/send-error-reports, so that we could roll our own minimal version of browser-logs?

Yes, you can have a look at logs api.

[mb21]

Thanks for the reply!

We could consider extract some features as plugins at some point but it is not in our current priorities.

I didn't look at the source and the build process, but shouldn't webpack's tree-shaking take care of eliminating most of the things from browser-core when you build the minified production build of browser-logs? assuming you do things correctly that is...

[bcaudan]

shouldn't webpack's tree-shaking take care of eliminating most of the things from browser-core when you build the minified production build of browser-logs?

it should eliminate unused things, but browser-core contains code that is shared by logs and rum so I don't expect much code to not be used by logs.

[robertleeplummerjr]

Last time I checked webpack's treeshaking works with ES6+ only.

[robertleeplummerjr]

Looking at the production bundle for a webview, there are lot of large strings, and prototype stuff that can really take up a lot of space.

[shadiramadan]

@BenoitZugmeyer What's the status on this? Any updates?

[BenoitZugmeyer]

While this is still a topic we have in mind, we don't have further work planed just yet appart from removing IE support, which would allow us to use shorter ES6 syntaxes.

[jqlee85]

Don't mean to pile on, but want to add a +1 to these concerns about package size. Even browser-rum-slim is 27kb gzipped, and appears to be growing with each release. Would love if this could be prioritized.

[MikeEtlingerRM]

Hey folks,

I agree that using this package comes at a great cost to our end users only so we can gain observability into the UX metrics that we care about.

There's a lot of focus on compressed bundle size but I'd like to call out that uncompressed bundle size matters as well. According to The Cost of JavaScript, low powered devices are CPU bound, not network bound.

That means that even if your package is 10kb gzipped/brotli compressed over the wire, if the unpacked size is 100kb, that still comes at a cost for parsing and executing.

At present :

@datadog/browser-rum: 144.5 kB MINIFIED -- 48.1 kB MINIFIED + GZIPPED @datadog/browser-rum-slim: 91.9 kB MINIFIED -- 30.5 kB MINIFIED + GZIPPED

If you look at companies like Speedcurve that are performance focused, you'll see an entire section about performance in their docs.

The important part:

Most SpeedCurve users know that third party scripts are a major culprit in making websites slower. We understand that putting our script on your page is a big ask, so we go to great lengths to ensure that lux.js does not affect the performance of your pages.

lux.js is something like 8kb-15kb which is very reasonable for comparison. 30kb/92k uncompressed is a bit of a non-starter for any company that takes web performance seriously.

Apologies if this comes across as a dig or a +1 but it's important to note the impact to our users.

[jame-earnin]

From Lighthouse Treemap, @datadog/browser-rum tends to be the dependency with the most unused codes.

[kurtextrem]

According to bundlephobia the size of @datadog/browser-rum-slim increased by 11 kB (non-gzip) from version 4.37.0 to 4.50.0, that's quite a hefty increase. All the way from 4.29.0, the size kept growing. 3.11.0 is at 22.2 kB (gzip) the smallest one.

[alexmanzo]

Hi there, adding another +1 on this thread. It's tough to swallow 50kB+ on the @datadog/browser-rum package.

It's disappointing to see that after four(!!) years of this issue being open there seems to have been little effort in prioritizing it and the package(s) have gotten progressively larger over that time.

Please consider spending some engineering time on this!

[dannyrb]

How are folks handling this? The size of this package is very large. Are folks pivoting to async loading instead of relying on sync loading because of the performance implications?

[jfsiii]

Are folks pivoting to async loading instead of relying on sync loading because of the performance implications

We load asynchronously but performance is still an issue.

Here's the results from running Lighthouse on a mobile login page, where you can see it takes 400+ ms

The shared/chunk-* script above it contains all of React, React Router, and Remix and still takes ~50ms less CPU time