The 100% correct way to split your chunks with Webpack
--
Working out the best way to serve up files to your users can be a tricky business. There’s so many different scenarios, different technologies, different terminology.
In this post I hope to give you everything you need so that you can:
- know what file-splitting strategy will work best for your site and your users
- know how to do it
According the Webpack glossary, there are two different types of file splitting. The terms sound interchangeable, but are apparently not:
Bundle splitting: creating more, smaller files (but loading them all on each network request anyway) for better caching.
Code splitting: dynamically loading code, so that users only download the code they need for the part of the site that they’re viewing.
That second one sounds far more appealing, doesn’t it? And in fact, many articles on the matter seem to make the assumption that this is the only worthwhile case for making smaller JavaScript files.
But I’m here to tell you that the first one is far more valuable on many sites, and should be the first thing you do for all sites.
Let’s dive in.
Bundle splitting
The idea behind bundle splitting is pretty simple. If you have one giant file, and change one line of code, the user must download that entire file again. But if you’d split it into two files, then the user would only need to download the one that changed, and the browser would serve the other file from cache.
It’s worth noting that since bundle splitting is all about caching, it makes no difference to first time visitors.
(I think too much performance talk is all about first time visits to a site. Maybe this is partially because ‘first impressions matter’, and partly because it’s nice and simple to measure.)
When it comes to frequent visitors, it can be tricky to quantify the impact that performance enhancements have, but quantify we must!
This is going to need a spreadsheet, so we’ll need to lock in a very specific set of circumstances that we can test each caching strategy against.
