HTML minifier revisited

You can see from this image — http://perfectionkills.com/images/minifier_benchmarks.png — that pages under 100KB are all under a second. But then it grows. I suspect regex parsing (not catastrophic but close) to be the culprit. If you have time to look into it and optimize — that would be super helpful, of course!

I'd have to agree, while not exactly the same, Google's closure compiler only starts to take a noticeable amount of time when you get into the thousands of lines.

The 7.7s to process a 400KB page (Wikipedia) is particularly surprising. Assuming a processor that executes ~2 billion instructions a second, that's roughly 37,000 instructions executed for each byte of input, or a throughput of ~52KB/s. I wonder where all the time is being spent, as from my understanding minifiers just parse the input document and then write it out in some smaller canonical form.

Also, please, whenever you publish benchmarks, always include the specifications of the system they were performed on! 52KB/s may be horribly slow on a 3GHz i7 but pretty good for a 100MHz Pentium.

It's not so much about invalid HTML as it is about superset of HTML. I don't like it either but certain constructs seem hard to implement otherwise. Changing attribute value is easy within HTML boundaries but anything related to presence of attribute and they have no choice but to wrap it somehow (they could wrap it with other attributes, of course, but that would probably be too verbose).

One of the reasons I added this support was so we could use the parser on our client-side handlebars templates to identify glyph usages and build the smallest possible custom fonts.

I've been using <script type=”text/html“> to hold bits of HTML I want to quilt together client-side.

I build all my templates in HTML, and then store all the different content to populate the templates in script tags. I can then use JavaScript to swap it out, and even hide/reveal unused templates.

It's 100% valid though, handlebars are not valid HTML, at least not until processed and rendered.

It's less data over the wire. Same benefits as minifying CSS and JS.

I agree. Plus if you activate any kind of caching / gzip compression the difference in the end is minimal. (entropy roughly the same => document roughly the same size)

Pays off? There might be little to gain from it, but on the other hand there is barely anything to lose. If you can shave 10% of your 200k pages in the couple of seconds the benchmarks took, I don't see why not.

I don't see why this might as well not be the default, if more browsers' source view would just de-minify CSS/HTML/JS automatically.

EDIT: Especially in mobile/touch-only browsers who are extremely unlikely to inspect the code. So do it for m.example.com, I reckon.

I myself have gotten a little lazy, because I'm hosting my static websites behind CloudFlare who do minification anyway, so I haven't thought much of this in a while.

Google minifies HTML on basically all its properties. It's probably about a 50% savings in bytes, which translates to (on my Comcast connection) about 250ms in network latency saved. Multiply out by rough estimates on queries/day and it saves a human lifetime every 2 days.

Repeated experiments - by Google, Amazon, and many smaller websites - have shown that lower latency directly translates to higher conversion rates, so I wouldn't be surprised if this results in billions of dollars of extra commerce, and even a small website would get noticeably higher revenue if they did this. Google also ranks faster websites higher, and so you get an SEO benefit as well.

To me the more interesting scenarios aren't related to size.

* Being able to embed comments which aren't visible to the world is very useful.

* Being able to remove non-important whitespace removes clues on the complexity of generation (though it's a super-complex thing to actually remove only the non-important whitespace thanks to <pre> and CSS styling).

* Linting is another area where things are interesting too. Validators might tell you if your HTML is well structured per the specs, but my js skills and habits have improved as a result of linting. The process might tell you that it's best practice to use readonly instead of readonly="readonly" on an element or similar. Sure, not directly related to minification, but the parsing needs to be done already.

* Minification adds some security through obscurity by making stuff like XSS attacks slightly more difficult (if you use name/id/class mangling). I've only seen this in practice on gmail (most gmail browser addons/scripts break every couple of months when google changes something that alters the generated button ids)

I haven't seen minification done on raw HTML, but have seen non-html solutions used in order to be able to include comments - this is a bit dumb to me.

I've used HTML preprocessors to concatenate separate (single page app) html resources (templates) for delivery, so the pipeline's already there.

You don't want to use HTTP or TLS compression when using TLS. Because compression breaks TLS. And then Russian hackers can steal your session ids and CSRF nonces.

But you can minify your HTML at least.

Compression kills TLS.

Smart competitors will just run it through Tidy :)

Hm, really? Works for me on http://kangax.github.io/html-minifier/