Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Browser library bundle size is very large.

See original GitHub issue

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).

Issue Analytics

  • State:open
  • Created 3 years ago
  • Reactions:27
  • Comments:17 (2 by maintainers)

github_iconTop GitHub Comments

BenoitZugmeyercommented, Feb 2, 2022

@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.

BenoitZugmeyercommented, Mar 8, 2022

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

  • #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.

  • #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.

  • #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.

  • #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.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Small Bundles, Fast Pages: What To Do With Too Much ...
This post will explain why bundle size matters and recommend tools and ... Large amounts of JavaScript negatively affect site speed in two ......
Read more >
Slimming down your bundle size - LogRocket Blog
Bundle optimization #2: Install lighter-weight alternative libraries. React's bundle size is still a bit large (124KB in our project), even ...
Read more >
Optimizing JavaScript bundle size - DebugBear
It's easy to keep adding new packages and lose track of the size of your Webpack, Parcel, or Rollup bundle. But large JavaScript...
Read more >
5 Methods to Reduce JavaScript Bundle Size - Bits and Pieces
Today, we use JavaScript heavily in web development, and we can find many applications with large bundle sizes. However, beyond a certain ...
Read more >
How CommonJS is making your bundles larger -
CommonJS modules are very dynamic, which prevents JavaScript ... bundle size is still the number one reason for making browser apps slower.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found