Next Bundle Optimizer

Bundle optimizer

1. Set the scope

Analyze the whole app by default, covering all routes and shared client dependencies. Narrow the scope only when the user specifies a route, dependency, feature or other subset. Choose audit or fix mode. Audit is the default: generate analyzer artifacts and report candidates while leaving application source, dependencies and lockfiles unchanged. Fix mode requires an explicit request to change the app. Ask before changing visible behavior, timing, compatibility or a trust boundary. For a route's static App Shell, use next-cache-components-optimizer; install it first if unavailable (npx skills add https://github.com/vercel/next.js/tree/canary/skills/next-cache-components-optimizer). For navigation prefetch work, use next-partial-prefetching-optimizer; install it first if unavailable (npx skills add https://github.com/vercel/next.js/tree/canary/skills/next-partial-prefetching-optimizer).

Done: the whole-app or user-specified scope, mode and intended behavior are recorded. A request to capture or export data is audit mode, not permission to fix.

2. Capture and export a baseline

Run from the app directory with its package manager. Read next analyze --help for capture options and next analyze export --help for replay options in the installed CLI. Reuse a selected saved snapshot, or capture with a distinctive name first; then export it through gzip at its default compression level. Keep before/after .jsonl.gz files separate.

Sandbox requirement: If the agent’s sandbox blocks TCP port binding (as Codex’s does), it MUST run the next analyze --output capture outside the sandbox. Do not attempt the capture inside that sandbox, even though --output does not serve the analyzer UI.

Run the pipeline in Bash:

set -o pipefail
# Capture only when a new baseline is needed
pnpm exec next analyze --output --snapshot 'audit-before-unique-1'
pnpm exec next analyze export --snapshot 'audit-before-unique-1' | gzip > /tmp/analyze-app-before.jsonl.gz

--output builds and saves binary/UI artifacts without serving. next analyze export reads a saved snapshot without building; stdout is one typed JSON record per line, with errors on stderr. Omit --route for whole-app analysis; add it for a user-specified route. The route filter keeps the whole-app module graph, so scope it in the next step.

For a custom distDir, replay with --dist-dir <configured-directory> (relative or absolute): capture loads the app config, replay does not. --snapshot <name> selects a retained name; omission selects the newest snapshot. Capture generates a unique timestamp name when omitted, and replaces an existing capture when an explicit name is reused. Use distinct before/after names, including names with spaces, to preserve both baselines. For interactive exploration, capture without --output to serve the UI; next build --analyze also produces replayable data.

Done: the chosen capture is identified, export succeeded, and the baseline file, snapshot name and analysis scope are recorded. Check the whole pipeline's exit status before processing the compressed file: pipefail prevents gzip from hiding a failed export. Export validates one route at a time, so a failure can leave a partial archive even if gzip -t accepts it. Discard output when export or gzip fails.

3. Interpret the evidence

Resolve the schema from the app's installed Next.js, using its Node launcher:

pnpm exec node -p "require.resolve('next/analyze/graph-v1.schema.json')"

Read its descriptions for record meanings, joins, attribution and coverage. Stream decompression with gzip -dc /tmp/analyze-app-before.jsonl.gz into a line-oriented analysis script rather than loading the whole dump into context. Use the schema to interpret client/server contributions across every route in scope and choose the metric.

Done: the baseline's route-attributed client/server contributions and the metric are identified. Treat this as build evidence: claims about observed browser requests, timing or transfer savings need separate evidence.

4. Explain a candidate

Inspect actual project source and exact importers. Rank client-output contributions across the whole app, or within the user-specified scope, by attributed size, repetition, likely runtime cost, need before interaction and correctness risk.

Community → min-cut pass

For broad audits seeking opportunities across multiple features or a large contributor list, run community detection → target selection → directed min-cut → source validation after the initial ranking. Read Graph methods before constructing the graph or running solvers.

1. Rank detected communities by scoped client-output attribution and inspect their inbound importers.
2. Select large communities, or optional feature regions within them, that can plausibly wait for interaction. Record why each selected region is optional under the route's render conditions.
3. Run directed min-cuts from the verified client roots to those targets to find small sets of importer changes that could detach them.
4. Validate the cut edges against source and behavior constraints; account for each investigated target as a candidate, rejected cut or evidence gap.

For a narrow audit of a named dependency or feature, use direct importer reasoning when it fully accounts for the relevant paths and proposed boundary; record why the paired pass adds no useful target discovery. If graph evidence or tooling blocks the pass, record the blocker and limit the conclusions accordingly.