Reducing JavaScript bundle size: find it, split it, delete it

How do you find what is in the bundle?

1. 1Run a bundle analyser against a production build and look at the treemap per route.
2. 2Read the framework's build output — Next.js prints first-load JavaScript per route.
3. 3In DevTools, use the Coverage panel to see how much of the loaded JavaScript actually executes.
4. 4Sort by size and investigate anything over about 30KB that you did not deliberately choose.
5. 5Check for duplicate copies of the same library at different versions.

Which dependencies are worth replacing?

Before adding any dependency, check its size and whether it tree-shakes. A five-second check at install time is worth more than a bundle-reduction project a year later.

How should code splitting be applied?

// Load the editor only when the user opens it
const RichTextEditor = dynamic(() => import("@/components/rich-text-editor"), {
  loading: () => <EditorSkeleton />,
  ssr: false,
});

// Load a chart library only on the route that renders charts
const Chart = dynamic(() => import("@/components/chart"));

• Split by route first — the framework usually does this for you; verify it did.
• Split heavy components behind an interaction: modals, editors, charts, maps, video players.
• Do not split tiny components; the extra request costs more than it saves.
• Prefetch the chunk on hover or intent so the user does not wait when they click.

What else reduces shipped JavaScript?

1. 1Move logic to the server. With server components, formatting, parsing and data shaping never reach the browser at all.
2. 2Use the platform: Intl for dates and numbers, fetch for requests, CSS for animation, native dialog and details elements.
3. 3Import specific modules rather than namespaces, and verify the package supports tree shaking.
4. 4Remove polyfills for browsers you no longer support — check your browserslist target.
5. 5Delete dead code and unused feature flags; they are shipped whether or not they run.

How do you stop it growing back?

• Set a size budget per route and fail CI when it is exceeded.
• Report the size delta as a comment on every pull request so the cost is visible at review.
• Require a note in the description when a pull request adds a new dependency.
• Review the biggest routes quarterly — treat bundle size like technical debt with an owner.

The number that matters is first-load JavaScript on your most-visited route, on mobile, compressed. Track that single figure over time and most of the discipline follows from it.