缩小 HTML、CSS 和 Javascript 是个坏主意吗？

Posted 2023-02-22

【中文标题】缩小 HTML、CSS 和 Javascript 是个坏主意吗？

【英文标题】：Is minifying your HTML, CSS, and Javascript a bad idea?

【发布时间】：2014-06-11 04:06:05

【问题描述】：

***defines minification作为...

[...] 从源代码中删除所有不必要字符而不更改其功能的过程。这些不必要的字符通常包括空白字符、换行符、cmets，有时还包括块分隔符，这些字符用于增加代码的可读性，但不是执行代码所必需的。

我目前正在对我的 html、CSS 和 javascript 执行此操作以节省带宽，但有人告诉我，他记得当某些标签（即 ul 和 li 项目之间没有空格时浏览器行为异常）。这是真的吗？

在处理压缩代码时，是否有任何值得注意的浏览器、代理或其他用户代理行为不端？

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

【问题讨论】：

“但有人告诉我，当某些标签之间没有空格时，他记得浏览器行为异常” 也许您可以向那个人询问更多信息。我相信这个人是错的。

没有标准规定必须分隔 HTML、CSS 或 JavaScript。如果浏览器确实不正确地呈现它，那么它很可能是一个错误。您可能面临的唯一问题是在处理 inline 或 inline-block 元素时，因为这些元素会考虑空格。

对于投票结束这个非常好的问题的匿名巨魔，因为“它过于基于意见”，你能否请解释这个问题的答案究竟取决于一个人意见？

有人会告诉你 不，标准允许这样做，如果允许，那就去做吧不能在浏览器中工作它的错误;其他人会告诉你是的，你应该解决所有浏览器中的所有错误；大多数人只会认为视情况而定或开始推荐最喜欢的缩小工具。

@guido 那一行论据没有任何意义。按照这种逻辑，您可以关闭关于 SO 的任何问题，因为 一些 用户可能会误入歧途，并在您真正应该提供事实的地方提供基于意见的答案。有两个简单的问题：浏览器是否行为不端以及缩小是否有不利之处？正如您从已经提供的答案中看到的那样，它根本不是取决于自己的意见，而是取决于事实。

【参考方案1】：

有人告诉我，他记得当有 某些标签（即 ul 和 li 项目）之间没有空格。这是 真的吗？

是的，在某些情况下，例如元素设置为显示 inline-block 或 inline。

由于<li> 元素之间的空格，以下两个列表的呈现方式会有所不同：

html

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

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

css

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

渲染输出

http://jsfiddle.net/Uwv3e/

【讨论】：

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

@Nit 是的，绝对是。就我个人而言，我不相信 HTML minifier 知道什么时候保留空格，什么时候不保留，而所有这些都只是为了减少几个字节。我确实缩小了我的 JS 和 CSS。

还请记住，缩小将删除代码中所有“不必要的” cmets...等等...所以我使用虚拟元素的淘汰赛绑定将消失，可能还有一些有条件的 IE9- cmets ...嗯...说真的，知道我所有的 HTML 都没有被缩小在某种程度上不会让我每晚都睡个好觉...

【参考方案2】：

为了……通常在站点大小上节省大约 4-8kb 的目的，缩小会消除可维护性。您可以通过压缩站点上的单个 jpg 并删除图像的元数据来节省更多费用。

除非您要构建一个拥有大量页面、子页面和模板以及超过 5,000 行 CSS 和 JS 的网站，否则您会发现缩小是浪费精力，尤其是在涉及维护和您必须保持未缩小版本的文件浮动只是为了进行修复，缩小，用新版本覆盖缩小的文件，祈祷下一个维护站点的人使用您的相同工作流程并且不对缩小的 CSS 文件进行更改，然后当你回来抹掉他的变化时......

我提出这个是因为我已经看到了这种情况。我已经在网站缩小前后进行了 GTmetrics 和 Pingdom 分数，分数和加载速度几乎没有变化，足以让它值得。

我一直把缩小称为“花钱省钱”。您的努力可以更好地用于开发项目的其他地方。

