Analyze JavaScript With a Script Treemap: Complete Guide (2026)

Why Bundle Visualization Matters

Bundles grow silently. Every new feature pulls a transitive dependency, every refactor leaves a few unused imports, and every "just install it" decision adds bytes the user pays for on every visit. The treemap is the only artifact that lets you see this drift in proportion.

• Unused JavaScript is the norm, not the exception. Industry analysis shows the median page loads roughly 35–40% JavaScript that is never executed during a session. The treemap shows you exactly which files contribute that waste.
• Bundle size determines the floor of your performance. Even with perfect caching, parse and compile time scales with bytes. On a mid-tier mobile device, every extra 100 KB of JavaScript adds roughly 100 ms of main-thread work.
• Transitive dependencies hide in plain sight.A library you intentionally added may pull in three more you didn't. The treemap surfaces those uninvited guests.
• Core Web Vitals depend on it.Heavy JavaScript bundles inflate Interaction to Next Paint (target < 200 ms) and delay Largest Contentful Paint (target < 2.5 s) — both confirmed Google ranking signals.
• AI search visibility follows performance. Generative answer engines preferentially cite pages that already rank well, and ranking depends on Core Web Vitals.

How to Read a Treemap (Worked Example)

A treemap is a nested rectangle chart. The outer rectangle is the entire bundle. Inside, each child rectangle is a package or file — its area proportional to its byte share. Drill into a package and you see its files. Drill into a file and you see its functions or exports.

Here is what a typical first-look reveals on a Next.js app shipping ~480 KB of JavaScript before optimization:

Total bundle: 482 KB (gzipped: 156 KB)

├── moment.js ......................... 250 KB  ← biggest rectangle
│   └── locale/ (all 130 locales) ..... 180 KB     (you only use en-US)
├── lodash ............................  72 KB
│   └── (used 4 functions of 200+) ....               (replaceable with lodash-es + tree shaking)
├── core-js polyfills .................  60 KB  ← polyfills for IE11 (your audience: 0%)
├── react + react-dom .................  44 KB     (keep — earns its weight)
├── chart-library-A ...................  28 KB
├── chart-library-B ...................  26 KB  ← duplicate-purpose library
├── your app code .....................  22 KB
└── source maps (.map shipped) ........  18 KB  ← should be excluded from production

Action plan:
  moment.js     → replace with date-fns (~30 KB)         saves 220 KB
  core-js       → drop legacy polyfills via browserslist  saves 60 KB
  chart libs    → consolidate to one                      saves 26 KB
  source maps   → exclude from production deploy          saves 18 KB
  ───────────────────────────────────────────────────────────────────
  Projected new total: ~158 KB (gzipped: ~52 KB)          ~67% reduction

The treemap doesn't make these decisions for you — it makes them visible. Each finding goes through the same triage: keep, replace with a lighter alternative, or lazy-load on demand.

How to Generate a Treemap

The mainstream open-source build tooling all has free treemap output. Pick the one that matches your bundler.

• Greadme deep scan — flags unused JavaScript, oversized scripts, and render-blocking bundles per page, and pairs each finding with an AI-generated fix or a one-click GitHub PR.
• Greadme crawler scan — runs the same JavaScript audit across every indexable page so you can spot which templates ship the most bloat.
• webpack-bundle-analyzer — interactive treemap for any webpack-based project (including Next.js).
• source-map-explorer — works with any project that emits source maps; great for Create React App and custom builds.
• rollup-plugin-visualizer — treemap output for Rollup and Vite builds.
• vite-bundle-visualizer — zero-config treemap for Vite projects.
• Chrome DevTools → Coverage tab — complements a treemap by showing which JavaScript actually executed at runtime, distinguishing "shipped" from "used."

// Adding webpack-bundle-analyzer to a Next.js project

// 1. Install
npm install --save-dev @next/bundle-analyzer

// 2. next.config.js
const withBundleAnalyzer = require('@next/bundle-analyzer')({
  enabled: process.env.ANALYZE === 'true',
});

module.exports = withBundleAnalyzer({
  // your existing Next.js config
});

// 3. Run it
ANALYZE=true npm run build

// Opens an interactive treemap in your browser showing
// every package, every chunk, and every byte.

What to Look For in a Treemap

// package.json
{
  "browserslist": [
    "> 0.5%",
    "last 2 versions",
    "not dead",
    "not IE 11"
  ]
}

// Bad — ships ~70 KB
import _ from 'lodash';
const fn = _.debounce(handler, 200);

// Good — ships ~2 KB
import debounce from 'lodash/debounce';
const fn = debounce(handler, 200);

// Next.js dynamic import (client-side only)
import dynamic from 'next/dynamic';

const AdminPanel = dynamic(() => import('./AdminPanel'), {
  loading: () => <p>Loading...</p>,
  ssr: false,
});

Common Bundle Problems and Fixes

Treemap Findings vs. Action: Decision Matrix

Every red flag in a treemap maps to one of three actions. Use this as a quick reference.

FAQ

What is a script treemap?

A script treemap is a chart that breaks down a JavaScript bundle by size, drawing each package, file, or function as a rectangle proportional to its byte share. It's the standard tool for diagnosing bundle bloat.

How much unused JavaScript does a typical page ship?

Industry analysis (HTTP Archive Web Almanac, 2024) puts the median at 35–40% unused JavaScript at first load. Many sites are well above 50%. A treemap combined with the Coverage tab in Chrome DevTools shows you exactly which files are responsible.

Should I look at minified or unminified sizes?

Look at minified, gzipped (or brotli-compressed) sizes — that's what users actually download. Most treemap tools show both; trust the "parsed size" or "gzipped size" column for real-world impact comparisons.

How often should I run a treemap analysis?

At minimum every quarter, and on every major dependency upgrade. Better: wire it into CI so a build fails when the main bundle grows past a budget (for example 170 KB gzipped per route).

Treemap vs. the Coverage tab — which should I use?

Both. The treemap shows you what's shipped; the Coverage tab in Chrome DevTools shows you what's executed. The gap between them is your unused JavaScript.

Do AI search engines like ChatGPT and Perplexity care about bundle size?

Indirectly but meaningfully. Generative search systems preferentially cite pages that already rank well in traditional search, and ranking depends on Core Web Vitals — which JavaScript weight directly affects. A bloated bundle quietly hurts both your search visibility and your odds of being chosen as an AI citation.

What should my bundle budget be?

A reasonable target for a content-driven site is ≤ 170 KB gzipped JavaScript per route on first load. Single-page apps with rich interaction can justify more, but every additional 100 KB on mobile costs roughly 100 ms of main-thread work.