Bundle Size: What to Cut and What Is Not Worth Cutting

The problem

Bundle size discussions usually fall into two bad extremes.

One side ignores it completely:

“Everyone has good internet now.”

The other side turns it into obsession:

“We need to save 3 kB no matter what.”

Both are wrong because they confuse the number with the impact.

Bundle size matters.

But it matters because of the real effect on the user’s critical path, not because a smaller number feels good in the dashboard.

Mental model

JavaScript does not cost you only once.

It costs you in several stages:

• download
• parse
• compilation
• execution
• main-thread contention

So the question is not just:

How many kB do I have?

The better question is:

How much code am I making the user download, interpret, and execute before they can use what actually matters?

That question leads to much better prioritization.

Breaking the problem down

First separate critical code from code that is just arriving too early

Not every piece of JavaScript needs to be in the first bundle.

Some code is truly needed for first paint or first interaction.

Some code can:

• load later
• load on demand
• stay off the client entirely

A lot of real gains come from that separation, not from obsessing over every function.

Then look for the big blocks, not the crumbs

Usually there are a few obvious suspects:

• a large library used for a tiny job
• a heavy component loaded on every page
• duplicated utility code
• a whole dependency pulled in for one function
• third-party code loading too early

It is common to waste time on cosmetic cuts while one large package still dominates the cost.

Remember that weight is not only network

Even when download time looks acceptable, parse and execution cost can still be high, especially on weaker devices.

That is why bundle size connects directly to:

• INP
• hydration time
• interaction jank

When cutting is not worth it

Not every reduction pays back the complexity it adds.

Examples:

• replacing a stable dependency with a fragile homemade solution to save a few kB
• making the codebase harder to maintain for a change with no real impact
• adding too much lazy loading and increasing flow complexity everywhere

The smaller number has to pay the bill in user experience or operational cost.

If it does not, it may just be vanity.

Simple example

Imagine a dashboard page that loads:

• a rich text editor
• a charting library
• a virtualized table
• analytics

All of that goes into the initial bundle.

The team decides to optimize by removing small helpers and refactoring utility functions.

Maybe they save a few kB.

But the real gain would probably come earlier from questions like:

• does the editor need to load on the first screen?
• do all charts need to be there before the first interaction?
• does this large analytics package need to arrive that early?

That is the point.

A good bundle is not only a smaller bundle.

It is large code kept out of the critical path when it does not belong there.

Common mistakes

• Treating every kB as if it had the same weight in the real user flow.
• Micro-optimizing utilities while a huge dependency stays untouched.
• Looking only at download and ignoring parse and execution.
• Adding excessive lazy loading without thinking about UX and complexity.
• Cutting a good dependency for savings that do not matter.

How a senior thinks about it

Someone who thinks well about bundle size usually prioritizes like this:

• which code is arriving too early?
• which dependency really dominates the cost?
• is this weight hurting network, CPU, or both?
• what can I remove from the critical path with low risk?

That is a better way to think than treating “small bundle” like an identity.

Seniority here means knowing that not every saving is worth it, while still seeing clearly when the app is paying too much for too much JavaScript too early.

What the interviewer wants to see

They want to see whether you:

• understand why bundle size matters
• can connect size to download, parse, and execution
• prioritize large, relevant cuts before cosmetic ones
• talk about the critical path instead of only talking about the number

If your answer sounds like “I would first look at what is loading too early and which dependency actually dominates the cost,” that already shows better judgment than a generic optimization list.

The best bundle cut is often code that never needed to be there that early.

Good performance does not come from counting kB with obsession. It comes from moving weight out of the wrong moment.