Shipping Less JavaScript: Bundle Budgets With an Agent

The Problem With Bundle Optimisation

Everyone agrees the bundle is too big. Almost nobody can say which kilobyte is worth removing. Bundle work has a bad reputation because it is usually done as a one-off audit with no baseline, no budget, and no owner, which is exactly the shape of work that gets undone by the next feature.

On 28 October 2026 the Next.js team published a post about shipping less JavaScript with an AI agent, including a next-bundle-optimizer agent skill and new Bundle Analyzer tooling. The interesting part is not that an agent can find large modules. It is that the workflow makes the budget explicit, which is what was missing.

---

Set the Budget Before You Look

Do this first, or the rest is theatre. Pick a number for the route you care about and write it down, along with the date you measured it. "The blog index should stay under 180KB of client JavaScript compressed" is a budget. "We should reduce our bundle" is a wish.

Budgets should be per route, not per application, because a global number can hide a route that tripled while another got smaller.

---

Measure What Users Download

Three measurements, in this order.

• Route-level client JS, compressed. What actually crosses the wire for that URL.
• Shared chunks. What every route pays for whether or not it uses it. This is usually where the easy wins are.
• Hydration cost. A component that ships 40KB to become interactive in a few seconds of main-thread work is a worse trade than its size suggests.

---

Let the Agent Propose, Then Verify

The useful division of labour is narrow and specific: the agent reads the analyzer output, identifies candidates, and proposes removals. You verify each one against behaviour.

Good candidates are boring. A date library imported for one format call. An icon set imported as a namespace. A markdown renderer on a page that only renders headings. A client component that is client-side for no reason beyond habit, holding an entire subtree in the client bundle.

Bad candidates are the ones that look like wins and change behaviour: swapping a rich-text renderer for a regex, or moving a component to the server and losing interactivity the product depends on. If a change requires a product decision, it is not a bundle task.

---

Prefer Shrinking the Boundary to Shrinking the Code

The largest single lever is usually moving the server/client boundary rather than minifying inside it. A page that reads from a database and renders markdown does not need a client-side markdown renderer. A component that formats a date once per render rarely needs a date library on the client at all.

This is where Server Components pay for themselves, and where an agent is genuinely useful: it can survey every client component and report what each one actually needs the client for. The report is usually uncomfortable in a productive way.

---

Make It Enforceable

A budget that is not checked is a suggestion. Whatever the ceiling is, wire it into CI so a pull request that exceeds it fails and says by how much. This is the difference between a bundle that stays small and a bundle that was small once, in October.

---

What Good Looks Like After a Quarter

Not a dramatic headline number. The realistic outcome is that three routes lose a meaningful chunk each, one shared chunk stops being shipped everywhere, and the next feature that would have added 30KB gets caught in review because the budget pushed back.

That is a boring result, and it is the one that lasts.