This content originally appeared on Go Make Things and was authored by Go Make Things
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 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-26T14:30:00+00:00) Modular CSS Redux. Retrieved from https://www.scien.cx/2025/06/26/modular-css-redux/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.