HTML Minifier

The smallest of the three wins

Of the three assets a page loads, HTML is usually the one where minification matters least, and it is worth being honest about that. HTML documents tend to be smaller than the stylesheets and scripts they pull in, and their tag structure is so repetitive that gzip compresses it exceptionally well before minification adds much. It is still worth doing in an automated build — free bytes are free bytes, and on a high-traffic site the bandwidth adds up. But if a page is slow, the HTML is rarely the culprit. Look at the images, then the JavaScript, then the render-blocking CSS, and expect to find the real problem well before you get to the markup.

Whitespace is not always meaningless

The reason HTML minification is riskier than CSS minification comes down to a quirk of the rendering model. HTML collapses consecutive whitespace into one space rather than deleting it, and between inline elements that surviving space is painted on the screen. A row of inline-block buttons separated by newlines in the source will render with visible gaps between them; remove the newlines and the gaps vanish. That is a real, visible layout change caused by what looks like a purely cosmetic edit. Good minifiers know this and preserve a single space where one would have been rendered — but it is exactly why you should look at the page after minifying rather than trusting that markup transformations are always safe.