Downsize your JavaScript: Mastering Bundler Optimizations

Filip Sobol — Tue, 17 Dec 2024 11:00:00 +0000

Introduction

Over the past 15 years, the JavaScript ecosystem has expanded rapidly, introducing countless tools to make development easier. But these tools come at a cost: growing bundle sizes. In fact, data from the HTTP Archive shows that the average amount of JavaScript transferred per page has surged from 90 KB in 2010 to 650 KB in 2024 (source).

Despite growing adoption and advances in compression, this trend shows no signs of slowing. As we keep adding features, the challenge remains: How can we ship less JavaScript?

Oddly enough, the solutions are both easy and hard. The easy part is the project-level tweaks that can yield quick wins. The hard part is making a lasting impact, which requires a community-wide change to improve bundlers, libraries, and tools.

This article focuses on actionable improvements for your projects, covering:

Bundlers: Optimizing build tools to reduce output size.
Libraries: Choosing and using external dependencies wisely.
Your project: Practical steps to shrink your bundles.

Future articles will address ecosystem-wide improvements we can make, but for now, let’s tackle how these factors contribute to bloated bundles — and how to manage them.

Why optimizing JavaScript matters

JavaScript is the engine behind the modern web interactivity, but it isn’t free. JavaScript is the most computationally expensive resource your browser has to handle. It’s often the bottleneck that determines whether a page feels fast or sluggish, as a bloated bundle can block rendering and degrade overall performance.

The bigger the JavaScript bundle, the longer it takes to load, parse, compile, and run. This delays everything else — like showing content or letting users interact with the page. For someone on a high-end laptop with a fiber connection, this might be a minor annoyance. But for someone on a low-powered phone or a spotty network, it can be the difference between staying or leaving your site entirely.

The first step at reducing the JavaScript bundle size is tree shaking (or “dead code elimination”), which most bundlers do out of the box. But are all bundlers equal?

Bundlers

Bundling in JavaScript has come a long way — from manual concatenation and task runners to sophisticated bundlers. Today, bundler performance is a key focus, with developers prioritizing faster builds. However, build speed isn’t everything. Equally important is the size of the bundles they produce, as smaller bundles translate to faster loading times for users.

In search for better performance, we have moved from writing bundlers in JavaScript to languages like Rust and Go. This switch required writing them from scratch, so every feature and optimization that was present in the old bundlers has to be reimplemented. In the long run, this will likely pay off. However, in the short term, it means that they are missing some features that JavaScript bundlers had years to develop, like good tree shaking or minification. And these are the very features that can help us minimize bundle size.

Benchmark

Of course, talk is cheap, so let's look at the numbers, shall we?

Let's compare eight popular libraries and bundle them with seven popular bundlers. To keep things fair, I used:

Node 22.12.0
Mean build time from 10 runs (with 2 warm up runs) using node --run
Configurations that remove all comments, including licenses, since bundlers handle them differently

You can check out the benchmark setup repository for the exact configurations.

Bundlers tested:

esbuild (0.24.0) with built-in minifier
Parcel (2.13.2) with built-in minifier
Rolldown (0.15.1) with rollup-plugin-esbuild minifier
Rollup (4.28.0) with rollup-plugin-esbuild minifier
Rspack (1.1.5) with built-in minifier
Vite (6.0.3) with built-in minifier
webpack (5.97.1) with swc minifier

Note that at the time of writing, Rolldown is still in alpha, so it's at the disadvantage and its results will likely improve over time.

Libraries tested:

chart.js
ckeditor5
d3
handsontable
luxon
mobx
tippy.js
zod

These libraries vary in size and features — some can function almost like standalone applications.

Build speed

Let's start with build speed, as this is something that developers seem to care a lot about. When bundling all of these libraries together, esbuild is the winner, with the build time of 229 ms. Comparing it to the slowest build time of 7.78 seconds, that's over 34 times faster.

Based on these results, we can group the bundlers into three categories:

Blazingly fast™: esbuild, Rolldown, Parcel with cache enabled (<1 second, with esbuild under 250 ms).
Faster: Rspack (~2.5 seconds).
Slow: Parcel without cache, Vite, Rollup, webpack (5+ seconds each).

