Last time we took a look at the performance impact of using tabs vs. spaces in HTML files. One question that arose was whether or not it’s worthwhile to minify HTML when also using GZip. Let’s run the experiment.

I’ve collected a few real-world HTML files and done some minification and GZipping on them. Here’s the result:

Website File size Minified Gzip GZip & minified Savings 218,642 197,032 53,793 49,008 9% 130,014 121,534 27,114 25,392 6% 53,465 46,608 12,262 11,416 7% 38,888 24,139 8,075 6,795 16%

These pages already do minification on various sections, but none of them minifies the whole document. If none of them used any minification, the savings would have been higher than the table shows.

So, according to the results, minification will provide an additional 6-16% lower file size with GZip enabled.

16% is a rather large saving on top of regular GZip, so the data suggests that we must use both GZip AND minification.

Remember, this is a rather small experiment with only 4 real-world websites. It would be interesting to expand the experiment for more accurate statistics.

For HTML minification in ASP.NET, I like to use WebMarkupMin or Meleze.Web.



Hi Mad,
thanks for the example.

Do you have a recommended tool that generates minified html on publish? (in VS)
It would be great to have the .aspx and .cshtml files minified on publish, so we don't need any additional process power on the servers...

Chris Marisic

@BB the Meleze.Web tool Mads mentioned does exactly what you asked.

@iamauser you would probably have to write your own scripts/addin that executes these tools and outputs new .cshtml files that are preminified in your build scripts.

Chris Marisic

This saves 1-2 packets per file. If the result of minifying isn't cached, I wouldn't be surprised if doing this actually reduced performance from the CPU overhead of running the script. In the tabs vs. spaces article, 5 bytes is less than alignment onto a DMA boundary and way less than a CPU cache line, so in all likelihood "Doesn't matter much" should literally be "Doesn't matter at all". DEFLATE should pretty much prevent a significant difference from being possible for larger pages since if it sees it enough, it will just consider 4 spaces to be an entry into its symbol table for Huffman coding (so it will become a 3-byte difference).

So basically, looks like premature optimization at the cost of a slightly more complex build/server environment and of the HTML output being less readable within browsers. You'd probably get a much better return from replacing photographic images encoded as .png with ones encoded as .webp or .jpeg.

Chris Marisic

Did you ever test if the performance cost of Meleze.Web exceeds the minification gains?

I would like to think that Meleze.Web only runs once and caches its work.

Chris Marisic

Comments are closed