How to Find Bundle Bloat with source-map-explorer

This guide adds a bundler-agnostic tool to Webpack Bundle Analysis Techniques, part of JavaScript Bundle Optimization & Code Splitting. Bundler plugins such as webpack-bundle-analyzer and rollup-plugin-visualizer report what the bundler thinks each module contributes, often before minification. source-map-explorer takes a different approach: it reads the final minified file and its source map, and attributes every byte of output to the original source file that produced it.

That has two advantages. It measures exactly what ships — after minification, dead-code elimination and any post-processing — and it works with any toolchain that emits source maps: webpack, Rollup, Vite, esbuild, Parcel, Turbopack, or a CDN-hosted third-party bundle whose map you can download. When numbers from a bundler plugin and the actual file size disagree, source-map-explorer is the tie-breaker.

Rapid Diagnosis

• Ensure source maps are generated for production builds, even if not deployed publicly (hidden-source-map in webpack, sourcemap: 'hidden' in Vite).
• Run the tool on the largest initial chunk first. That is where bytes hurt most.
• Look for [unmapped] bytes. Large unmapped areas mean injected code (runtime, helpers) or broken source maps.
• Look for the same package under multiple paths — node_modules/a/node_modules/lodash and node_modules/lodash — indicating duplication.

Root Cause Analysis: What It Commonly Finds

1. Packages that survived tree shaking. A library expected to be partially removed appears in full because of side effects or CommonJS format.

2. Duplicated dependencies. Different versions of the same package installed for different dependents, both bundled.

3. Generated code. Large chunks attributed to generated files — GraphQL documents, i18n catalogues, route manifests — that grew silently.

4. Bundler runtime and helpers. Unmapped or runtime-attributed bytes that grow with chunk count or with module-interop overhead.

unmapped 18KB

Step-by-Step Workflow

1. Generate production source maps

// webpack.config.js
module.exports = { mode: 'production', devtool: 'hidden-source-map' };
// vite.config.js
export default { build: { sourcemap: 'hidden' } };
// trade-off: source maps add build time and disk space. Generate them in CI and
// upload to your error tracker; do not deploy them publicly unless you intend
// your source to be readable.

Expected outcome: a .map file next to every emitted chunk.

2. Run the analysis

npx source-map-explorer 'dist/assets/index-*.js' --html report.html
npx source-map-explorer 'dist/assets/*.js' --json > sme.json     # all chunks, machine-readable
# trade-off: analysing all chunks together merges lazy and initial code into
# one picture. Analyse the initial chunks separately for critical-path decisions.

Expected outcome: an interactive treemap and a JSON breakdown per file.

3. Investigate the top items

For each large contributor, decide: is it needed on this route? Is it larger than it should be (tree shaking failed)? Is it duplicated? Trace the import chain with your bundler's analysis tool or a why-style command (npm ls lodash, pnpm why lodash).

npm ls lodash
# my-app@1.0.0
# ├── lodash@4.17.21
# └─┬ legacy-widget@2.3.0
#   └── lodash@3.10.1
# trade-off: deduplicating across major versions is not always possible; if
# the old version is required, consider replacing or forking the dependent.

Expected outcome: a short list of concrete fixes, each with an expected byte saving.

4. Compare before and after

Save the JSON output for the base build and compare per-file totals after changes, or across releases, to confirm savings and catch regressions.

Verification

Check that the tool's total for a chunk matches the file's size (minus a small unmapped remainder); a large mismatch means the source map is incomplete. After fixing an issue, re-run and confirm the item shrank or disappeared, and that the chunk's total file size fell by a corresponding amount.

Worked Example: Two Copies of lodash

A React app's main chunk was 410KB minified. The bundler plugin showed lodash at 24KB, which seemed fine. source-map-explorer showed lodash under two paths totalling 71KB: the app's own lodash (full build, imported via import _ from 'lodash') and lodash@3 nested under an old widget dependency. The team switched the app's imports to lodash-es per-function imports, replaced the old widget, and the main chunk dropped by 64KB. The plugin had under-reported because it measured pre-minification module sizes and grouped the nested copy separately.

Common Mistakes

• Analysing development builds. Unminified, un-shaken code produces a misleading picture.
• Ignoring [unmapped]. A large unmapped share means the analysis is incomplete; fix source map generation first.
• Deploying public source maps by accident. Use hidden maps and keep them out of the public deploy.
• Comparing gzip to raw. Be consistent about whether you discuss minified or compressed sizes; the tool reports minified bytes by default (--gzip changes that).

Edge Cases That Distort the Picture

Concatenated modules. Scope hoisting (webpack's ModuleConcatenationPlugin, Rollup's default) merges modules into one function scope; source maps still attribute bytes correctly, but small helper modules may appear to vanish into their importers.

Inlined constants and minifier transforms. Minifiers inline constants and collapse code, so bytes attributed to a file can be smaller than its source suggests — or attributed to the call site rather than the definition. Interpret per-file numbers as approximate for very small files.

Multiple maps per chunk. Some pipelines run a second transform (a post-build minifier or obfuscator) that produces a new map; if the maps are not chained, attribution points at the intermediate file rather than the original source. Generate maps from the last step or chain them.

Inline data URLs. Fonts or images inlined into JavaScript appear as one large attribution to the importing module, often a CSS-in-JS file. Large inline assets are almost always better served as separate files.

FAQ

Related

• How to configure webpack-bundle-analyzer for production — the import-graph view.
• Finding duplicate dependencies in a monorepo bundle — fixing the duplication this tool reveals.
• Comparing two builds with Statoscope — build-to-build diffs for webpack.