Bundle Analysis

How the analyzer works

• Install @next/bundle-analyzer, wrap next.config.ts, run ANALYZE=true next build --webpack
• Opens an HTML treemap — each rectangle is a module, sized by its byte contribution
• The --webpack flag is required; Next.js 16 defaults to Turbopack which the analyzer doesn't support

What it found

• Three things stood out: a large proxy.js edge bundle, Auth0 packages in the client bundle, and date-fns at 24 modules
• Only Auth0 was a problem — the other two were expected
• proxy.js is the middleware (intentionally large: it runs auth and CSP on every request). date-fns at 24 modules is correct tree-shaking — only the calendar's named imports are included

The real problem: Auth0Provider

Root layout wrapped the whole app in <Auth0Provider>, a React context so client components could call useUser().

useUser() had zero call sites in the entire codebase. Auth0Provider pulled in jose (JWT parsing, hundreds of KB), oauth4webapi, openid-client, and swr — server-only libraries with no business in a browser bundle.

The fix

• Remove Auth0Provider from layout.tsx — three lines deleted, layout became a synchronous function
• jose, oauth4webapi, openid-client, and swr disappeared from the client bundle entirely
• Auth still works: middleware gates every route server-side before React runs; server components call auth0.getSession() directly; API routes call auth0.getAccessToken()

The takeaway

• The analyzer is most useful for finding things that shouldn't be in a bundle, not just things that are too large
• Pattern to watch for: server-only libraries (crypto, JWT parsers, DB drivers) appearing in the client or edge bundle
• A quick grep for useUser — zero results — confirmed the removal was safe before shipping