为什么HTML / JavaScript压缩有益

14

当HTTP协议已经支持gzip数据压缩时，为什么HTML / JavaScript压缩有益呢？

我认识到Javascript / HTML缩小可以消除不必要的空格，并可能将变量重命名为几个字母，从而显着减小Javascript / HTML文件的大小，但是当重复次数很多时，LZW算法的效果不是特别好字符（例如很多空白？）

我意识到某些Javascript缩小工具所做的不仅仅是缩小尺寸。例如，谷歌的闭包编译器还试图通过内联函数和进行其他分析来提高代码性能。但是Javascript压缩的主要目的通常是减小文件大小。

我还意识到，除了性能之外，还有其他原因可能需要减少，例如代码混淆。但是同样，通常不强调该原因，而不是强调性能提高和文件大小减小。例如，Closure Compiler并不是宣传为混淆工具，而是宣传为代码大小缩小器和下载速度增强器。

那么，当您已经通过gzip压缩显着减小文件大小时，实际上从Javascript / HTML 压缩中获得了多少性能？

javascript html http minify

— 频道72
source

11

因为gzip压缩确实有其自身的开销（CPU）。缩小是可以在不影响CPU的情况下应用的第一个“低挂”压缩。

这些似乎微不足道，但是，涉及规模时，这些数字很快就有意义。

此外，通过压缩，您无需再进行gzip压缩。

— 黑夜
source

3

现代网络服务器会为每个请求实际gzip javascript文件吗？服务器似乎有可能缓存静态压缩的内容，因为它不太可能更改。

— aaberg 2012年

@aaberg即便如此，这还是服务器上缓存的数据更多。（不是说缓存不好）

— chills42

@ chilis42：如果这是问题所在，则服务器能够从文件系统本身提供预先压缩的文件。

— herby 2012年

+1表示比例。如果您每天有10位用户和100次点击，那么您就可以避免这种情况。如果您需要一个小时100k的服务器，那将是一笔可观的节省。

— SoylentGray 2012年

2

告诉我，运行全尺寸JavaScript编译器并在内部表示形式上运行一些优化，所有这些通常都是用Java实现的，因此CPU开销并不低。

— Oleg V. Volkov

5

压缩+ gzip通常会产生更好的结果，因为gzip是一种通用算法，没有专门适应一个或另一个输入，而压缩器却知道它的内容并且可以完成通用压缩算法无法实现的工作。它也可以有损（想想：完全消除注释和空格-这是对这些数据的100％压缩，如何克服？），而常规压缩则不能。

— 奥列格·沃尔科夫（Oleg V.Volkov）
source

2

您可能不会获得太多的性能优势，但仍会减少带宽使用。如果您可以通过缩小操作（和使用CSS精灵来减少请求数量）来减少js（和CSS）文件的kb，并且每天为1000个用户提供服务，那么一个月后，您将大大减少带宽。

— 史蒂夫·怀特豪斯
source

1

+1：精简意味着节省总计。这可能会帮助单个请求更快，但是它的目的是随着时间的流逝减少带宽使用。

— Joel Etherton 2012年

1

您在Web应用程序中所做的最昂贵的一件事情就是直接发送信息。如果您要付出CPU周期的费用，那么发送更少的东西几乎总是净赢。

另外，我没有任何科学依据可以支持，但是我希望如果没有其他原因（除了缩小工具是特定于域的并且可以调整为更好地压缩javascript的话），缩小工具可能会比gzip更好地压缩javascript。是通用工具，会折中。

— 怀亚特·巴尼特
source