Code splitting is the practice of breaking a website’s JavaScript into smaller, separate files that load only when they are needed. Rather than shipping one giant bundle on the first visit, the browser pulls in a small core file to get the page running and fetches the rest on demand.
Think of moving house. You could pack everything into one enormous crate that takes two people and a long time to lift, or you could pack a few clearly labelled boxes and only carry in the one for the room you are setting up first. Code splitting is the second approach: the checkout logic does not load until someone reaches the checkout, and a heavy chart library does not load until a chart is actually on screen. This ties closely to lazy loading, where files are deferred until the moment of use, and it leans on a bundler to decide where the split points go.
The payoff shows up in real numbers. Smaller initial downloads improve Core Web Vitals and shorten the load time, which matters most on mobile connections where every kilobyte counts. The trade-off is a little extra complexity: split too finely and you create lots of tiny requests, split too coarsely and you lose the benefit.
The natural place to split is the route. A blog reader rarely needs the code behind the admin dashboard, so that code stays in its own chunk and never loads for them. Same for a date picker or a video player that only appears once a user clicks. Get the boundaries right and the first paint feels almost instant.
At TopDevs we set split points around routes and the heaviest interactive pieces, so a client’s site feels quick on the first paint and the rest of the JavaScript arrives quietly in the background.
