Let’s Talk again about Minification

Seriously, stop suggesting this optimization

I’ve just finished building a site for a client, and it is one of the fastest sites I’ve built in a long time, even with jquery and 4 additional libraries included(jquery modal, bxslider, typeit, and skrollr).  The site is lean, with measurements in size of just under half a meg per page.  I’ve gotten scores of 99 on GTmetrics, 100 on pingdom, and 97 on Pagespeed insights on this site.  

‘Great!’, you might say, but you might also wonder what I’m still being dinged on to keep me from 100 on GTMetrics and Pagespeed Insights.   It’s the usual song and dance about parsing of javascript(and Oh no, I have a whole 129 BYTES of JS inlined! HORRORS!), oh and the ever insistent demand I minify my CSS.

I still won’t minify.  According to Pagespeed Insights, taking my beautiful, human-readable CSS and compressing it into an unreadable mess that I will have to use bower or some other godawful client-side/server-side toolkit to compile/decompile my CSS would save the website viewers from loading the horrors of extra whitespace in my CSS totalling up to… 2.4 kilobytes.

Now, I know we’ve talked about this before, but I’m going to talk about it again.  I’m not going to add additional server-side tools to compile CSS files for me to save 2.4 kilobytes.  I’m not going to keep human-readable and machine-readable files side-by-side to save 2.4 kilobytes.  I’m not going to change my workflow for 2.4 kilobytes.  

Now, the reason people love minification is because they love their toolkits.  They love pre-processors, post-processors, setting up environments, and big, clunky frameworks that has so much excessive styling and code that you might actually get real savings if you minify the CSS files.  I propose the problem is not that I don’t minify my CSS, but that your workflow is so clunky that you NEED to minify your CSS.

Minification would only save me 2.4 KB.  You need to be a on a 28.8 modem before the time difference in loading the extra 2.4KB would be noticable.  The site loads in less than half a second on a 3G network.  I’ve decided to do a little experiment: I’ve compiled the css measurements of my site both with and without g-zip compression and minification, both using Shipwright and using Bootstrap.

My entire CSS stack, including custom CSS for this site and Shipwright as a framework weigh in, together, g-zipped at 16kb.  Non-minified and non-gzipped, the site css weighs in at 81kb.  

If I take Bootstrap and my custom css together, impling any custom code to duplicate the site I built would, at minimum, mirror what I wrote for Shipwright, the site would weigh in, non-minified and non-gzipped, at 221kb.   Gzipped, the size would be 25kb.  Non-compressed, the CSS stack is nearly triple the size simply by using Bootstrap.  Compressed, the size is nearly double.  

What we have here is a systemic problem of people used to large, bloated frameworks that bloat the web, creating the false dilemma and need to minify CSS, destroying readability in favor of savings that measure less than a megabyte.  You can get even more savings by using a lighter framework, or even no framework at all.  You can also decrease the number of programs you use for development, decrease the number of steps you need to use before deployment of changes, and overall simplify your life.  

The most radical thing I will declare right now is we should stop listing CSS minification as a speed optimization if the resulting minification reduces file sizes less than 10kb.  The minification process does not produce meaningful savings that are noticeable by the end-user, and listing them as an optimization process only encourages younger devs to destroy human-readability versus teaching them good dev habits.