Next.js 16.4: Ship Less JavaScript With Your AI Agent

As a Next.js project grows, its JavaScript bundles quietly get bigger. Nobody does it on purpose. A component imports another file, and that file pulls in yet another library. In the end, users download code they will never use on that page.

Next.js 16.4 hands this job to your AI agent. According to the Next.js team’s announcement on October 28, the new next-bundle-optimizer skill lets your agent read Turbopack’s module graph and find code that loads for no reason. In this post I’ll cover what the skill does, how to set it up, and what it found in Vercel’s own products.

What Is next-bundle-optimizer?

next-bundle-optimizer is an agent skill you install into your coding agent (such as Claude Code, Codex or Cursor). It gives the agent access to the data behind the Next.js Bundle Analyzer: which module imports which, and which chunks load on the initial page load.

The analyzer is built on Turbopack’s module graph, so it requires Turbopack. Turbopack has been the default bundler since Next.js 16.

Where Does the Problem Start?

To defer a heavy component, we usually reach for lazy():

// HeavyComponentLoader.js
'use client';
import { lazy } from 'react';

// Load the heavy component only when needed
export const HeavyComponentLoader = lazy(() => import('./HeavyComponent'));

But if another file in the same bundle imports that component statically:

// Settings.js
'use client';
// Static import: HeavyComponent is now part of the initial load
import HeavyComponent from './HeavyComponent';

What happens? The deferral you set up with lazy() is wasted. The code still loads up front. It is also very hard to spot by reading the code, because the two files know nothing about each other.

This is exactly the kind of import relationship the skill finds.

How Does It Work?

The skill teaches the agent to export saved next analyze snapshots as JSON and rebuild Turbopack’s module and chunk graphs. The agent then:

• Finds large groups of tightly connected modules and measures their impact on the bundle.
• Traces their import chains.
• Uses minimum cut to find the smallest set of import boundaries that would defer those modules.
• Checks its proposals against your source code and how the components are used in the UI.

It can also catch:

• Logic that could move to React Server Components
• Duplicate versions of large dependencies
• Unused code that ends up in the bundle because tree shaking couldn’t be applied

How Do You Set It Up? (Step by Step)

Step 1 — Upgrade to Next.js 16.4

npm install next@latest

Step 2 — Install the Skill

npx skills add vercel/next.js --skill next-bundle-optimizer

Step 3 — Start With a Report

Run the skill in your agent:

/next-bundle-optimizer

The default mode only produces a report. It doesn’t touch your source code, dependencies or lockfile. To focus on a single route, just name the route in your prompt.

Step 4 — Let It Fix Things If You Want

/next-bundle-optimizer fix

In this mode the agent applies its proposed changes, reruns the analysis and compares the two snapshots to measure the impact. It asks you before any step that would change visible behavior or timing. You can then ask it to open a separate pull request for each change.

What Did It Find at Vercel?

The Next.js team tried the skill on their own products. In v0:

• An experimental code editor loaded on nearly every page, even for users outside the experiment: 150 KB saved on most pages.
• The central dialog registry eagerly loaded some heavy dialogs: 40–650 KB depending on the page.
• An unused trace viewer component was reachable from most routes: 7–61 KB depending on the page.

On vercel.com:

• Markdown rendering, syntax highlighting and chart code shipped even when the Vercel Agent panel was closed: 255 KB on the dashboard page.
• A heavy natural-language date parsing library loaded before users touched the assistant: 55 KB on average.
• URL parsing code was imported through a shared utility file that also pulled in the entire observability query engine: 125 KB on the deployments page.

In total, nearly 2 MB of compressed JavaScript was either removed or deferred until needed. For each fix the agent opened a pull request, and the team verified it on a preview deployment before shipping.

The last example is the most familiar one to me. A shared utils file you created for one small helper can quietly drag a huge module along with it.

What’s New in the Bundle Analyzer?

The analyzer itself was also updated for people who don’t want to use an agent. The UI you open with next analyze now has:

• Route summary: A home page listing your largest client routes. Open a route and sort its table by size.
• Snapshot comparison: Analyses are saved automatically. Diff two of them to measure an optimization or see how much a new dependency added.
• Critical render path: Modules loaded synchronously for the initial render are highlighted, and you can filter out async dependencies.

If you want to use the analysis in your own tools, the new next analyze export command in 16.4 streams a snapshot as JSON Lines:

# Save the analysis as "before"
npx next analyze --output --snapshot before

# Export the saved snapshot as JSON Lines
npx next analyze export --snapshot before > bundle-graph.jsonl

For details, see the Next.js package bundling guide.

Who Is Affected / What Should You Do?

Any Next.js project on Turbopack can benefit, especially if you are unhappy with initial load times or Core Web Vitals. If you are on Webpack, this skill isn’t for you; the @next/bundle-analyzer plugin is still the tool there.

• Upgrade your project to Next.js 16.4 or later.
• Look at your largest routes yourself first with next analyze.
• Install the skill and use report mode only on the first run.
• Take fixes as separate pull requests and test them in a preview environment. Every deferred module is downloaded separately the first time a user touches that feature.
• The security scans on the skill page include a warning from Snyk. It’s worth a look before you install it.
• If you work in a sandbox that blocks port binding, such as Codex, you may need to run the next analyze --output step outside the sandbox.