The differences are stark. For instance, Rolldown and Rspack are 7× and 3× faster than their older counterparts, Rollup and webpack, respectively — all while maintaining theoretical backward compatibility. Switching to these newer bundlers could boost productivity significantly on larger projects.

Output size

When it comes to output size, the differences aren’t as drastic as build times, but they still matter.

Aggregated results

When bundling all eight libraries together, Rollup and Vite are the winners, with the output size of 2081 KiB. Comparing it to the largest output size of 2491 KiB, that's over 19.5% smaller output.

A 19.5% difference in output size is substantial: on a slow 3G connection, the smallest bundle might take around 5.7 s to download, while the largest closer to 7 s. Parsing and execution times also scale with bundle size, so the real-world difference could be even more noticeable.

Based on these results, we can group the bundlers outputs into three categories:

Smallest: Rollup, Vite, esbuild, Rolldown, and Parcel (~2081–2162 KiB).
Okay: webpack (~2317 KiB).
Big: Rspack (~2491 KiB).

With this particular set of libraries, webpack and Rspack produced the largest bundles. However, there's a reason for this. In the later section, we will look at it in more detail and introduce an optimization that will help reduce the bundle size in both webpack and Rspack, bringing webpack bundles up to par with Rollup and Vite.

Individual libraries

Aggregated results don't paint the whole picture because it's unlikely that you will use all the libraries listed above in your project. What is more interesting is how these bundlers handle the individual libraries.

For a library like chart.js, the choice of bundler can dramatically affect the output size, with differences reaching 70%. This highlights the importance of testing bundlers with your specific dependencies. In most other cases, the difference is much smaller, reaching up to 22%.

Moreover, while in aggregate webpack ended up in the middle, it performed the best in 4 out of 8 cases. However, because it performed much worse when bundling handsontable and chart.js, it ended up where it did. This means that, depending on the libraries you use, webpack can be a good choice.

On the other side of the spectrum, we have Rspack. It performed the worst in 5 out of 8 cases, which produced a bundle much larger than the other bundlers.

Bundle size vs. output speed

As shown, some bundlers may produce larger builds than others, and the results may also depend on the libraries used.

When choosing a bundler for your project, or migrating from one to another, don't just compare build times — compare the resulting bundle sizes as well. You may find yourself trading faster builds for larger bundles. You should also test it with the libraries you use to make sure it works well in your specific case and setup.

For example, after Angular switched from webpack to esbuild, some developers reported that the size of an empty Angular app increased by around 20 KB. This highlights perfectly the build-speed vs. bundle-size trade-off.

It's not to say that you should not look at the build speed because it's important for developer productiveness and happiness. There's also a correlation between the CI build time and the time needed to merge the code.

When choosing a bundler, look at the features it provides first. Then aim for a balance between build speed and bundle size. Select the bundler that can produce possibly the smallest bundle in the time that you are comfortable with.
Test a few representative libraries from your project. If your dependencies make up most of your codebase, the differences you see in these benchmarks can be a good predictor for your situation.

Libraries

Next on our list are external libraries, which often make up the bulk of your JavaScript bundle. In many, if not most, applications I have worked on, they accounted for the majority of the bundle size. That's why it's so important to choose (and use) them wisely.

Gold but old

Many of us have installed libraries like lodash, axios, or moment just to use a single function — leading to bloated applications. These libraries are great and historically important, but as they became more popular, lighter alternatives were created, and some of their features were added to the language itself.

We can take advantage of that. I could list native APIs or newer and smaller alternatives for these libraries, but there are already many articles covering that. And there are so many other libraries that it would be impossible to cover them all.

That's why I will only give you a general advice to take a look at the libraries you use and see if you can remove or replace them with native APIs or smaller alternatives. The YOU MIGHT NOT NEED * website is a great resource to get started.

Bundler-specific optimizations

Bundlers support different features and this also can have a significant impact on the output size. We already saw this in the initial benchmark, where webpack and Rspack produced the largest bundles. But there's a reason for this.

