Tree Shaking

Modern websites and apps consist of program code that developers don’t write entirely themselves. They pull in ready-made collections of building blocks, so-called libraries. Such a library can contain hundreds of functions, even though a project might only need three of them. Tree Shaking is a process that throws out exactly this unused part before publication. The name comes from the image of a tree: you shake it, and everything that isn’t firmly attached falls off. What remains is only the code that is actually called somewhere.

Why every kilobyte matters in the browser

When you open a website, your device first has to download the program code. Only then can it be executed and the page becomes usable. The larger the file, the longer you stare at a half-loaded page. On fast Wi-Fi you barely notice this. On a train with weak mobile signal, it suddenly becomes several seconds of difference.

These seconds have measurable consequences. Studies from large online shops have shown for years that slower pages sell less. Search engines also factor a page’s load time into their rankings. That’s why the size of the delivered code is a real metric that development teams monitor.

The effect of Tree Shaking is often surprisingly large in this regard. A popular toolkit like Lodash spans several hundred kilobytes. A project that only uses two helper functions from it can, after the sorting-out process, get by with just a few kilobytes. The rest is never sent to the user, since it wouldn’t do anything there anyway.

How the bundler decides what gets dropped

The work is done by a program called a bundler. It collects all the code files of a project and bundles them into a package for the browser. Well-known examples are called Webpack, Rollup, or esbuild. While bundling, the bundler analyzes which building blocks anyone actually requests.

It starts at the entry point of the program and follows every connection further. If the entry file calls Function A, and A uses B, both are considered reachable. Function C, which nobody references, is marked as dead code and deleted. Experts therefore also speak of Dead Code Elimination. The difference is subtle: Tree Shaking looks at whole modules and their connections, while classic Dead Code Elimination tends to look at individual lines within a file.

For this to work, the analysis has to be possible without execution. The bundler only reads the code, it doesn’t run it. That’s why Tree Shaking works well with the modern import/export syntax, where all dependencies are fixed in the text. If code is instead dynamically assembled at runtime, the tool can’t decide with certainty. When in doubt, it prefers to keep the building block, because a package that’s too small and crashes would be the worse mistake.

Tree Shaking in frameworks and build pipelines

You practically never have to install Tree Shaking as a separate tool. It’s already built into the standard toolchains of modern web frameworks like React, Vue, or Svelte. As soon as a project is built for real production use, this step runs automatically along with it. During the development phase it usually stays turned off, because it costs time and gets in the way when hunting for bugs.

The topic becomes visible in discussions about libraries. When developers write that a library is tree-shakeable, they mean: you can use individual parts of it without having to drag along the entire rest. Nowadays this is a solid selling point that projects advertise on their homepage.

A common misconception is that Tree Shaking would make the execution of the program faster. It only removes dead weight that was never executed anyway. What becomes faster is the downloading and initial parsing of the code, not the actual computation work. Still, for perceived speed, it’s one of the most effective levers.