缩小HTML、CSS和Javascript文件是个好主意吗？

Question

维基百科定义缩小为...

[...]从源代码中删除所有不必要的字符而不改变其功能的过程。这些不必要的字符通常包括空格字符，新行字符，注释以及有时用于添加代码可读性但不需要执行的块定界符。

我目前正在对我的HTML，CSS和Javascript进行此操作，以节省带宽，但有人告诉我，在某些标记之间没有空格（即ul和li项）时，他记得浏览器会出现问题。这是真的吗？

是否有任何著名的浏览器、代理或其他用户代理在处理缩小的代码时出现异常表现?

除了查看源时失去可读性外，缩小还有其他缺点吗？

- JohnCand

---

也许你可以向那个人询问更多信息。不过我认为那个人是错的。但有人告诉我，他记得当某些标签之间没有空格时，浏览器会出现问题。 - Felix Kling

没有标准规定HTML、CSS或JavaScript必须有空格。如果浏览器无法正确呈现，则很可能是一个错误。唯一的问题可能出现在处理“inline”或“inline-block”元素时，因为这些元素会考虑空格。 - James Donnelly

对于那些匿名的喷子们，因为“这个问题太基于观点”而投票关闭这个完全正常的问题，你们能否请解释一下，这个问题的答案到底取决于哪个人的观点？ - JohnCand

将HTML、CSS和JavaScript进行缩小处理是一个不好的想法吗？有人会告诉你“不，标准允许这样做，所以如果它不起作用，那就是浏览器的错误。”；另一些人会告诉你“是的，你应该解决所有浏览器中的所有错误”；大多数人只会认为“这取决于情况”或开始建议他们最喜欢的缩小工具。 - guido

@guido这种论点没有任何意义。按照那种逻辑，你可以关闭SO上的任何问题，因为一些用户可能会偏离主题提供基于观点的答案，而你实际上应该提供事实。有两个简单的问题：浏览器是否表现不佳，缩小文件大小是否有缺点？正如你从已经提供的答案中看到的，它*完全不依赖于一个人的观点，而是事实。 - JohnCand

Answer 1

有人告诉我，当某些标签之间没有空格时（特别是ul和li元素），浏览器会出现错误。这是真的吗？

是的，在某些情况下会出现错误，比如元素设置为inline-block或inline时。

以下两个列表将呈现不同的效果，因为<li>元素之间有空格：

HTML代码：

<ul>
    <li>simple</li>
    <li>list</li>
</ul>

<ul><li>minified</li><li>list</li></ul>

层叠样式表

li {
    display: inline-block;
    background: blue;
    color: white;
}

呈现的输出

http://jsfiddle.net/Uwv3e/

- xec

---

从技术上讲，这将是缩小脚本的错误，因为按照定义缩小是“从源代码中删除所有不必要的字符而不改变其功能的过程”。因此，一个好的缩小器应该将其缩小为“<ul><li>minified</li> <li>list</li></ul>”或类似的结果。 - Etheryte

@Nit 是的，绝对没错。就我个人而言，我不会相信一个 HTML 压缩工具知道什么时候保留空格，什么时候不保留，只是为了减少一些字节。但我确实会压缩我的 JS 和 CSS。 - xec

请记住，缩小代码将删除所有“不必要”的注释...等等...那么我的使用虚拟元素的 knockout 绑定将消失，可能还有一些条件 IE9- 注释...嗯...说真的，知道我的所有 HTML 都没有被缩小，这不会让我晚上睡不好觉... - Adrian Salazar

Answer 2

缩小文件大小的过程通常会牺牲代码可维护性，仅仅可以减小网站约4-8kb。如果你想获取更多的空间，可以尝试压缩单个jpg图片并且删除其元数据。

除非你正在构建一个拥有大量页面、子页面和模板以及超过5,000行CSS和JS代码的网站，否则你可能会发现缩小文件大小是一种徒劳的努力，尤其是在维护方面，因为你需要保留未经过缩小处理的文件版本进行修复，并且要使用minify重新压缩文件并覆盖已经压缩好的版本，还需要祈求下一个维护网站的人使用相同的工作流程并不对minified CSS文件进行更改，否则你又得重新来过...

我提到这点是因为我曾经遇到过这种情况。我曾经对网站进行了GTmetrics和Pingdom分数的评估，在压缩前后，得分和加载速度变化微乎其微，很难看出效果。

我总是将缩小文件大小称为"花费整元钱去省下角分"。你可以将精力放在开发项目的其他方面。

- Ben

---

