Your main bundle crossed a megabyte and nobody can say why. Bundle analyzers tell you what is in there; an LLM is good at turning that inventory into a ranked reduction plan — duplicates, heavy dependencies, missed split points. Every item on the plan is then verified by building and measuring, because models routinely propose savings that bundlers already made or that break behavior.
Tier: Core · Workflow area: Performance & debugging
This playbook turns bundle archaeology into a short, evidence-ranked backlog and closes each item with a measured before/after.
Skip it if your problem is one known heavy import — just fix it. This playbook is for when the weight is diffuse and unexplained.
source-map-explorer for any bundler with source maps, rollup-plugin-visualizer for Vite/Rollup, @next/bundle-analyzer for Next.js, or webpack-bundle-analyzer.Generate the inventory and capture the baseline. Build for production and run the analyzer. Export something textual — source-map-explorer --json, the visualizer's data file, or even the sorted module list — because the next step needs data the model can read, not a treemap screenshot alone (though attaching the screenshot too helps a multimodal model).
Ask for a ranked plan with claimed evidence per item. Feed the inventory with a prompt that forces structure and falsifiability:
This is the bundle analysis of our app's critical route (JSON attached;
totals: 1.14MB raw / 342KB gzip first-load). Produce a ranked reduction
plan. For each item give:
1. What to change (specific: package, import site, config).
2. Estimated savings in KB and your confidence.
3. The evidence in this data that supports it (module paths, sizes).
4. Risk: what could break, and how to check.
Look specifically for: duplicate packages at multiple versions,
multiple libraries doing the same job (date, utility, icons), full-library
imports where subpath imports exist, polyfills for targets we may not
need, heavy deps used on this route but only for a minor feature, and
components that are candidates for dynamic import.
Cross-examine the top items: npm why <package> for duplicates, grep for the import sites it names. Strike any item whose evidence you cannot reproduce in the data.
Verify the top item with a measurement, not a merge. Take the highest-ranked item, apply it on a branch, rebuild, re-run the analyzer, and compare against the baseline. Watch for the two classic false wins:
Work down the list, one measured change per PR. Each PR carries the before/after: raw and compressed sizes, and which chunk changed. Behavioral risk items (swapping a date library, dropping a polyfill) additionally need the check the plan named in its risk column — run the affected tests or the affected browser matrix before merging.
Install the ratchet. Once you have won the headroom, freeze it: size-limit, bundlesize, or your CI's budget assertion on first-load JS per critical route, set just above the new reality. Add the analyzer to CI as an artifact so the next investigation starts with history instead of archaeology.
The model ranks, the build measures. An LLM reading your bundle inventory finds real duplicates and split points fast — and also confidently proposes savings the bundler already made. Nothing lands without a rebuilt, re-measured before/after.
package.json; the dependency list plus module sizes together let it spot duplicate-purpose libraries the treemap alone hides.next/dynamic/React.lazy boundaries — with you re-measuring after each.Bundle inventories reveal your dependency tree and module structure — usually shareable, but some client engagements class even that as confidential.
npm why plus this playbook's checklist (duplicates, same-job libraries, full-library imports, polyfills, split candidates) is a fine manual protocol — the LLM compresses hours into minutes but adds nothing you cannot enumerate.Never paste source maps or bundle contents from a client's proprietary app into a public tool — a source map is close to the source code itself. Inventories (module paths and sizes) are the most that should travel, and only where the engagement allows.