Let an AI agent trim your JavaScript

On October 28, the Next.js blog published Ship less JavaScript in Next.js with your AI agent, by Will Binns-Smith. It has two halves: a next-bundle-optimizer skill for AI agents, and a set of new Bundle Analyzer features for humans.

What makes it worth writing about is not "AI can do one more thing". It is the division of labor it demonstrates: the tool does the analysis, the agent makes the change, and people sign off.

1. The problem: you think it is lazy-loaded, but it is not

The official example is a classic. You write lazy(() => import('./HeavyComponent')) to defer a large component. If that is the only module importing HeavyComponent, the deferral works. But if any other module in the same bundle imports it statically, the code still loads upfront.

This is hard to catch by reading code, because the two imports can live in completely unrelated files. The bigger the project, the more quietly it grows.

2. How the agent skill works

• Requirements: Next.js 16.4 with Turbopack, the default bundler since Next.js 16, because the skill relies on Turbopack's module graph.
• Install: npx skills add vercel/next.js --skill next-bundle-optimizer, then run /next-bundle-optimizer in your agent.
• Approach: the agent exports saved next analyze snapshots as JSON, rebuilds the module and chunk graphs, finds large groups of connected modules, and uses minimum cut to find a small set of import boundaries that would defer them. It then checks the proposal against your source code and how the components are actually used.
• It also finds: logic that could move to React Server Components, duplicate versions of large dependencies, and places where tree shaking failed and pulled in unused code.
• Report-only by default. To apply changes, run /next-bundle-optimizer fix, which reruns the analysis and compares snapshots before and after.

3. Vercel's own numbers

Vercel says the skill saved nearly 2 MB of compressed JavaScript across v0 and vercel.com. Some of the specific findings:

• An experimental code editor in v0 loaded on nearly every page, even for users outside the experiment: 150 KB saved on most pages.
• v0's centralized dialog registry eagerly loaded heavy dialogs: 40–650 KB saved depending on the page.
• On vercel.com, markdown rendering, syntax highlighting and charts for the Agent panel shipped even when the panel was closed: 255 KB saved on the dashboard page.
• A URL parsing helper, imported through a shared utility file, pulled in the entire observability query engine: 125 KB saved on the deployments page.

These are numbers from Vercel's own large products, not a promise for yours. The process is the part worth copying: every change went through a pull request and was verified on a preview deployment before shipping.

4. The Bundle Analyzer for humans

If you would rather dig in yourself, next analyze gained some useful features:

• Route summary: the home view lists your largest client routes, so you know where to start.
• Automatic snapshots and diffs: every analysis is saved, so you can measure an optimization or find out what a new feature or dependency added.
• Critical render path: modules loaded synchronously for the initial render are highlighted, and async dependencies can be filtered out. The post also notes you should still test which modules really are on the critical path.
• Graph data can be exported for your own tooling with next analyze export.

5. Adoption advice

1. Measure before you optimize. Add a bundle-size budget check to CI; otherwise the weight comes back a month after the agent removes it.
2. Start in report mode. Let the agent list problems and suggestions, and have a person decide whether to run fix.
3. One change per pull request, and click through the interactions on a preview deployment before merging. Deferring code can change what users experience on their first click.
4. Confirm your build uses Turbopack. If the project is still pinned to webpack, the skill will not work.

6. What it means for this site

8plus is already on Next.js 16.4 and has its own bundle budget check (pnpm check:bundle). It measures the gzip size of the JavaScript each page loads initially, with a 200 KB target and a 340 KB ceiling; the home page baseline recorded on October 1 was 324 KB. In other words, there is still a gap to the target, which is exactly where tools like this help.

One caveat: in production, this site is built with Vite through vinext and runs on Cloudflare Workers, while next analyze analyzes the Turbopack build. The two may not split code the same way, so anything found there needs to be verified again against what is actually deployed.

---

JavaScript size is the kind of technical debt that grows a little at a time and is substantial a year later. Finding the cause used to take a senior engineer an afternoon of tracing imports; now an agent can produce the first report. The tooling got cheap. Budgets and sign-off are what the team still has to own. If you want help setting up performance budgets and checks for your site, book a 30-minute intro call.