【讨论】：

您描述了一个糟糕的缩小过程。通常，一个好的设置会使用 gulp 或 grunt 之类的东西将文件从一个目录（或前缀文件名）缩小到另一个目录。您通常会将未缩小的文件保留在 Web 根目录之外，并在缩小后将它们移到那里。

引入另一个依赖项，如 Gulp 或 Grunt，纯粹是为了缩小文件，不会让事情变得更简单。最简单的方法是提交文件并完成它。额外的好处是您可以在实时站点上查看源代码并在那里诊断问题，如果您不知道开发站点和实时站点之间存在隐藏的差异，这很好。另外，如果最初实现工作流的开发人员被替换，新的开发人员不必处理 Gulp 或 Grunt 来运行他们的新工作流。

+1 @kloddant。我继承了一个具有 gulp/grunt 依赖项的项目，这很痛苦，因为这些工具很慢（在 Visual Studio 中构建时）。 Ben 在他的回答中所说的工作流程很重要：在一个项目中，我有一个插件来进行缩小。当我升级 IDE 时，我没有安装那个插件，所以我所做的 CSS 更改没有被缩小……最终结果，开发/产品站点之间的差异让我抓狂。这当然是“花钱来节省便士”，而且 IMO 不值得。

【参考方案3】：

缩小您的 HTML、CSS 和 Javascript 是个坏主意吗？当然可以！

不过，一个好主意是缩小 CSS 和 Javascript

为什么？

通过 (a) 将人类可读的变量名称替换为紧凑名称（如“mySuperTollesFunctionCall()”到“m()”以及通过 (b) 进行缩小工作删除空格 您的 JavaScript 可以从 (a) 和 (b) 中受益 您的 CSS 只能从 (b) 中受益 理论上，您的 HTML 代码只能从 (b) 中受益，但这不值得一试。

任何简单的优秀 HTML 编辑器都可以为您格式化 HTML 文件。处理“pre”块内的空格，提示您遵守 W3C 等。

如果您担心 HTML 文件的大小...您应该在 Web 服务器中启用静态文件的 GZIP 压缩，大多数活化石都会处理它，并且您的客户会喜欢它。

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

【讨论】：

+1 对于所有绝对真实的细节。但是如果asker寻求最大的性能，他绝对可以缩小html然后gzip它（然后缓存结果是适用的）

谷歌会反驳你的观点。缩小 HTML 并不意味着它变得不起作用。它删除了空白，现在它是页面速度的指标。

【参考方案4】：

某些浏览器 IE 版本在缩小font-face 声明方面存在问题，请参阅：

CSS fonts not loading in IE9 How to minify CSS with font-face

【参考方案5】：

有人告诉我，他记得当有 某些标签（即 ul 和 li 项目）之间没有空格。这是 真的吗？

不，该陈述是错误的。这就是浏览器应该按照HTML specification regarding whitespace 工作的方式。任何一系列的空格（制表符、换行符、空格）都表示相同的意思。

采用以下标记：

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

在考虑到SGML line break rules 声明可以忽略开始标记之后和结束标记之前的空格之后，正确的缩小，那么正确的缩小将是：

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

如果缩小工具给出以下信息，则说缩小器已损坏是恰当的。

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

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

【参考方案6】：

如前所述，缩小 HTML 实际上在某些情况下会改变列表，我已经看到了。

对于 JS/CSS，我只缩小非常大的文件，例如 jQuery 或 FontAwesome 附带的 CSS。

如果服务器设置正确，静态资源将提供一个适当的标头，告诉客户端他们可以缓存一段时间，当该期限到期时，大多数客户端会简单地询问服务器文件是否已更改以及何时更改它没有改变，客户甚至没有要求的新时间段开始了。

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

特别是对于 brotli 压缩，我不相信通过缩小所节省的空间有什么大不了的，除了像 jQuery 这样的大型库可能是个例外。在我看来，保持所服务源的可读性比在浏览器尚未缓存文件时节省几千字节更有价值。

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