你描述了一种糟糕的压缩过程。通常一个好的设置会使用像gulp或grunt这样的工具将文件从一个目录（或带前缀的文件名）压缩到另一个目录。你通常会将未经压缩的文件保存在网站根目录之外，并在压缩后将它们移动到那里。 - Daniel Dewhurst

为了仅仅压缩文件而引入像 Gulp 或 Grunt 这样的依赖并不能使事情更简单。最简单的方法就是提交文件然后完成它。附加的好处是你可以在实时网站上查看源代码并诊断问题，如果开发和实时网站之间存在您不知道的隐藏差异，这将非常有用。此外，如果最初实施工作流程的开发人员被替换，新人不必使用 Gulp 或 Grunt 来运行他们的新工作流程。 - kloddant

+1 @kloddant。我接手了一个依赖gulp/grunt的项目，但它太慢了（在Visual Studio内建立时）。而Ben在他的答案中提到的工作流程非常重要：在一个项目中，我使用了插件进行缩小操作。当我升级IDE时，我没有安装该插件，因此我所做的CSS更改并没有被缩小...最终结果是，开发和生产网站之间存在差异，这让我感到沮丧。这肯定是“花费美元来节省便士”，在我看来根本不值得。 - Eric Mutta

Answer 3

缩小 HTML，CSS 和 Javascript 的文件是一个不好的主意，当然是的！

一个好的想法是缩小你的CSS 和 Javascript文件。

为什么？

• 缩小工作原理是通过将人类可读的变量名替换为紧凑的名称，例如“mySuperTollesFunctionCall()”替换为“m()”，并通过去除空格来实现。
• 你可以从（a）和（b）两者中受益。
• 你的CSS只能从（b）中受益。
• 在理论上，你的HTML代码只能从（b）中受益，但尝试这样做并不值得。

任何简单的好的HTML编辑器都可以为你美化格式化HTML文件。注意“pre”块内的空格，给你W3C合规性的提示等等。

如果您担心HTML文件的大小... 您应该启用Web服务器中静态文件的GZIP压缩，大多数Web服务器都支持它，您的客户将不胜感激。

http://www.schroepl.net/projekte/mod_gzip/browser.htm

- Adrian Salazar

---

对于所有细节的真实性给予肯定。但是，如果提问者寻求最大的性能，他绝对可以缩小HTML然后进行gzip压缩（如果适用，则缓存结果）。 - ngasull

Google 会反驳你的观点。压缩 HTML 并不意味着它变得无法使用。它只是删除了空格，成为页面速度的一个度量标准。 - Kyias

Answer 4

一些浏览器（包括IE版本）在使用压缩的font-face声明时会出现问题，详情请参见：

• CSS字体在IE9中无法加载
• 如何压缩带有font-face的CSS

- leo

Answer 5

有人告诉我，当某些标签（即ul和li项）之间没有空格时，浏览器会出现错误行为。这是真的吗？

不，这种说法是错误的。根据HTML规范关于空白的说明，浏览器应该按照这种方式工作。任何一系列的空格（制表符、换行符、空格）都意味着相同的含义。

看下面的标记：

<ul>
    <li>A</li>
    <li>B</li>
</ul>

考虑到SGML换行规则，指出在开标签后和闭标签前的空格可以忽略，因此正确的缩小应为：

<ul><li>A</li> <li>B</li></ul>

如果一个压缩工具给出了以下内容，可以说该压缩工具已经失效。

<ul><li>A</li><li>B</li></ul>

这个规则的例外是PRE标签，它指定了预格式化内容，浏览器应该呈现所有的空格字符。我想你也需要保留CDATA，因为它在技术上不属于HTML内容。

- Brett

Answer 6

如前所述，缩小HTML确实在某些情况下会改变列表，我见过。

对于JS/CSS，我只缩小像jQuery或附带FontAwesome的CSS这样的大文件。

如果服务器设置正确，静态资源将使用适当的标头提供服务，告诉客户端可以缓存一段时间，当该期限到期时，大多数客户端将简单地询问服务器文件是否已更改，当文件未更改时，客户端甚至不会请求新的时间段。

确保发送适当的过期标头将节省比缩小更多的带宽。

特别是在brotli压缩方面，我并不认为缩小所节省的空间有多大作用，除了像jQuery这样的大型库可能有例外。在我看来，维护源代码的可读性比在浏览器没有缓存文件时节省几千字节更有价值。

Brotli压缩现在在除IE11、Opera Mini和百度浏览器之外的所有地方都得到支持。使用它，我真的怀疑缩小是一个无关紧要的问题。

- VeryGoodErotica