Internally, the handsontable library uses moment to handle dates, which uses dynamic require() calls to load the locale files. Since dynamic require() calls depend on runtime values, webpack and Rspack bundle all locale files just in case they are needed. Depending on your setup, this may be what you want.

In most cases, you won't need all the locales, just the ones you choose. That's why we can configure webpack and Rspack not to bundle them, which significantly reduces the bundle size.

// webpack.config.mjs / rspack.config.mjs

export default {
  module: {
    noParse: [ /moment.js/ ]
  }
};

This small change reduced the size of the handsontable in both bundles by almost 20% and brings the webpack bundle with all dependencies up to par with Rollup and Vite.

Optimized installation paths

Most libraries aren’t optimized for size by default, but some offer special installation paths or partial builds. Even among the libraries in our test, chart.js, handsontable, and ckeditor5 offer a way to reduce the size of the library by only including the parts you need. Let's look at ckeditor5 as an example.

The default installation path results in the bundle size between 666 and 786 KiB. However, if we use the optimized installation path, the bundle size drops to between 603 and 659 KiB. This is a 7% to 23% reduction in size, depending on the bundler.

Duplicated dependencies

Another thing to look out for are duplicate dependencies. This is a surprisingly common problem in JavaScript applications. For example, Bluesky embed widget had two versions of zod validation library. Removing the duplicate reduced the bundle size by ~9%.

This problem usually doesn't happen because you pulled two different versions of the same library, but because you and one of the external libraries depend on the same library, but in different versions. This can often be solved by updating the libraries you depend on.

Your project

With all of this in mind, we can finally move to the last piece of the puzzle — your project. Here’s what you can do to shrink your bundles and improve performance.

Inspect your bundles

The first step is visibility. Without understanding what’s inside your bundles, reducing their size becomes a guessing game. For this, you can use a bundle analyzer and visualizer I created called Sonda. It works with most bundlers mentioned above (except Parcel) and accurately shows the size of individual files that contribute to the bundle.

You can start by installing it in your project and visually inspecting parts of your bundle.

Once you have a good understanding of what’s inside the bundles and have identified the parts that can be optimized, you can click on the graph tiles to see:

Sonda also warns you about duplicate dependencies so you can quickly identify and fix the root of the problem.

Ideally, you should not only do a one-time inspection, but set up continues monitoring as part of your CI pipeline. Tracking changes over time, especially in large projects, can help you prevent small changes from snowballing into significant bloat over time.

Remove or optimize external libraries

The fastest code is the code you don’t ship. Whenever possible:

Remove libraries that can be replaced by native APIs.
Swap out heavyweight libraries for smaller alternatives.
Use optimized installation paths if the library support it.

Use code splitting

If you can’t remove some part of your application, try code splitting. Code splitting allows you to defer loading certain parts of your app until they’re needed, improving initial load times.

Use dynamic import() to load modules on demand. For example, if a particular feature isn’t needed until the user clicks a button, defer loading it until that moment.

Modern frontend frameworks support lazy loading out of the box, making it easier than ever to integrate code splitting into your workflow.

Follow the best practices

This is a general advice, but it's worth repeating. Follow the best practices, like:

Use the latest target you can so that the code is not unnecessarily transpiled or polyfilled. Some polyfills can add a lot of code that is not needed at all in modern browsers, but many environments still add them by default. You can also set up a reminder to update the target every year.
Regularly update dependencies, as every so often the newer versions are smaller or faster. This can also prevent you from having to deal with security vulnerabilities or duplicate dependencies.
Evaluate each dependency you already have or are considering adding. If you can't justify the size, don't add it or search for a smaller alternative.

Join the Ecosystem Performance (e18e) community

If you are interested in making the web faster or simply just learning new things, you should consider joining the Ecosystem Performance community. We focus on three main areas:

Clean up — Improving packages by removing redundant dependencies or replacing them with modern alternatives.
Speed up — Improving performance of widely used packages.
Level up — Building modern alternatives to outdated packages.

Conclusion

I hope this article illustrates that you can ship the same features with less code. Bundle sizes can grow out of control if unmanaged, but even small changes can significantly improve performance.

Start today: analyze your bundles, test a new tool, or replace a heavyweight library. The impact will surprise you.

