HTML minify – to be or not to be?
Let’s review today such a contradictory point in website acceleration as HTML minify. It’s one of our steps to bring extreme performance to our website. And it can reduce load time not only for the first-time visitors, but also for returned ones and if readers are going to the next posts in our blog – for second pages and so on.
HTML minify challenges
Well. It seems be very simple – just remove all unnecessary symbols from HTML code. But what symbols are excessive? First of all – all line breaks and double spaces. But should we remove really all of them? The correct answer is – no. We can’t remove for sure any symbols from tags pre, textarea, and script to reduce overall HTML code size.
OK. We can leave these tags as they are. What else? Also we can’t touch aggressively line breaks inside inline elements (or between them) – because they are equivalent to spaces (per contra we can safely remove all space-like characters between block elements without any actual losses).Well… The hour is not easier.
Also we can remove HTML comments if they are not served to IE browsers (because latter can parse conditional comments). Or we should remove all comments exclude conditional.
Practical solution
There are a lot of reefs and too little possible gain. You can apply all HTML minify actions by hand (through your template code and blog posts). But this isn’t worth expected speedup.
You can also try to implement some (semi) automated solutions. But please don’t use W3 Total Cache plugin for aggressive HTML minify – it can break your layout. WEBO Site SpeedUp which is being used for this website has complete support for all actions to minify data size including HTML documents.
Let’s try to enable HTML minify, Remove HTML comments (conditional comments are removed for non-IE browsers only), and ‘HTML-to-1-string’ options. Here is final YSlow chart.
In comparison with the last performance situation we have eliminated 0.6 Kb (remember – we are already using gzip compression), which is about 11% from HTML document and about 0.15% from page load speed. But it’s valid only for new visitors.
For returned visitors (is they have all the other resources cached – CSS, JavaScript, images) we have here 10% additional speedup. Except HTML document we have only small Google Analytics GIF-counter, which loads rather quickly. But in case of loading all assets from cache we face with rendering expenses. And actual speedup here will be less (we will try to count it in the future with rendering measurement).
Conclusion
HTML minify isn’t worth to be implemented for a common website. It does too little and can be very CPU (or time) expensive. If you are already using some strong caching solution – it’s better to include HTML minify to it. In all the other cases you can leave this WordPress performance optimization practice for geeks only.
As an author of an HTML minifier, I agree. The best way to use this is to have it baked into the CMS/template system and minify partial content at store/compile time.
[...] HTML minify – to be or not to be? [...]