Q196: Bundle Analysis, JavaScript Cost and Route Splitting
What Interviewers Want To Evaluate
This question checks whether you can reason about JavaScript as a performance cost. Interviewers want bundle analysis, route chunks, hydration cost, dependency weight, parsing and execution, tree shaking, dynamic imports, Server Components, and regression prevention.
Senior answers should connect bundle size to user experience, not just file size.
Short Interview Answer
Bundle analysis shows what JavaScript ships to each route and why. JavaScript cost includes download, parse, compile, execute, and hydrate time. To reduce it, split by route and interaction, remove unused dependencies, avoid pulling server-only code into client bundles, use dynamic imports for delayed features, prefer Server Components for non-interactive content, and track route-level budgets so regressions are caught early.
Detailed Interview Answer
JavaScript is expensive in multiple ways.
network download
decompression
parse
compile
execute
hydrate
garbage collection
main-thread blocking
A smaller file is usually better, but the runtime cost matters too.
Bundle Analysis Questions
Bundle analysis should answer:
what ships to this route
which package added the most weight
why is this module included
is it client or server bundle
is code duplicated across chunks
is a dependency tree-shaken
which route owns the cost
The "why" matters as much as the "how much."
Route-Level Cost
A route should pay only for what it needs.
Example:
question reading route should not load code editor
home route should not load PDF generation logic
practice route can load transpiler UI
admin-only charting should not ship to public pages
This is especially important in Next.js apps with mixed content and tools.
Hydration Cost
Client Components hydrate.
Hydration means React attaches behavior to server-rendered HTML.
Too many client components can create:
long startup tasks
delayed interaction
high memory use
INP regressions
slower low-end devices
Push client boundaries down to the smallest interactive islands.
Tree Shaking
Tree shaking removes unused exports when code is statically analyzable.
It works best with:
ES modules
side-effect-free modules
named imports
clear package sideEffects metadata
no dynamic require patterns
Some packages are harder to shake, so measure actual output.
Dynamic Imports
Dynamic imports delay loading code until needed.
Good candidates:
code editor
charting library
PDF preview
admin-only panel
rare modal workflow
heavy syntax highlighter
large visualization
Do not dynamically import critical above-the-fold content if it delays LCP.
Server Components
Server Components can keep non-interactive code out of the browser.
Good use cases:
MDX rendering
content lookup
metadata generation
server formatting
data fetching
large server-only utilities
Be careful not to import server-heavy modules into Client Components.
Dependency Review
Before adding a dependency, ask:
how large is it
does it tree shake
does it run on every route
does it need the browser
can platform APIs replace it
is it maintained
does it duplicate existing code
what is the fallback if removed
Every dependency has product and operational cost.
Common Mistakes
A common mistake is looking only at total bundle size.
Another mistake is dynamically importing content users need immediately.
Another mistake is making a whole page client-side for one button.
Another mistake is adding charting, date, or utility libraries without checking cost.
Another mistake is ignoring hydration when server HTML looks fast.
Senior Trade-Offs
Splitting code improves initial load but can create later loading pauses.
The best split follows user intent.
Load what users need now. Delay what they may need later. Preload what they are very likely to need next.
Debugging Workflow
When JavaScript cost grows:
run bundle analysis
identify route affected
inspect largest modules
trace why module is included
check client/server boundary
review new dependencies
measure hydration and INP
split delayed features
remove duplicate packages
add budget check
Interview Framing
Explain JavaScript cost, route-level analysis, hydration, tree shaking, dynamic imports, Server Components, and dependency governance.
Revision Notes
JavaScript performance is not just bytes. It is work on the user's device.
Key Takeaways
Make every route pay only for the code it needs.
Follow-Up Questions
- What does bundle analysis show?
- Why is JavaScript more than download size?
- What is hydration cost?
- How do route chunks help?
- What makes tree shaking effective?
- When should dynamic imports be used?
- How can Server Components reduce JS?
- What dependency questions should be asked?
- How do bundle budgets prevent regressions?
- How would you debug a sudden bundle increase?
How I Would Answer This In A Real Interview
I would say I analyze route-level bundles to see what ships and why. Then I reduce unnecessary client JavaScript by moving non-interactive work to Server Components, splitting delayed features, reviewing dependencies, preserving tree shaking, and tracking budgets against route and interaction performance.