Code Splitting Architecture

Code splitting is the bundler-level technique of dividing an application's JavaScript into multiple smaller files (chunks) that are downloaded on demand rather than all at once, reducing the initial payload and improving time to first interaction.

Without code splitting, a large SPA might ship a single JS file that includes every page, component, library, and utility in the application. A user visiting the home page downloads code for the admin dashboard, the data visualization library used only on the reports page, and the PDF export module used on the settings page — none of which they need. Code splitting eliminates this waste.

There are three main code splitting strategies, often used together. Entry-point splitting creates separate chunks for each entry point in the application — useful in multi-page apps. Dynamic import splitting creates a chunk boundary wherever import('./module') appears in the source; the bundler automatically separates that module and its dependencies into an async chunk. Vendor splitting (also called chunk splitting or splitChunks in webpack) extracts shared libraries like React, lodash, or chart libraries into a separate vendor chunk that can be cached independently from application code — since vendor code changes less frequently than business logic.

The bundler outputs a chunk manifest (a JSON map of chunk names to hashed filenames) that the application runtime uses to know which file to load for a given route or component. Frameworks like Next.js and Vite abstract this behind conventions: files in /pages or /routes become automatic route-based chunks.

At runtime, chunk loading is coordinated through the bundler's runtime module system injected into the main bundle. When a dynamic import resolves, the runtime inserts a