This week, I wrote about [using the CSS `@import` rule to modularize CSS](https://gomakethings.com/rethinking-modular-css-and-build-free-design-systems/), and [some performance challenges with that approach](https://gomakethings.com/modular-css-redux/).

_**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.

## Current Setup

- [40 modular CSS files](https://github.com/cferdinandi/kelp/tree/main/css)
- All imported from a single `kelp.css` file 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.

## Concatentated Setup

- `kelp.complete.css` - the entire library
- `kelp.core.css` - all required CSS variables + styles for native HTML elements
- `kelp.utilities.css` - The complete set of utility classes
- `kelp.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 |

## Conclusions

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.