1) pre tags - being that pre tags take into account formatting, removing whitespace is going to alter how the content is rendered
2) any empty tags - its becoming a thing of the past but there are many instances where browsers will render a tag with a single space inside differently than a tag with nothing inside. In other words, space within a tag may be intentional by the developer.
3) spaces inside attributes may matter - you could have an attribute on an html tag that say is data-whatever="1 2\n 3" and potentially reducing those spaces could be bad - depends upon what the developer intended
Additionally there are some other things to consider...
1) GZIP if used will make the impact of scrubbing out whitespace almost nonexistent
2) Most HTML served is dynamic, meaning that the HTML compression will need to be run on every HTML response - this could have some performance negatives. (If your just compressing static HTML once it should be fine.)
Gzip is basically exactly what the GP wants, and beyond that, whitespace in HTML is still, sadly, significant in places.
>1) GZIP if used will make the impact of scrubbing out whitespace almost nonexistent
Maybe if you were just removing whitespace (although you still will see a difference). Removing comments and omitting optional closing tags will take you further. Minified JS compresses smaller than un-minified JS, so it's reasonable to think the same would be true of HTML.
>Most HTML served is dynamic, meaning that the HTML compression will need to be run on every HTML response - this could have some performance negatives. (If your just compressing static HTML once it should be fine.)
For templated HTML, the minification should be done on the template itself, not on the final output. You really do have to weigh the pros and cons of GZIPping dynamically generated HTML, so pre-minified HTML templates could be a pretty big win.
Almost any modern combination should work fine.
OK - there is a cpu overhead for the server but if bandwidth is the issue then it sure beats any attempt at minifying the HTML
Most of the time GZIP + minify is not significantly smaller then GZIP, and thus minifying HTML or JS is not worth it + may prevents good debugging.
AFTER EDIT: TazeTSchnitzel asks a fair question. I put each new major element on a new line. In general, I try to make paragraphs look like paragraphs, headings look like headings, and so on, with just newline whitespace but without leading whitespace before elements (which has annoyed me for the last few weeks in a website updating project I was working on). Thanks for asking the clarifying question.
FURTHER EDIT: Yes, thanks for the statement that indentation shows nested structure (which is what I guessed is the usual rationale for extra whitespace in HTML code). Despite that obviously sensible practice (which, after all, leads to the MEANINGFUL white space in Python code), I have seen plenty of examples of HTML pages that have unmatched tags even though they have so much whitespace that the "view source" view of the page is mostly off to the right of my screen. Agreeing that being able to view source code structure is important, may I suggest that as one reason to like Notepad++ as one of the many editor choices available to persons who write code? In the recent project I worked on updating, the original programmers had left many unmatched tags and inconsistent structures in the code, and I was able to strip out all the extraneous code AND fix the structure by using Notepad++ to find (for example) the beginning and ending div elements surrounding big, complicated blocks of code. Notepad++ shows code structure with structure lines overlaid on the raw source code view.
<!doctype html><html><head><meta charset=utf-8><title>super-readable HTML</title></head><body><div id=container><h1>Title</h1><p>Lorem ipsum dolar sit amet.</p><hr><ul><li>List item</li><li>List item</li></ul><div id=main><div id=sidebar><ul><li>Sidebar item</li><li>Item 2</li></div><div id=main><div id=top><img src=file.png alt=""> This is some text</div><div id=form><form action=/><input type=text name=something><input type=submit></form></div><div id=content><div class=widget><div class=widgettop>thing</div><button class=widgetbtn>button</button></div></div></div></div></body></html>I do as does anyone else who uses Zen Coding (or emmet).
>Why use an editor that adds whitespace in the first place?
Because it makes the code way, way more readable. Indentation allows you to easily see the structure of the HTML, so that you can see what is a descendant of what.
Look at this and tell me whether "Man Made" is part of "Debris" or if it's a separate sublist:
<ul>
<li>Debris:
<ul>
<li>Sand</li>
<li>Dirt</li>
<li>Man Made:
<ol>
<li>Broken glass</li>
<li>Pennies</li>
</ol>
</li>
</ul>
</li>
<li>Animals:
<ul>
<li>Cats</li>
<li>Dogs</li>
<li>Chimps</li>
</ul>
</li>
</ul>
<ul>
<li>Debris:
<ul>
<li>Sand</li>
<li>Dirt</li>
<li>Man Made:
<ol>
<li>Broken glass</li>
<li>Pennies</li>
</ol>
</li>
</ul>
</li>
<li>Animals:
<ul>
<li>Cats</li>
<li>Dogs</li>
<li>Chimps</li>
</ul>
</li>
</ul>The basic text file (at least in unix) is king, and the medium by which we transport all sorts of code around. Adding a layer of asbtraction to an editor like that, where it shows you one thing but saves the file differently, breaks this premise and means your new editor now doesn't play well with others.
- Unless you source control is in on it, you are going to suddenly see a different file than you were working with before when resolving conflicts.
- Your whole team is now forced to use your editor to get the same view of the code as you are.
- grepping, line counts, most third party text mapulation/wrangling services become moot unless savvy to the context of your editor
Another reason is because, websites are becoming more dynamic & it’s not very cacheable – CSS/JS are extremely cacheable. Since on every request you have the extra task of running minimization on the complete HTML of a webpage (especially if your website is dynamic and you’re using a script to do this) and this is time you could have used to transfer data.
Moreover, there are other low hanging fruit that most websites need to tackle first – minimizing HTTP request, removing unnecessary images, minifying images, minifying & combining CSS/JS.
Of course that would be slow, but if you have compiled templates on a dynamic site, could you not strip out whitespace at compile-time?
Personally, I think the benefits of minifying your HTML won't pay off until you're receiving a significant amount of traffic anyway. Which is why, for the large majority of sites they'll see better value through minifying/combining their CSS/JS and tackling the other low hanging fruit first.
Every now and then whitespace turns out to be significant though ... so you need to be slightly intelligent about how you handle it.
It is probably less relevant in HTML5 times where you are most likely just using a small bit of HTML to act as a "loader" for your Javascript, which then takes over. The JS and CSS files are, in this case, way bigger than the HTML.
I eliminate whitespace with the following PHP code:
preg_replace(['/\t+/', '/>\s+</'], [' ', '><'], $html);But I once worked on a Facebook-like SaaS, and minifying HTML had huge performance hit on the back-end, since we used templates, not a proprocessor language such as Jade or HAML.
EDIT: Wait, isn't that something the template compiler could do?
I'm betting big on using preprocessor languages, such as HAML, or Jade.