Menu
Minification is the process of minimizing code and markup in your web pages and script files. It's one of the main methods used to reduce load times and bandwidth usage on websites. Minification dramatically improves site speed and accessibility, directly translating into a better user experience.
Minification means to minimize code (HTML, CSS, JS) and markup in your web pages and script files. This reduces load times and bandwidth usage on websites. Moreover, it improves site speed and accessibility. Additionally, a user can access your website even with a limited data plan.
Therefore, you can also minify those HTML files and keep reusing them as you could do with any static files. To extend, some webpages might even share both of these qualities.
Minifying strips out all comments, superfluous white space and shortens variable names. It thus reduces download time for your JavaScript files as they are (usually) a lot smaller in filesize. So, yes it does improve performance. The obfuscation shouldn't adversely affect performance.
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:
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:
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.
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.
I suppose it's hard because sometimes things like white-space is used for formatting, maybe depending upon doctype.
Page Speed recommends minifying markup:
http://code.google.com/speed/page-speed/docs/payload.html#MinifyHTML
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With