Code-Splitting und Lazy Loading

Shipping all JavaScript in one bundle forces users to download code for pages they may never visit. Code splitting breaks the bundle into smaller chunks loaded only when needed.

The dynamic import() expression returns a promise and tells bundlers to create a separate chunk. The module loads on demand at runtime.

The most impactful split is per route: each page becomes its own chunk, so the initial load contains only the landing route.

While a lazy chunk loads, show a fallback so the UI stays responsive. In React this is Suspense; other frameworks have equivalents.

Heavy widgets like rich text editors, maps, or charts can be split too, loading only when the user opens that feature rather than on first paint.

Separating third-party libraries into a vendor chunk lets it cache independently. App code changes frequently; vendor code rarely does, so users re-download less.

Lazy loading can add a delay when the user navigates. Prefetch the chunk during idle time, for example on link hover, so it is ready before the click.

Too many tiny chunks create request overhead and waterfalls. Aim for meaningful boundaries (routes, big features), not splitting every small function.

Code splitting pairs with tree shaking: use ES module imports and import only what you need so dead code never enters any chunk.

Use a bundle analyzer to inspect chunk sizes and the Coverage tab in DevTools to find unused code shipped on initial load. Lighthouse flags large unused JS.

• Split by route first.
• Lazy-load heavy components.
• Separate vendor chunks for caching.
• Prefetch likely-next chunks during idle.

You learned to shrink initial payload with code splitting: dynamic import(), route- and component-level lazy loading, vendor chunking, idle prefetching, and tree shaking. Split at meaningful boundaries and measure with a bundle analyzer.