[Go Make Things] Modular CSS Redux

Thursday, June 26, 2025

They say the best way to get an answer to a technical question is to post the wrong answer on the internet!

Yesterday, I wrote about modular CSS architecture using the browser-native @import operator. And while I wouldn't say that what I wrote was wrong, I did learn a whole lot and have some really interesting conversations that shifted my perspective a bit.

Let's dig in!

Gzipping makes things weird

The modular files in Kelp are really small. The average size is about 500 bytes (or 0.5kb).

Gzipping can make large files shockingly small. But for smaller files, especially those below 1kb in size, it can actually make them larger.

Looking in developer tools, I noticed that the gzipped size a lot of Kelp's files were up to twice as large as the actual asset size. Gzip is taking a 0.3kb file, and compressing it into a 0.7kb one.

Transfer size and network cost

This article from Joe Honton on the gzip penalty also adds an additional data point…

Data transmission through the TCP/IP stack is governed by the Ethernet Maximum Transmission Unit (MTU). It's a fixed size. On most Ethernet NICs it is 1500 bytes. Responses where the HTTP headers plus payload is less than the MTU, all pay the same network cost.

That means if you're shipping a 300 byte file or a 1200 byte file (0.3kb and 1.2kb, respectively), the network cost is identical.

Putting it together

I did a quick test.

I took the six layout files from Kelp, and concatenated them into a file. Then I gzipped it.

The average individual file size was ~500 bytes. The combined size was 2.8kb.

The combined, gzipped size? 943 bytes.

Combining and gzipping a bunch of files resulted in nearly the same file size as gzipping one smaller one. And because of MTU, the network cost of both files is the same, but you're making 5 fewer network calls by concatenating.

Like I said earlier: gzip is weird!

What does this mean for Kelp?

Honestly, I'm not sure yet.

I still very much want to keep Kelp build-free. That goal hasn't changed, and I can't see myself going back on it.

But the math also makes it pretty clear that larger bundles of gzipped files has the same performance impact as one smaller gzipped file.

Based on that, I think it's likely that I'll do what I originally planned: create pre-compiled bundles that users can grab as needed…

The theme
Native element styles
Layouts
Utility classes
Popular components

And then I'd also offer a complete bundle, and the option to independently load components as needed.

As a benefit, this approach potentially reduces mental overhead. Or not. I dunno!

The challenge of building a system like this is that I need to account for a bunch of use cases I don't know about and can't predict. I want to be as flexible as possible, while also not making the web worse.

What's your ideal setup?

I've had a lot of people tell me they want something buildless, that they can just drop into projects and run with.

I'd love to hear what your ideal setup would look like. How would you want to customize what you're loading?

Right now, Kelp is pretty small. Once I build out the various components, I'm not sure I'd recommend loading the entire thing when projects don't need all of the components.

I'm building Kelp out in the open. You can follow along at KelpUI.com.

Like this? A Go Make Things membership is the best way to support my work and help me create more free content.

Cheers,
Chris

Want to share this with others or read it later? View it in a browser.

Did someone forward this to you? Get Daily Developer Tips.

Don't want to get these emails? Totally cool. Update your subscriber preferences.

You can also unsubscribe from all emails from me, including updates to products you've purchased.

113 Cherry St #92768, Seattle, WA 98104-2205

.