This content originally appeared on Go Make Things and was authored by Go Make Things
This week, I wrote about using the CSS @import rule to modularize CSS, and some performance challenges with that approach. I ran a few additional tests, and wanted to share the data I found.
tl;dr: the issue isn’t the @import rule itself, but that files under 1kb often end up the same size or even bigger when gzipped, so you get no compression benefits.
Let’s dig in!
wtf is gzip!?
The .gzip format is a compressed file format, a lot like .zip. It reduces the size of your files by, on average, 70 percent. That’s huge!
Gzipping a file means sending it down the wire in this compressed format.
The cool thing about gzipped files is that they can be sent compressed in that format from the server, and browsers can unzip them and run them on-the-fly. Even though that involves some work for the browser, because the how much it reduces the size of files, it has a dramatic improvement on web performance.
But, compression is kind of weird.
You’d expect compression to work uniformly, but it doesn’t. Small files see their size shrink by very little. In some cases, the compressed files are bigger than the original. By comparison, large files compress by orders of magnitude.
I wanted to test how different sized bundles for Kelp, my HTML-based UI library, were affected by gzipping.
Current Setup
This is how Kelp is currently setup while in development in alpha…
- 40 modular CSS files
- All imported from a single
kelp.cssfile hosted on JSDelivr - Average file size of ~0.5kb
| File | Transfer Size | Unzipped Size |
|---|---|---|
| Combined modular files | 29.2kb | 47kb |
With gzipping, some files were ½ the size of the original, some were the same size, and many were a little bigger than the uncompressed files.
Concatentated Setup
I used ESBuild to create some bundles, then ran them through gzip with the stock settings.
- Complete - the entire library
- Core - all required CSS variables + styles for native HTML elements
- Utilities - The complete set of utility classes
- Core + Utilities - The core and utility files combined, but none of the components
| File | Transfer Size | Unzipped Size |
|---|---|---|
| Complete | 8kb | 43kb |
| Core | 6kb | 31kb |
| Utilities | 1kb | 7kb |
| Core + Utilities | 7kb | 39kb |
As you can see, compressing bigger files resulted in files that were more than 80-percent smaller!
Conclusions
Based on this, the native @import approach is a terrible idea.
If the files I was importing were larger, it might make sense. As tiny, modular files? Not so much!
The complete library concatenated and gzipped is less than a single HTTP request. It’s just over 25-percent of the transfer size of sending modular gzipped files instead.
However, the complete code base will continue to grow as a I add more components. I’ll need to run more tests then and figure out the right move.
Like this? A Lean Web Club membership is the best way to support my work and help me create more free content.
This content originally appeared on Go Make Things and was authored by Go Make Things
Go Make Things | Sciencx (2025-06-27T14:30:00+00:00) gzip performance is wild!. Retrieved from https://www.scien.cx/2025/06/27/gzip-performance-is-wild/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.