7 Comments

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:

WebsiteFile sizeMinifiedGzipGZip & minifiedSavings
amazon.com218,642197,03253,79349,0089%
cnn.com130,014121,53427,11425,3926%
twitter.com53,46546,60812,26211,4167%
xbox.com38,88824,1398,0756,79516%

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.

Comments

Comment by iamauser

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...

iamauser

Comment by 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.

Comment by Nick

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.

Nick

Comment by 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.