What Is Tree-Shaking in JavaScript?
Learn what tree-shaking is, why it depends on ESM's static structure, and how bundlers safely remove unused JavaScript code.
Expected Interview Answer
Tree-shaking is a build-time optimization where a bundler statically analyzes ES module import/export statements to detect which exports are actually used, then eliminates unused ('dead') code from the final bundle so the browser never downloads it.
The name comes from imagining the module dependency graph as a tree and shaking it so dead code falls out and only the reachable, used branches remain. This relies fundamentally on ESM’s static structure: because import/export declarations cannot be conditionally computed at runtime, a bundler like Webpack, Rollup, or esbuild can build a precise reachability graph starting from entry points and mark every export that is never imported anywhere as eligible for removal. Side-effect-free code is essential for this to work safely — if the bundler cannot prove a module has no side effects (e.g., it mutates a global or runs code on import), it must keep it even if nothing imports its exports, which is why library authors mark packages with sideEffects: false in package.json when it is true. Tree-shaking does not work reliably on CommonJS because require() calls are dynamic and can be conditional, so the bundler cannot statically prove which exports are unused.
- Reduces final bundle size by removing genuinely unused exports
- Improves page load performance by shipping less JavaScript to parse and execute
- Encourages modular, side-effect-free library design
- Works automatically with production builds in modern bundlers (Webpack, Rollup, esbuild, Vite)
AI Mentor Explanation
Tree-shaking is like a groundskeeper packing the kit bag only with items actually listed on the day’s team sheet, leaving every unused bat and pad from the storeroom behind. Because the team sheet is fixed and known before the match, the groundskeeper can prove with certainty which gear will never be touched. If one item’s status is unclear — maybe it triggers an automatic announcement when unpacked — it gets kept just in case. That certainty-based, keep-only-what’s-provably-needed process is exactly what tree-shaking does with unused exports.
Step-by-Step Explanation
Step 1
Build the static dependency graph
The bundler parses ESM import/export statements from every entry point without executing code.
Step 2
Mark reachable exports
Any export actually imported and used somewhere in the graph is flagged as live.
Step 3
Identify dead code
Exports never imported anywhere, and code paths never reached, are marked unused.
Step 4
Eliminate and emit
The minifier physically removes dead code (unless side effects can't be ruled out) and emits the final trimmed bundle.
What Interviewer Expects
- Understanding that tree-shaking depends on ESM's static import/export structure
- Ability to explain why side effects block safe removal
- Awareness that CommonJS is much harder to tree-shake
- Mention of “sideEffects”: false in package.json for library authors
Common Mistakes
- Claiming tree-shaking works equally well on CommonJS code
- Forgetting that a module with unproven side effects will not be removed even if unused
- Assuming tree-shaking happens automatically without a production/optimized build config
- Confusing tree-shaking with code-splitting, which is a different optimization
Best Answer (HR Friendly)
“Tree-shaking is when a build tool looks at all the code you actually use and strips out everything you imported but never called, so users don’t have to download JavaScript that never runs. It relies on modern import/export syntax being predictable enough for the tool to know for certain what’s safe to delete.”
Code Example
// utils.js — only imported functions end up in the final bundle
export function add(a, b) { return a + b }
export function subtract(a, b) { return a - b } // unused, gets removed
// app.js
import { add } from './utils.js'
console.log(add(2, 3)) // subtract() never shipped to the browser
// package.json for a library — tells bundlers it’s safe to tree-shake
// {
// "name": "my-lib",
// "sideEffects": false
// }Follow-up Questions
- Why is tree-shaking much harder to apply to CommonJS modules?
- What does “sideEffects”: false in package.json actually tell the bundler?
- How does tree-shaking interact with code-splitting?
- Can tree-shaking remove an unused class method the same way it removes an unused function export?
MCQ Practice
1. What structural property of ESM makes tree-shaking possible?
Static, non-conditional import/export syntax lets bundlers build a precise usage graph ahead of execution.
2. Why might tree-shaking fail to remove an unused module?
If a module might run code with observable side effects just by being imported, it must be kept for correctness.
3. Why is tree-shaking unreliable on CommonJS code?
Because require() can be conditional or computed, bundlers cannot statically guarantee which exports are unused.
Flash Cards
What is tree-shaking? — Removing unused exports from a bundle via static analysis of ESM imports/exports.
What does tree-shaking require? — ESM's static import/export structure, resolvable without running code.
What blocks safe removal? — Unproven side effects — the bundler must keep code it cannot prove is side-effect-free.
Why doesn't CommonJS tree-shake well? — require() is dynamic/runtime, so usage cannot be statically determined.