FE5: Loading less, loading later
What's in your bundle, and splitting it
🎯You'll be able to
Read a bundle report and split code so each page ships only what it needs.
🏠The everyday picture
Packing for a two-day trip, you don't take your whole wardrobe. You pack what you'll need for those two days and leave the rest at home, ready if needed later.
📘What it really is
-
Build tools combine your code and libraries into bundles. Large bundles take longer to download and, more importantly on phones, to parse and run.
-
A bundle analyser (for example
@next/bundle-analyzer, orrollup-plugin-visualizerfor Vite) shows which libraries take the most space. Common surprises: a full date library for one function, a whole icon set for five icons, a charting library on every page. -
Code splitting: break the bundle so each page loads only what it needs.
- Route-based splitting happens automatically in frameworks such as Next.js: each page gets its own chunk.
- Component-level splitting: load heavy parts on demand with dynamic
import()(React.lazy, ornext/dynamic), such as a map, a rich-text editor or a chart that appears only after a tap. -
Tree shaking removes unused exports, but only if you import specifically (
import { format } from 'date-fns', not the whole library) and the library supports it. -
Set a budget, such as "under 170 KB of compressed JavaScript for the product page", and check it in every build.
📝A worked example
Kirana's analyser output for the product page:
| Item | Compressed size | Action |
|---|---|---|
| Charting library (used only on the admin dashboard) | 95 KB | Moved to the admin route only |
| Full icon set | 60 KB | Imported 12 icons individually: 4 KB |
| Moment.js with all locales | 70 KB | Replaced with Intl.DateTimeFormat and a small helper |
| Map for "store near you" | 110 KB | Loaded only when the customer taps "Change store" |
Product page JavaScript fell from 420 KB to 140 KB compressed, under the 170 KB budget.
🌍Where it's used
- Large apps that have grown over years.
- Pages with optional heavy features: maps, editors, video players.
- Performance budgets checked in the build pipeline.
📝Case scenario
A team adds a markdown editor for product reviews, and the product page's JavaScript grows by 180 KB, although only a few customers write reviews. Loading the editor with a dynamic import when "Write a review" is tapped returns the page to its previous size, and the editor still opens within half a second on 4G.
🖱️Try it
Run a bundle analyser on your Kirana app. List the five largest items, decide for each whether to remove it, import it more specifically, or load it on demand, and measure the page's JavaScript before and after.
⚠️Common mistakes
- Importing a large library for one small function. Sign: the bundle jumps by hundreds of KB. Fix: import only the piece you need, or write the small function yourself.
- Splitting everything into tiny pieces. Sign: many small requests slow the page. Fix: split at page and large-feature boundaries.
🛠️For your project
The starter deals page imports lib/deals-analytics.ts (about 420 KB). Project 3's JavaScript budget is 170 KB.
✅Quick check
What does a bundle analyser show?
Show the answer
Which code and libraries take up the most space in each bundle.
When should a component be loaded with a dynamic import?
Show the answer
When it's heavy and only needed after a user action or on some visits, such as a map or editor.