The race for the smallest CSS files continues

The journey marches on

A week or so ago, I have released the CSS Remynifier onto the world. I have received many comments and I have been tinkering with CSS on and off to take the comments into account.

So far we only have one bug in csso fixed out of that. Not a bad start, but there are so many more things to investigate.

Let's go on and get some more data about how compression works together with minification.

It will be compressed, mate!

Quite a few people have, rightly, mentioned that CSS almost never gets sent down the wire uncompressed. This is true.

I will run a large comparison here. We will have the inputs minified using various minifiers and compressed using various compression methods. Let's see how they compare and how they match up.

First, meet the contestants:

In the compression corner we have gzip -9, the gold standard for compression that is fast to apply. You aren't going for gzip because you want the smallest files possible. You go for gzip because you want to pack things up quickly and need the files to be unpacked everywhere.

Also on team compression, zopfli. zopfli produces files in the same format as gzip, but compressed better. The good news is that every piece of software that can decode a file encoded with gzip can also decode files done with zopfli.

Finally, brotli, the problem child. No one loves brotli. Servers still don't support it out of the box as much as they should. Browser support is a bit under 60%. brotli, however, offers much better compression rates.

In the other corner, we have the four minifiers: csso, crass, cssnano and cleancss. All minifiers seem decently capable. We don't have any of this "remove spaces" stuff here. Each minifier can perform transformations that actually reduce the size of the CSS that is being minified.

I'm also going to run the Remynifier using a combination of the four minifiers. Because I can and it amuses me, that's why. I won't make it the focus. Let's go.

The results are in!

First of all, let's take a look at the results from the compression run.

(Remember, the tables are draggable/scrollable if they don't completely fit on your screen.)

Yes, using zopfli saves bytes over using gzip. Let's throw in brotli too. I'm running it at the 11 quality level and with window setting of 24. This is the maximum setting available and it is still quite quick.

brotli is a big win, even over zopfli. Runtime not being my goal, I did not time it, but it did run noticeably faster as well.

Apparently using a better algorithm/file format is a better idea than trying to make the old one behave. Reverse compatibility is both a blessing and a pain that we have to live with.

I won't waste too much of my time in experimenting with silly things, but compressing bootstrap.css with the paq method, as seen in lrzip, gives me a file size of 16364. We are nowhere near the level of desperation that is required to use paq for CSS, so I'll end this here. Not like there's browser support for that anyway.

Next up...

The minifiers step up!

Instead of relying on the data from a table I found online, this time I ran all the minifiers myself.

Well, that's a nice table, but kinda hard to put it into context. Let me help. I'm going to pick the best minifier for a given file and I'm going to compare it against brotli.

When minifying, by using the best minifier for a given file, we saved 38% over the entire corpus. By compressing with brotli we saved 87%.

This is quite interesting. Compression ran much faster and produced much better results than minification. If you are going to use only one technique to make your CSS smaller, make it be some kind of compression. There is also something to be said about the ability of minifiers to make undesirable changes to the CSS. There is probably some degree of safety in using a non-optimizing minifier together with compression.

Speaking of which!

How about we work together?

Nothing limits us from working together. We can combine minification and compression. I take the best result of each minifier and feed it into brotli. The last column of the table will tell you which of the minifiers produced the smallest compressed file.

Yup, brotli and minification work just fine together. I have heard a rumour, but a company connection has supposedly seen some cases where gzip (or even zopfli) could not cope very well with the results of minification. Apparently a minified file would compress worse than an unminified one. brotli has no such issues. It, at maximum settings, eats all that CSS up for breakfast and asks for a second helping.

There is an interesting behaviour happening here as well. The smallest CSS file after minification does not always correspond to the smallest file when compressed. For example, 960.css was at the smallest size when minified with crass. However, the smallest .br resulted from initially minifying with cssnano and then applying brotli. I think that a big benefit to minification would be to try to consider the effects of compression on the output files. Something to give more thought to, I reckon.

I wonder if crass optimizes for compressed size. It did really well here. Congratulations, team crass.

Enter the Remynifier

So... how does this work for everyone's favourite thought experiment in CSS butchery? The usual caveat of this possibly wrecking your CSS still applies, but let's do it for the sake of playing around. What is the absolutely lowest file size that we can get from our input CSS files, under the assumption that Remynifying is safe enough for our use case?

Since this is just a funny experiment and I'm busy enough with my day job, I will do this on just one file. I hear a lot about this bootstrap thing, so let's go with that.

Well, it did improve things, but not exactly in a way I'd call significant. At this point we are playing CSS size-reducing drag racing. Not saying it isn't fun, but the practicality just isn't there.

But I think we can do a bit better.

The Remynifier needs a change. Previously I had it only deal with the CSS files, aiming to get the smallest CSS file. Now, however, we are in need of the smallest compressed CSS file. This is a bit harder. The minifiers don't aim for the post-compression size. While we hope that a smaller CSS file will produce a smaller compressed file, we have no guarantees.

Good thing about the search procedure is that it can cope with a bit of disconnect between the metric we are actually optimizing and the goals of our minifiers. Simple: I apply brotli to the output of the minifiers when checking for an improvement over the previous best answer. I still keep the CSS file for the purposes of feeding it to a next minifier in the pipeline, but the best file is decided based on the results of the brotli compression.

Of course, because our search is not as guided as before, we need to use a bigger search depth.

Here's what I, much later, got!

Best size: 14941

Minifier sequence: bootstrap.css>cssnano>crass>csso>csso>cssnano

Yay! I have a further 119 bytes saved!

I still don't think this is worth it, considering that the saved bytes might have come from your CSS being mangled. But yes, we can still, in theory, save those bytes.

The search, sadly, devolved into being completely brute-force. It is hard to predict the compressed size from the minified size, which makes it hard to quickly discover a good chain of minifiers.

Closing thoughts

I'm still a bumbling fool who barely knows what they are doing. (Corrections welcome!)

brotli is awesome. Use it.

crass is awesome under brotli. I'm probably going to be using it.

Minification is nowhere near as important as compression. The two play well together, at least in case of brotli.

I should write up something to detect minifiers breaking the CSS. Easier said than done.

I also should write up something about what the minifiers change and look for missed optimizations.

Making a minifier that does really well under compression seems like a neat task.

I need to lose weight. Too many Swiss bready things.

And if you guys be willing to give me a tiny bit of change so I could break even on this whole subproject without running ads, that would be lovely! Thanks.