Compounding performance issues
About a month ago, I wrote a series of articles about modular CSS, compression algorithms like gzip and brotli, and why modular files and compression don’t play well together.
Based on all of this, I ended up including both pre-built and modular versions of the CSS and JavaScript files in Kelp, my UI library for people who live HTML.
The big tipping point for me came from running a handful of performance tests with the fully concatenated versus modular versions of Kelp, hosted on my own server instead of through the CDN.
| Bundled | Modular | |
|---|---|---|
| Total Size | 8.2kb | 27.2kb |
| Start Render (Cable) | 1.1s | 1.3s |
| Start Render (3g) | 2.2s | 3.5s |
When I first ran my tests on a cable connection, I saw that the modular setup was just 200ms slower to start rendering and felt like that was an acceptable tradeoff to have no build process at all.
But when I re-ran the tests on a 3g connection, I was shocked at how much bigger that gap got.
I knew it would grow a little, but over a second longer to load? That was genuinely surprising!
Now, to be fair, once you factor in caching and repeat renders, the numbers come down quite a bit!
| Bundled | Modular | |
|---|---|---|
| Total Size | 8.2kb | 27.2kb |
| First Render (Cable) | 1.1s | 1.3s |
| Repeat Render (Cable) | 0.7s | 0.9s |
| First Render (3g) | 2.2s | 3.5s |
| Repeat Render (3g) | 1.8s | 1.9s |
Once the files are cached, subsequent renders take just 100ms to 200ms slower with modular files compared to one bundled file.
Given that the guiding ethos of Kelp is that the web is for everyone, it looks like I should probably be encouraging folks to use a bundled version as the main entry point.
But this is a loosely held opinion, especially when I look at the repeat render times. What do you think?