为什么人们缩小资产而不是 HTML？
为什么人们建议缩小 Web 资源，例如 CSS 和 JavaScript，但他们从不建议缩小标记？ CSS 和 JavaScript 可以在许多不同的页面上使用，而每次都会加载标记，这使得标记的缩小变得更加重要。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这里写的答案非常过时，甚至有时没有意义。 与 2009 年相比，很多事情都发生了变化，所以我会尽力正确回答这个问题。
简短的回答 - 你绝对应该缩小 HTML。 今天这很简单，并且可以提供大约 5% 的加速。 对于更长的答案，请阅读整个答案
回到过去，人们手动缩小 css/js （通过通过某些特定工具运行它来缩小它）。 使该过程自动化有点困难，并且肯定需要一些技能。 知道现在很多高级网站都没有使用 gzip（这很简单），人们不愿意缩小 html 是可以理解的。
那么为什么人们缩小 js，而不是 html？ 做以下事情：
var isUserLoggedIn到var a）当你缩小 JS 时，你会 即使在过去也有很大的进步。 但是在html中你无法将长名称更改为短名称，而且在那段时间几乎没有什么可评论的。 所以剩下的唯一的事情就是删除空格和换行符。 这仅提供了少量的改进。
这里写的一个错误的论点是，因为内容是通过 gzip 提供的，所以缩小没有意义。这是完全错误的。 是的，gzip 减少缩小的改进是有道理的，但是为什么要 gzip 注释、空格（如果你可以正确修剪它们）并且 gzip 只是重要的部分。 这就像您有一个要存档的文件夹，其中有一些您永远不会使用的垃圾，并且您决定将其压缩而不是清理并压缩它。
为什么缩小没有意义的另一个论点是它很乏味。可能这在 2009 年是正确的，但在这之后出现了新的工具。 现在您不需要手动缩小标记。 对于像 Grunt 这样的东西，安装 很简单grunt-contrib-htmlmin 并配置它以缩小您的 html。 您只需要花 2 个小时来学习 grunt 并配置所有内容，然后一切都会在不到一秒的时间内自动完成。 听起来 1 秒（您甚至可以使用 grunt-contrib-watch 自动执行任何操作）并非如此大约有 5% 的改进（即使使用 gzip）。
还有一个论点是 CSS 和 JS 是静态的，而 HTML 是由服务器生成的，因此您无法对其进行预缩小。 2009 年也是如此，但目前更多和更多 站点看起来像一个单页应用程序，其中服务器很薄，客户端正在执行所有路由、模板和其他逻辑。 所以服务器只给你 JSON 并且客户端渲染它。 这里有很多页面的 html 和不同的模板。
结束我的想法：
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 isUserLoggedIntovar 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:
一个可能的原因是标记通常会更频繁地更改，并且必须针对每次页面加载进行缩小。 例如，在给定的 Stack Overflow 页面上，时间戳、用户名和代表计数可能会随着每次页面加载而变化，这意味着您也必须针对每个页面加载进行缩小。 使用 css 和 javascript 等“静态”文件，您可以大大减少压缩的频率，因此在某些人看来，提前进行工作是值得的。
还要考虑到每个主要的 Web 服务器和浏览器都支持 gzip，它会动态压缩所有标记（快速）。 因为无论如何，缩小速度比 gzip 更慢且效率低得多，因此网站管理员可能会认为对每个页面加载进行缩小不值得花费处理成本。
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.
考虑一下：
HTML：
使用此 css 文件：
鉴于此，对于只能查看 HTML 文件的 HTML 缩小器来说，实际上不可能找到可以安全缩小的任何内容。
Consider this:
HTML:
With this css file:
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 建议缩小标记：
http://code.google.com /speed/page-speed/docs/payload.html#MinifyHTML
Page Speed recommends minifying markup:
http://code.google.com/speed/page-speed/docs/payload.html#MinifyHTML
如今，标记往往是动态生成的，即使是静态的，通常也会有一堆页面。 JavaScript 和 CSS 通常以每个站点一个文件的方式进行缩小，因此更容易手动缩小（或编写脚本）。
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).