This week, I wrote about using the CSS @import rule to modularize CSS, and some performance challenges with that approach.
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.
I ran a few additional tests, and wanted to share the data I found.
- 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 1/2 the size of the original, some were the size, and many were a little bigger than the uncompressed files.
kelp.complete.css- the entire librarykelp.core.css- all required CSS variables + styles for native HTML elementskelp.utilities.css- The complete set of utility classeskelp.core-utilities.css- 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 |
Based on this, the @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% the transfer size of sending modular gzipped files instead.
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.