I hope you enjoyed this article. If you have any questions or comments, or if you like to learn more about a specific topic, please let me know in the comments below. If you want to learn more about the topic of JavaScript performance, bundling and tree-shaking, you can follow me here or on BlueSky and join the e18e community.

Visualizing JavaScript and CSS Bundles with Sonda

Filip Sobol — Sun, 01 Dec 2024 10:35:34 +0000

In this article, I'll show what Sonda is and what it can do. If you want to give it a try, check out https://sonda.dev/ or the demo page.

If you've ever struggled with optimizing your JavaScript and CSS bundles, you're not alone. As web applications grow more complex, fewer developers focus or learn build tools. But understanding how your code is bundled and what’s inside those bundles becomes increasingly important. This knowledge pays dividends in the long run and should be a key part of a web developer's toolkit.

One open-source tool that can help you understand your bundles better is Sonda. Sonda lets you visualize and analyze JavaScript and CSS bundles. In this article, let's explore how it can help you gain a deeper understanding of your final bundles after optimizations like minification and tree-shaking.

Works With All Major Bundlers

Sonda works seamlessly with all major bundlers, including:

Vite
Rollup
esbuild
webpack
Rspack

There are no second-class citizens. Plugins for all bundlers offer the same features and provide consistent insights, so you don't need to change tools or workflows because of the bundler you're using.

More Accurate Insights

Many existing bundle visualizers struggle to provide an accurate picture of the final bundles, often visualizing the output before crucial optimizations like tree-shaking or minification have occurred. This means that what you see in these reports may not match what is actually delivered to users.

Sonda addresses this by showing information about the final bundle, after all optimizations are complete. This ensures an accurate representation of what is ultimately delivered to users.

You can learn more in the What Makes Sonda Accurate? article.

Detailed Reports for Better Understanding

Sonda provides a detailed analysis, including:

Sizes before and after compression
Download times
A dependency graph

This helps you understand the impact that each file and dependency has on the bundles. With this information, you can make informed decisions about which dependencies are worth keeping or where to trim down your code.

Supports Multiple Formats: HTML & JSON

Sonda can generate reports in HTML and JSON formats. The HTML reports are ideal for visual analysis, offering a clear, interactive visualization that can be easily shared with teammates. The JSON output is useful for integrating Sonda into CI/CD pipelines or other automated processes, making it flexible enough to fit into various workflows.

Highlighting the Code That Matters

Sonda can highlight the code that is actually used in the final bundle. In complex projects, it can be challenging to keep track of which parts of a library or module are necessary. Sonda makes it clear by showing exactly what is in use.

This feature can save significant time on debugging and pruning unnecessary code, providing a straightforward path to bundle optimization.

Identifying Common Issues

Sonda also provides warnings about common issues, such as duplicated dependencies. This helps prevent unintentional duplication that can increase bundle size and impact load times.

These warnings help you maintain best practices and keep your bundles clean and optimized.

Conclusion

Sonda is a powerful tool for understanding and optimizing JavaScript and CSS bundles. Its bundler-agnostic approach, detailed reports, and accurate post-optimization insights make it a solid choice for shipping smaller and faster web applications.

If you're interested, give Sonda a try at https://sonda.dev/ or check out the demo page

What are your biggest challenges when analyzing bundlers? Are there any features that Sonda is missing?

DEV Community: Filip Sobol

Downsize your JavaScript: Mastering Bundler Optimizations

Introduction

Why optimizing JavaScript matters

Bundlers

Benchmark

Build speed

Output size

Aggregated results

Individual libraries

Bundle size vs. output speed

Libraries

Gold but old

Bundler-specific optimizations

Optimized installation paths

Duplicated dependencies

Your project

Inspect your bundles

Remove or optimize external libraries

Use code splitting

Follow the best practices

Join the Ecosystem Performance (e18e) community

Conclusion

Visualizing JavaScript and CSS Bundles with Sonda

Works With All Major Bundlers

More Accurate Insights

Detailed Reports for Better Understanding

Supports Multiple Formats: HTML & JSON

Highlighting the Code That Matters

Identifying Common Issues

Conclusion