Tree Shaking

Tree shaking is an optimization technique that automatically detects and removes unused JavaScript code during the build process of your website. The name refers to shaking a tree where dead branches fall off. In practice, a bundler like Webpack, Rollup or Vite analyzes which functions, variables and modules you actually use and omits anything you don't call on in the final file. For an average SMB Web site, this means that your JavaScript files can be 30 to 60 percent smaller, which directly affects load speed and Core Web Vitals score.

How tree shaking works in modern bundlers

Tree shaking relies on ES6 module syntax (import and export) because it is statically analyzable. While building your site, the bundler scans all import statements and marks which exports are actually called. Code that is not imported or called anywhere is labeled dead code and is not included in the production file. This process works reliably only if you use libraries that provide ES modules and if you don't use dynamic imports or eval constructs that interfere with static analysis. Modern frameworks such as React, Vue and Svelte support tree shaking natively, but older CommonJS modules often remain entirely in your bundle.

Why tree shaking is now standard in web development

Around 2015, Rollup introduced tree shaking as a core feature, followed by Webpack 2 in 2017. The answer to a growing problem: JavaScript bundles were getting bigger and bigger through the use of extensive libraries like Lodash or Moment.js, while websites often only needed a handful of functions. Google made it clear in 2018 that load speed is a ranking factor and introduced Core Web Vitals in 2020. Since then, tree shaking is no longer a nice-to-have but a basic requirement for any professional website. An unoptimized 800 kB bundle can shrink to 250 kB due to tree shaking, which makes the difference between an acceptable and a slow mobile experience.

What tree shaking brings to Dutch SME websites

In practice, we at Monkey Vision see that tree shaking mainly impacts websites with many interactive components or extensive dashboards. An ecommerce store that loads a datepicker, validation library and analytics script, without tree shaking, easily sends 600 kB of JavaScript to the visitor, while only 40 percent of it is actually executed. By enabling tree shaking in combination with code splitting, you achieve a First Contentful Paint that is 1 to 2 seconds faster, which has a measurable effect on bounce rates and conversion. For those serious about investing in speed and user experience, professional front-end development with optimized build processes is the logical next step. A link to API integrations is also relevant, as tree shaking helps to load only the necessary SDK components. More background on optimization can be found in Google Developers' JavaScript Optimization Guide.

Tree shaking really comes into its own when working with external libraries or a modular codebase. Below you can see where technology makes the most difference and when you consciously choose to enable or skip tree shaking.

Optimize utility libraries such as Lodash and date-fns

Lodash is a popular JavaScript library with over 300 help functions, but most projects use only 5 to 10 of them. Without tree shaking you import the entire library of about 70 kB minified. By using ES-module-imports (import { debounce, throttle } from 'lodash-es') and enabling tree shaking, you only include the functions you actually call. The same goes for date-fns: instead of the entire library of 200+ functions, you only load format, addDays and parseISO. For a B2B platform with 15 employees building a scheduling interface, this easily saves 150 kB of unnecessary code. Note: always use the ES module variant of a library, identified by the -es suffix or module field in package.json.

Keeping component libraries and design systems lean

Design systems like Material-UI, Ant Design or Chakra UI offer dozens of components, but an average page uses only 3 to 7 of them. Without tree shaking, you load the entire library, including components you never use. By using named imports (import { Button, TextField } from '@mui/material') and activating tree shaking, only the required components remain. An ecommerce store with 500 products building a custom checkout can thus go from 400 kB Material-UI down to 80 kB. Important: some libraries require additional configuration, such as the babel-plugin-import-package for Ant Design. Always check the documentation and test the bundle size with tools such as Webpack Bundle Analyzer. For those who want a fully custom design without ballast, custom web design is often more efficient than modifying an existing design system.

Icon sets and SVG collections filtering

Icon libraries like FontAwesome, Heroicons or Material Icons contain thousands of icons, while a typical website needs 20 to 40. Without tree shaking, you import the full icon font or SVG sprite of 300 to 500 kB. With tree shaking, you import only the icons you use (import { FaUser, FaShoppingCart } from 'react-icons/fa'), resulting in 5 to 15 kB. For an SME service provider with a simple corporate site, this makes the difference between an acceptable and a slow mobile experience. Remember that tree shaking only works if you use named imports; a wildcard import (import * as Icons) takes everything. If you doubt that you have tree shaking set up properly, use the coverage tab in Chrome DevTools to see what percentage of your JavaScript is actually being executed.

When tree shaking is the right choice and when it is not

Tree shaking makes sense once you use external libraries, have a modular codebase or build an SPA with a framework. It is less relevant for small static sites with less than 50 kB of JavaScript or for server-rendered pages where most of the logic runs in PHP or Python. Note that tree shaking does not work well with CommonJS modules, dynamic imports or code that has side effects (such as polyfills that automatically adjust the global scope). If your library does not offer ES modules, the full bundle will remain. In that case, it's smarter to choose an alternative library or cherry-pick features manually. For more complex projects with API integrations and real-time data, a professional development setup with tree shaking, code splitting and lazy loading is the only sustainable route.