当传输压缩时，为什么要缩小

Why minify when the transport will gzip?

本文关键字：为什么 缩小 传输 压缩      更新时间：2023-09-26

在过去(是的，我真的这么老了)，你可以从重命名的zip文件中引用脚本，像这样

<script archive="path/to.jar" src="some.js"></script>

在IE4, NS4和Opera5上支持，具有相同的标记和语义，但已经被扔到数字废品场。为什么?

好的，对于那些对答案感兴趣但又没有兴趣去浏览旧消息线程的人(见下面的评论)，它的长和短是，你仅仅通过指定Content-Encoding: gzip就可以从传输层获得压缩，所以在表示层中支持标记是不合适的，因此它被删除了。这也提高了粒度，因为脚本文件在缓存中是单独的版本。

如果传输层使用gzip，那么最小化的意义是什么?gzip字典标记传递将在网络上实现这一点，而不会产生可怕的调试体验。

我同意串联将提高压缩率。我想一些服务器/浏览器组合可能无法使用gzip，在这种情况下，缩小会有所帮助。

archive属性

对于任何对这个属性感兴趣的人，DevX在1999年3月23日的每日提示中提到了它。为了保存，此处复制了原文:

ARCHIVE是Internet Explorer 4和Netscape Navigator 4中<SCRIPT>标签的新属性，可以加快具有大型JavaScript文件的站点的下载时间。如果要加载多个JavaScript文件和数字签名，那么将它们压缩到单个JAR (Java Archive)文件中会更有效。JAR存档是添加了自描述信息的压缩文件。在JAR文件中，您仍然需要为HTML页面中的每个实例指定一个外部JavaScript文件。

<SCRIPT ARCHIVE="myArchive.jar" SRC="myScript.js"></SCRIPT>

现代浏览器的支持

这不在任何标准轨道中，现代浏览器似乎也不支持该属性。一个简单的特性测试表明:

"archive" in document.createElement( "script" );

结果非常一致:

  • 铬:假
  • IExplorer:假
  • Firefox:假
  • 歌剧:假
今天

相关性在现代浏览器中，我们真的不需要这样的功能。我们现在有了更好的编码选项，以及大量连接和最小化多个依赖的构建工具。我们也有像require.js和r.js这样的工具，它们可以打包多个文件来减少HTTP请求。

简而言之，web已经超越了传输压缩依赖项的需要。

同样的问题在2003年W3C的www-html邮件列表中被问到。下面列出了一些关于为什么不再需要像[archive]这样的属性的论据:

  • 浏览器现在能够长期缓存以减少未来的HTTP请求
  • 浏览器现在能够更好地压缩内容
  • 浏览器现在能够持久连接，减少HTTP请求

存档出版物

MSDN有一个名为"基于脚本的安全"的资源，至今仍在引用它。

MDN还有一个关于Mozilla中签名脚本主题的存档资源。

对作者的回复

如果传输层使用gzip，那么最小化的意义是什么?gzip字典标记传递将在网络上实现这一点，而不会产生可怕的调试体验。

可能是浏览器不支持gzip的情况(不太可能，但可能)。在这些情况下，连接/缩小的源要好得多。包括最小化步骤在内的现代构建过程还提供了更细粒度的控制，而gzip可能无法与之抗衡。例如，最小化可以删除冗长的源代码注释。

至于调试体验，您可以始终利用现代浏览器对源映射的支持，这将消除实际调试最小化代码的任何需要。

相关文章：