How I cut my Webpack bundle size in half

Last updated 1 year ago by Justin Duke


When I initially built out Buttondown, I was focused on two aspects above all else

  • It being built quickly.
  • It working reasonably well.

Notably excluded from that list is performance. Buttondown isn’t a slow app, but it is a heavy one: the bundle size while developing is measured in megabytes, and there’s a non-trivial loading time for first-time users.

Now that the core feature base has stabilized and nothing is particularly in an “on fire” state, I wanted to turn my eye towards maintenance work, and a big piece of that was seeing what I could do to shrink that bundle.

So, yeah. A hair under four megabytes. Sure, that’s unminified and unuglified, but it’s way too large for an app of Buttondown’s size. I resolved to cut that size in half, and here’s how: a combination of best practices and common sense front-end principles that I really should have adopted from the start.

0. Analyzing the Bundle

I knew the bundle was big, but I didn’t really know why it was big. Thankfully, there’s a tool for that! webpack-bundle-analyzer analyzes your webpack stats and spits out a tree-map visualizing what’s taking up so much space:

What the bundle looks like

Read full Article