Code Splitting
Code splitting is the practice of dividing an application's JavaScript into separate bundles that can be loaded on demand, rather than sending everything in one monolithic file.
§ 1 Definition
Code splitting is the solution to the single-bundle problem. Without it, every user downloads the entire application's JavaScript even if they only visit one page. Code splitting divides your code into chunks that are loaded when needed. Dynamic import statements (`import('./module.js')`) are the primary mechanism. Bundlers like Webpack and Vite detect these dynamic imports and automatically create separate output chunks. When the code is needed (a route is visited, a modal is opened, a feature is triggered), the browser fetches the chunk. Code splitting is essential for any application larger than a few pages. It directly reduces Time to Interactive (TTI) and saves bandwidth. The most common strategy is route-based splitting: one chunk per page or view. Component-level splitting is used for heavy components (editors, charts, maps) that are not immediately visible.
§ 2 How it works
Replace static imports with dynamic imports: `const AdminPanel = () => import('./AdminPanel.js')`. The bundler creates a separate chunk for AdminPanel. When the code runs, the browser fetches the chunk asynchronously. With React, use `React.lazy()` and `<Suspense>`. With Vue, use `defineAsyncComponent`. The bundler handles chunk naming, hashing (for cache busting), and preloading/prefetching hints.
§ 3 Splitting strategies
Route-based: each route gets its own chunk. This is the most impactful strategy. Vendor splitting: separate framework code (React, Vue) into a vendor chunk that changes rarely and can be cached aggressively. Component-based: split heavy components that are not needed immediately (image editors, rich text editors, data visualization libraries). Library-based: split third-party libraries that are only used in specific contexts.
§ 4 Common misconception
Code splitting is not free. Each chunk adds an HTTP request, and loading chunks adds latency to navigation. Over-splitting (creating hundreds of tiny chunks) can harm performance. The goal is to split enough that the initial bundle is small, but not so much that navigation is laggy. Use preload (<link rel="preload">) and prefetch (<link rel="prefetch">) hints to load critical chunks proactively. Also, code splitting without proper loading states results in a poor user experience (flash of blank content while chunks load).
§ 5 Note
§ 6 Common questions
- Q. What is the difference between code splitting and tree shaking?
- A. Tree shaking removes unused code from the final bundle at build time. Code splitting creates separate bundles that load on demand at runtime.
- Q. Does code splitting work with CSS?
- A. Yes. Most bundlers can split CSS alongside JavaScript chunks, loading the CSS when the component or route is loaded.
- Code splitting divides JavaScript into chunks loaded on demand, reducing initial bundle size.
- Route-based splitting is the highest-impact strategy for most applications.
- Balance chunk granularity: too few chunks = large initial bundle, too many = excessive HTTP requests.
Atomic Glue implements strategic code splitting for fast application performance. We measure bundle impact and optimize chunk strategies. Our Website Development services deliver lean apps.
Get in touchCode splitting is the practice of dividing an application's JavaScript into separate bundles that can be loaded on demand, rather than sending everything in one monolithic file.
Category: Web Development (also: Performance, Cro)
Author: Atomic Glue Team
## Definition
Code splitting is the solution to the single-bundle problem. Without it, every user downloads the entire application's JavaScript even if they only visit one page. Code splitting divides your code into chunks that are loaded when needed. Dynamic import statements (`import('./module.js')`) are the primary mechanism. Bundlers like Webpack and Vite detect these dynamic imports and automatically create separate output chunks. When the code is needed (a route is visited, a modal is opened, a feature is triggered), the browser fetches the chunk. Code splitting is essential for any application larger than a few pages. It directly reduces Time to Interactive (TTI) and saves bandwidth. The most common strategy is route-based splitting: one chunk per page or view. Component-level splitting is used for heavy components (editors, charts, maps) that are not immediately visible.
## How it works
Replace static imports with dynamic imports: `const AdminPanel = () => import('./AdminPanel.js')`. The bundler creates a separate chunk for AdminPanel. When the code runs, the browser fetches the chunk asynchronously. With React, use `React.lazy()` and `<Suspense>`. With Vue, use `defineAsyncComponent`. The bundler handles chunk naming, hashing (for cache busting), and preloading/prefetching hints.
## Splitting strategies
Route-based: each route gets its own chunk. This is the most impactful strategy. Vendor splitting: separate framework code (React, Vue) into a vendor chunk that changes rarely and can be cached aggressively. Component-based: split heavy components that are not needed immediately (image editors, rich text editors, data visualization libraries). Library-based: split third-party libraries that are only used in specific contexts.
## Common misconception
Code splitting is not free. Each chunk adds an HTTP request, and loading chunks adds latency to navigation. Over-splitting (creating hundreds of tiny chunks) can harm performance. The goal is to split enough that the initial bundle is small, but not so much that navigation is laggy. Use preload (<link rel="preload">) and prefetch (<link rel="prefetch">) hints to load critical chunks proactively. Also, code splitting without proper loading states results in a poor user experience (flash of blank content while chunks load).
## Note
Measure before and after splitting. Use the Coverage tab in Chrome DevTools to see how much JavaScript is unused on initial load. Code splitting should reduce that percentage significantly.
## Common questions
Q: What is the difference between code splitting and tree shaking?
A: Tree shaking removes unused code from the final bundle at build time. Code splitting creates separate bundles that load on demand at runtime.
Q: Does code splitting work with CSS?
A: Yes. Most bundlers can split CSS alongside JavaScript chunks, loading the CSS when the component or route is loaded.
## Key takeaways
- Code splitting divides JavaScript into chunks loaded on demand, reducing initial bundle size.
- Route-based splitting is the highest-impact strategy for most applications.
- Balance chunk granularity: too few chunks = large initial bundle, too many = excessive HTTP requests.
## Related entries
- [Bundling](atomicglue.co/glossary/bundling)
- [Lazy Loading](atomicglue.co/glossary/lazy-loading)
- [JavaScript](atomicglue.co/glossary/javascript)
Last updated June 2026. Permalink: atomicglue.co/glossary/code-splitting