This, my friend, is monkey advice. Meaning, it is written for monkeys.
Worse, this is not the problem of slow or underperforming websites.
Yet, we hear website administrators clap and jump for joy when they’ve properly minified their assets. Web Performance auditing tools (like GTMetrix and Google Page Speed Insights) all give you little green lights of praise when you do, and scold you in alarmingly red colors when you don’t.
But let’s be real for a minute: minifying is a machine process, not a human one. It is not something humans should be doing.
In fact, most modern web development practices setup minifying into task runners like Grunt and Gulp as simply “part of the process” of their build setups.
Personally, I think all the hullabaloo is not only silly, but is missing the real issue.
You can minify that bloat until the cows leave the internet, but it’s not going to make any appreciable difference.
Don’t even tell me that your next “tip” will be to combine your CSS files into one massive missile of CSS.
Do you think all the computation only happens during your task runner’s build process? Do you have any empathy for the little browser trying to make sense of your 4,000 lines of CSS code?
And when there are those kinds of CSS files, you can be sure they are accompanied by 30-character class names like “page-builder-2-clear-fix-left” which is always fun to send that across the internet in your HTML about 19 times per page load.
If only we could watch the DOM elves try to make sense of the nested DIV hell delivered and then try to parse a 4,000 line CSS file just so your little submit button can hover a darker shade of blue.
Ladies and Gentleman of the Enterprise World: If your web developers are toying with their Make and Grunt files and convincing you they are making your website fast, look deeper.
That job can – and will soon – be done by monkeys, er, machines. I think it is only a matter of time before prominent CMSs like WordPress just automatically minify CSS and JS out of the box.
Themes and Plugins will come with non-minified assets (for the purposes of debugging) and will be required to demonstrate their intended purposes via comments (as WordPress itself does in PHP), and then when “activated”, they minify them on-the-fly. If you make a change in the “pretty” version via the custom code option, WordPress will one day just minify it again for you.
So, minifying is not, and never really has been, the problem. It was an overhyped fictional worry, even in the days of slow browsers and DSL. No one ever doubled the speed of a website by minifying the JS and CSS.
The alternative is to get knee-deep into the code and fix the bloated and excessive file loading.
My rule of thumb for a truly performant website is to look at the five most heavily trafficked pages and see how many lines of unused CSS there are. If it’s more than just a few lines, something’s up.
Stop minifying files and calling your work “performant”. Instead, find out why you have four different classes for identifying errors on a web page and “minify” that (i.e., get rid of three of them).
To do so, you’ll have to rely less on frameworks and more on web standards.