html - 为什么人们缩小 Assets 而不是 HTML？

Question

为什么人们建议缩小 CSS 和 JavaScript 等网络资源，但从来不建议缩小标记？ CSS 和 JavaScript 可以在许多不同的页面上使用，而每次都会加载标记，这使得标记的缩小变得更加重要。

Answer 1

这里写的答案非常过时，有时甚至没有意义。与 2009 年相比，很多事情都发生了变化，所以我会尽量正确地回答这个问题。

简短回答 - 您绝对应该缩小 HTML。今天很简单，给出大约 5% speedup .如需更长的答案，请阅读整个答案

过去人们手动缩小 css/js(通​​过一些特定工具运行它来缩小它)。自动化这个过程有点困难，而且肯定需要一些技能。知道很多高级网站甚至现在都没有使用 gzip(这是微不足道的)，人们不愿意缩小 html 是可以理解的。

那么为什么人们缩小 js 而不是 html？当你缩小 JS 时，你会做以下事情:

• 删除评论
• 删除空格(制表符、空格、换行符)
• 将长名称更改为短名称(var isUserLoggedIn 为 var a)

即使在过去，它也带来了很大的改进。但是在 html 中，您不能将长名称更改为短名称，而且在那段时间里几乎没有什么可评论的。所以唯一剩下的就是删除空格和换行符。这只会带来少量改进。

这里写的一个错误论点是因为内容是用 gzip 提供的，所以缩小没有意义。这是完全错误的。是的，gzip 减少缩小的改进是有道理的，但是如果你可以适本地修剪它们和 gzip 只是重要的部分，为什么你应该 gzip 评论，空格。这就像您有一个要归档的文件夹，其中有一些您永远不会使用的废话，您决定只压缩它而不是清理和压缩它。

另一个为什么进行缩小没有意义的论点是它很乏味。可能这在 2009 年是正确的，但在这之后出现了新的工具。现在您不需要手动缩小标记。像 Grunt 这样的东西安装 grunt-contrib-htmlmin 很简单并将其配置为缩小您的 html。您只需要 2 小时来学习 grunt 并配置所有内容，然后一切都会在不到一秒钟的时间内自动完成。听起来 1 秒(您甚至可以使用 grunt-contrib-watch 自动执行任何操作)对于大约 5% 的改进(即使使用 gzip)来说并不是那么糟糕。

还有一个说法是CSS和JS是静态的，而HTML是由服务器生成的，所以你不能预先压缩它。这在 2009 年也是如此，但目前 more和 more网站看起来像一个单页应用程序，服务器很瘦，客户端负责所有路由、模板和其他逻辑。所以服务器只给你 JSON客户端呈现它。这里有很多页面和不同模板的 html。

所以结束我的想法:

• Google 正在缩小 html。
• pageSpeed要求您缩小 html
• 做起来很简单
• 它提供了大约 5% 的改进
• 它与 gzip 不同