45

Why do people suggest minifying web assets, such as CSS and JavaScript, but they never suggest the markup be minified? CSS and JavaScript can be used on many various pages while the markup gets loaded each and every time, making minification of markup far more important.

Salvador Dali
  • 214,103
  • 147
  • 703
  • 753
  • 8
    good question. probably because developers like to see their pretty code. – Jason Aug 20 '09 at 15:05
  • 15
    Even better is the people that think they're saving bandwidth by "minifying" server-side code (e.g. PHP)... – Breakthrough Aug 20 '09 at 16:35
  • @Breakthrouh: I understand what you are saying (regarding output to the browser), but I do wonder.. if the webserver passes on the php script (file) to the (optionally external) php fcgi-server, I would assume that bandwidth to the fcgi-server is indeed saved... Which also makes me wonder if a 'minified' php script saves memory (I mean, before it is converted to byte-code and executed).. – GitaarLAB Jan 24 '14 at 01:48
  • html content should be minified. Previously it was hard to do this and gave really small gain. Check [my answer](http://stackoverflow.com/a/22446770/1090562) – Salvador Dali Sep 02 '14 at 09:28

6 Answers6

39

The answers written here are extremely outdated or even sometimes does not make sense. A lot of things changed from old 2009, so I will try to answer this properly.

Short answer - you should definitely minify HTML. It is trivial today and gives approximately 5% speedup. For longer answer read the whole answer

Back in old days people were manually minifying css/js (by running it through some specific tool to minify it). It was kind of hard to automate the process and definitely required some skills. Knowing that a lot of high level sites even right now are not using gzip (which is trivial), it is understandable that people were reluctant in minifying html.

So why were people minifying js, but not html? When you minify JS, you do the following things:

  • remove comments
  • remove blanks (tabs, spaces, newlines)
  • change long names to short (var isUserLoggedIn to var a)

Which gave a lot of improvement even at old days. But in html you were not able to change long names for short, also there was almost nothing to comment during that time. So the only thing that was left is to remove spaces and newlines. Which gives only small amount of improvement.

One wrong argument written here is that because content is served with gzip, minification does not make sense. This is totally wrong. Yes, it makes sense that gzip decrease the improvement of minification, but why should you gzip comments, whitespaces if you can properly trim them and gzip only important part. It is the same as if you have a folder to archive which has some crap that you will never use and you decide to just zip it instead of cleaning up and zip it.

Another argument why it pointless to do minification is that it is tedious. May be this was true in 2009, but new tools appeared after this time. Right now you do not need to manually minify your markup. With things like Grunt it is trivial to install grunt-contrib-htmlmin and to configure it to minify your html. All you need is like 2 hours to learn grunt and to configure everything and then everything is done automatically in less than a second. Sounds that 1 second (which you can even automate to do nothing with grunt-contrib-watch) is not really so bad for approximately 5% of improvement (even with gzip).

One more argument is that CSS and JS are static, and HTML is generated by the server so you can not pre-minify it. This was also true in 2009, but currently more and more sites are looking like a single page app, where the server is thin and the client is doing all the routing, templating and other logic. So the server is only giving you JSON and client renders it. Here you have a lot of html for the page and different templates.

So to finish my thoughts:

  • google is minifying html.
  • pageSpeed is asking your to minify html
  • it is trivial to do
  • it gives ~5% of improvement
  • it is not the same as gzip
Salvador Dali
  • 214,103
  • 147
  • 703
  • 753
  • About HTML genrated by the server I think it's worth mentioning template engines like [jade](http://jade-lang.com/) which allow you to write well formatted markup in source and output minified HTML by default. It also allows you to easily deal with cases like the one mentioned in [Alohci's answer](http://stackoverflow.com/a/1308948/1774484) – Benjamin Albert Mar 28 '16 at 11:57
  • Minification removes maintainability for the sake of... usually about 4-8kb of savings on a site size. You can get more savings by compressing a single jpg on the site and removing the image's meta-data. – Mahdi Younesi Aug 18 '17 at 10:58
  • 2
    @MahdiYounesi no one maintains minified assets. When you minify the html you are not removing an existent non-minified version. Also no one told you that once you minify the html, you should not improve your images/js, uze gzip, etc. You can do all of the things. – Salvador Dali Aug 18 '17 at 18:41
  • @SalvadorDali Isn't the idea of modern day agile workspace that the cycle between maintenance -> updates-> using is short? Minifying increases this, as you have to decipher customer bug reports without potential extra data given by the browser of the customers. – paul23 Nov 05 '17 at 18:13
  • As of Lighthouse, which supersedes PageSpeed, HTML minification is no longer listed as a factor that influences the final score in any way. –  Aug 17 '19 at 15:36
29

One likely reason is that markup typically changes MUCH more often, and would have to be minified for every page load. For instance on a given Stack Overflow page, there are timestamps, usernames, and rep counts that could change with every page load, meaning you would have to minify for each page load as well. With "static" files like css and javascript, you can minify far less often, so in the minds of some, it is worth the work up front.

Consider also that every major web server and browser support gzip, which compresses all of your markup (quickly) on the fly anyway. Because minifying is slower and much less effective than gzipping anyway, webmasters may decide that minifying for every page load isn't worth the processing cost.

Kenan Banks
  • 207,056
  • 34
  • 155
  • 173
  • 7
    CSS and JS are gzippable too, but minification still is seen as having significant benefits. – ceejayoz Aug 20 '09 at 15:08
  • 4
    Minimally significant. ~70% reduction by gzipping vs. ~5% reduction by minifying a gzipped file. – Kenan Banks Aug 20 '09 at 15:11
  • Agree the gains of even basic Compression far outweigh the gains of minifying. minifying seem to be more about obscuring 'your' really 'cool' code. – Mesh Aug 20 '09 at 15:13
  • 5
    @Adrian I wouldn't go _quite_ that far. There are occasionally good reasons to save every byte you can. The reason that *I* hate minifying though is that it often makes in-browser debugging a pain, and there are usually much better ways to speed up a site. – Kenan Banks Aug 20 '09 at 15:16
  • @Triptych That's why minifying is best handled via a framework. Drupal, for example, keeps the original files and lets you turn minifying off for development. – ceejayoz Aug 20 '09 at 15:21
  • 5
    For me these are separate domains. Minifying is about removing chaff, unnecessary material that doesn't affect the result. Compressing is about compressing the remainder. Gzip does great, but there's no point in gzipping when we could reduce it to zero. – T.J. Crowder Aug 20 '09 at 15:34
  • @TJ It's always a trade off. My point is that webmasters might decide they don't want the performance hit of minifying a markup file for every page load BECAUSE gzip does a good enough job. Obviously minifying+gzipping will net you the most savings overall. – Kenan Banks Aug 20 '09 at 15:36
  • If minification is a pain because it makes code hard to read or debug then why not have a beautifier ready? I have written one at http://mailmarkup.org/prettydiff/prettydiff.html –  Aug 20 '09 at 22:18
  • 1
    @Austin that won't help with messages like "error: line 1, character 13,045" – Kenan Banks Aug 20 '09 at 22:54
  • That makes me think you have not ever used a beautifier for your markup. Try the one I linked to and tell if you could ever get to the 13000th character on a single line. –  Aug 21 '09 at 02:05
  • minifying reduces the amount of work the browser has to do once it has downloaded the file - it has less data to parse. gzipping increases the browsers work - it has to uncompress the file before it starts parsing it. So minifying is a good idea, weather or not you gzip as well. – rjmunro Aug 21 '09 at 09:27
  • 3
    @rjmunro - that was quite a leap of logic. You certainly lose more time minifying on-the-fly server side than you gain in parsing time on the client. Gzipping decreases the amount of data the browser has to download, which will generally vastly outweigh the time require to uncompress. – Kenan Banks Aug 21 '09 at 11:16
  • @austin. The point is that when minifying, often all of your javascript code ends up on a single line. A tool like Firebug will therefore always report errors to be on "line 1" of the offending source file. Beautifying the code _afterwards_ will not help with tracking down where that error actually occurred in the original Javascript file. – Kenan Banks Aug 21 '09 at 11:19
  • 1
    Triptych, it actually does. Minified JavaScript behaves, provided its written properly with curly braces and semicolons, exactly the same regardless of minification. So in troubleshooting beautify it, correct the errors, and minify it again. If a person's JavaScript is not well written because semicolons and curly braces are not worth their time then they have other more serious problems to address. –  Aug 24 '09 at 00:47
  • 1
    @Austin. You are missing my point completely. I am not saying that minifying introduces errors. Please reread carefully – Kenan Banks Aug 24 '09 at 03:24
  • When a full page cache system is in place it is quite useful. – twicejr Aug 28 '14 at 23:39
  • 3
    @Austin Triptych is right. I hate fueling a discussion that doesn't belong in the comments but simply formatting a JS file doesn't help in debugging. His points are valid and properly minified means the variable names are changed to single letters. Try debugging when all your variable names are changed. The point is, your beautifier is cool if I want to format someone elses minified code but it helps nothing in debugging in the dev console when I can just look at my original code instead of an un-minified version. – Dustin Griffith Oct 08 '14 at 14:58
14

Consider this:

HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Demo</title>
<link rel="stylesheet" type="text/css" href="nonminify.css"/>
</head>
<body>
<div title="My   non   minifiable   page">
    <p class="http://www.example.com/classes/class/lorem-ipsum">

            Lorem ipsum dolor sit amet, consectetur adipisicing elit, 

            sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. 

            Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris 

            nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in 

            reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla 

            pariatur. Excepteur sint occaecat cupidatat non proident, sunt in 

            culpa qui officia deserunt mollit anim id est laborum.

    </p>
</div>
</body>
</html>

With this css file:

div[title="My   non   minifiable   page"] 
      p[class~="http://www.example.com/classes/class/lorem-ipsum"]
{
    white-space:pre;
}

Given that, it's effectively impossible for a HTML minifier that can only see the HTML file to find anything that it can safely minify.

Alohci
  • 78,296
  • 16
  • 112
  • 156
  • 4
    I suspect that the white-space:pre declaration is the exception and not the normal as it is so very rarely used. –  Aug 20 '09 at 22:19
  • 2
    True, but it's not just white-space:pre of course. DOM walking JavaScript can also make assumptions about the presence of white space that a minifier can change. Strange though it may seem, white space is significant in HTML, whereas in CSS and JavaScript it mostly isn't – Alohci Aug 21 '09 at 00:16
  • I disagree. Whitespace in markup is tokenized during parsing, so its only relevant down to single space characters. If minified only down to that level there is no difference to the interpretation of the code. Try minifying your HTML using my tool to see for yourself: http://mailmarkup.org/prettydiff/prettydiff.html –  Aug 21 '09 at 02:03
  • 1
    White-space is tokenized during parsing sure, but every white space character is passed through into the DOM. see http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#data-state and http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#parsing-main-inbody. Collapse of the white space happens in the render phase by typically applying the white-space:normal css rule. If that wasn't the case, how could browsers possibly implement white-space:pre? – Alohci Aug 21 '09 at 08:21
  • 2
    I don't deny that probably 99% of HTML pages as used on the web could have their white space reduced without being broken, but there will be 1% where that's not the case. I wish you luck with your HTML minifier, but if it is used a lot, expect to get a run of strange bug reports from web authors blaming the minifier for breaking their web pages. – Alohci Aug 21 '09 at 08:28
  • Small correction. Not EVERY white space character is passed through, but those going into text nodes in the body are. – Alohci Aug 21 '09 at 08:33
  • 1
    @Alohci, I just noticed your comments. I wrote a markup minifier that does not interfer with the parsed output of content. All whitespace, unless there is a contrary presentation condition intentionally applied, in markup is tokenized prior to be parsed out and whitespace between tags, except singletons, is entirely removed. Knowing the correct whitespace rules for markup allows a condition where the markup can be minified without harm in an automated fashion each time. –  Nov 02 '09 at 04:35
  • 1
    good point, i had not considered this. this should really be the accepted answer, as it explains why it is technically not possible for html like it is for js/css. – Kip Aug 26 '10 at 20:21
  • I guess the only thing that an HTML minifier could really safely do is to remove any spacing around attributes - e.g. "
    " should always be exactly the same as "
    ". That's unlikely to make much of a saving, though.
     – Bobby Jack Oct 19 '10 at 13:19
  • In the example above, there is no reason why the `pre` element couldn't be used for the text in which you want white space preserved. Pre is easier for both humans and machines to read, and it's not hard to design a minifier that ignores text inside a `pre` element. – Will Peavy Jun 10 '11 at 13:20
  • 1
    @Will - Sure, but that's not the test case. The case to be handled is where white-space:pre is used. The author of the minifier has no control over the markup and styling that the user of the minifier happens to be using. – Alohci Jun 10 '11 at 14:01
  • "but that's not the test case" - it's an academic test case, and an edge case. When would you ever use something like that in practice? The selector in the test case above should never be used. – Will Peavy Jun 10 '11 at 14:30
  • @WillPeavy I've used it in practice with sites implemented in CMS's. If I let the user enter text in a ` – Jacob Mar 27 '17 at 15:13
5

I suppose it's hard because sometimes things like white-space is used for formatting, maybe depending upon doctype.

Kieron
  • 26,748
  • 16
  • 78
  • 122
5

Page Speed recommends minifying markup:

http://code.google.com/speed/page-speed/docs/payload.html#MinifyHTML

Will Peavy
  • 2,349
  • 3
  • 21
  • 21
3

Markup tends to be dynamically generated these days, and even when static there's usually a bunch of pages. JavaScript and CSS are usually minified in a one-file-per-site manner and thus much easier to minify manually (or to script).

ceejayoz
  • 176,543
  • 40
  • 303
  • 368