How do you analyze and reduce bundle size in Next.js?

Q: How do you analyze and reduce bundle size in Next.js?

**Target Audience:** Frontend engineers preparing for Next.js interviews — assumes basic React and App Router familiarity. **Difficulty:** Medium > **How to read this doc:** Each idea is explained in plain language first, then tagged with `📌 Interview term:`. Every behaviour claim was checked against the Next.js docs shipped with the package (written on 16.3.4, re-reviewed against 16.4.2) and, in the **Verified** section, against real output from a build or a running server; each Verified block says which version it ran on. ## 1. Why This Even Matters — A Story First Reducing a bundle is like packing for a trip with a strict luggage limit. First you weigh the suitcase and look inside (the analyzer). Then you leave behind what you only use at home (server-only code), take a small travel bottle instead of the full bottle (import one function), and ship the heavy ski gear separately, only if you go skiing (lazy loading). ## 2. The Core Idea 📌 **Interview term: Bundle analyzer** — a

The problem

Question presented to candidate: "Lighthouse flags too much JavaScript on our product pages. How do you find out what is in the bundle, and what are your main levers to reduce it in a Next.js app?"

What a strong answer should cover:

Next.js 16 removed the size and First Load JS columns from next build; measure with the Turbopack bundle analyzer (next analyze since 16.4; next experimental-analyze in 16.1 to 16.3, still an alias), @next/bundle-analyzer for Webpack builds, and Lighthouse.
Biggest lever: keep code in Server Components, which ship no client JavaScript, and push 'use client' down to small leaves.
Import only what you use: per-function imports or optimizePackageImports for large libraries.
Lazy load heavy client code with next/dynamic or import() in handlers.
Move third-party scripts to next/script with a late strategy, and keep server-only packages out of client imports.

Clarifying questions expected:

"Which route and which user flow?" — measure the page that matters, not the whole app.
"Is the cost in our code or in dependencies?" — the analyzer answers that.

Code / implementation expected: Yes — an import change and the analyzer command.

nextjs
bundle-size
performance
optimization

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Frontend engineers preparing for Next.js interviews — assumes basic React and App Router familiarity. Difficulty: Medium

How to read this doc: Each idea is explained in plain language first, then tagged with 📌 Interview term:. Every behaviour claim was checked against the Next.js docs shipped with the package (written on 16.3.4, re-reviewed against 16.4.2) and, in the Verified section, against real output from a build or a running server; each Verified block says which version it ran on.

1. Why This Even Matters — A Story First

Reducing a bundle is like packing for a trip with a strict luggage limit. First you weigh the suitcase and look inside (the analyzer). Then you leave behind what you only use at home (server-only code), take a small travel bottle instead of the full bottle (import one function), and ship the heavy ski gear separately, on

The solution is hidden so you can try first

5 min read · 8 sections

Read the code

Precise imports, package optimization and the analyzer

// Before: pulls in the whole library
import _ from "lodash";
const onSearch = _.debounce(search, 300);

// After: one module
import debounce from "lodash/debounce";
const onSearch2 = debounce(search, 300);

// next.config.ts: precise imports for barrel-heavy packages
const nextConfig = { experimental: { optimizePackageImports: ["@acme/icons"] } };
export default nextConfig;

// Terminal (Turbopack): Next.js 16.4+
//   npx next analyze                      (16.1 to 16.3: npx next experimental-analyze)
//   npx next analyze --output --snapshot before && npx next analyze export --snapshot before > graph.jsonl

Discussion

Other approaches, follow-ups and how it went in real interviews.

Sign in to join the discussion.

No comments yet. Share how you would answer it.

The solution is hidden so you can try first

Keep your momentum going.