Gzip 与 minify
前几天，我就缩小 Javascript 和 CSS 与喜欢使用 Gzip 的人进行了一场热烈的讨论。
我会称这个人为 X。X
说 Gzip 已经压缩了代码，因为它会压缩你的文件。
我不同意。 Zip 是一种无损缩小文件大小的方法。 无损意味着必须完美地恢复原始内容，这意味着必须存储信息才能恢复空格、不需要的字符、注释代码和其他所有内容。 这会占用更多空间，因为必须压缩更多空间。
我没有测试方法，但我相信这段代码的Gzip：
.a1 {
background-color:#FFFFFF;
padding: 40px 40px 40px 40px;
}
仍然会比这段代码的Gzip更大：
.a1{body:background-color:#FFF;padding:40px}
有没有人可以证明这是对还是错。
请不要来说“这是正确的，因为那是我一直使用的”。
我在这里寻求科学证据。
I had a somewhat lively discussion the other day about minifying Javascript and CSS versus someone who prefers using Gzip.
I'll call this person X.
X said that Gzip allready minifies the code, since it zips your files.
I disagree. Zip is a lossless method of shrinking filesize. Lossless means the original must be restored perfectly, meaning info must be stored to be able to restore the spaces, the un-needed characters, commented code and everything else. That takes up more space, since more must be compressed.
I have no method of testing, but I believe that the Gzip of this code:
.a1 {
background-color:#FFFFFF;
padding: 40px 40px 40px 40px;
}
Will still be bigger than the Gzip of this code:
.a1{body:background-color:#FFF;padding:40px}
Is there anybody who can prove this right or wrong.
And please don't come saying "It's right because that's what I've always used".
I am asking for scientific proof here.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
测试起来非常简单。 我拿走了你的 js，将它们放在不同的文件中，并对它们运行 gzip -9 。 这是结果。 这是在运行 Cygwin 和 gzip 1.3.12 的 WinXP 计算机上完成的。
下面是使用真实 JS 示例的进一步测试。 源文件为“common.js”，原始文件大小为73134字节。 缩小后，大小为 26232 字节。
原始文件：
缩小文件：
使用 -9 选项 gzip 压缩的原始文件（与上述版本相同）：
使用 -9 gzip 压缩的缩小文件选项（与上面相同的版本）：
正如您所看到的，各种方法之间存在明显的差异。 最好的选择是同时压缩和压缩它们。
Very simple to test. I took your js, put them in different files and ran gzip -9 on them. Here's the result. This was done on a WinXP machine running Cygwin and gzip 1.3.12.
Here's a further test using a real-world JS example. The source file is "common.js" The original file size is 73134 bytes. Minified, it came to 26232 bytes.
Original file:
Minified file:
Original file gzipped with -9 option (same version as above):
Minified file gzipped with -9 option (same version as above):
As you can see, there is a definite difference between the various methods. The best bet is to both minify as well as gzip them.
以下是我不久前使用我网站上的“现实生活”CSS 文件进行的测试的结果。 CSS 优化器 用于缩小。 Ubuntu 附带的标准 Linux 存档应用程序用于 Gzipping。
原始：28,781 字节
缩小：22,242 字节
Gzip 压缩：6,969 字节
Min+Gzip：5,990 字节
我个人的意见是首先使用 Gzipping，因为这显然会产生最大的差异。 至于缩小，这取决于你的工作方式。 您必须保留原始 CSS 文件才能进一步进行编辑。 如果您不介意在每次更改后缩小它，那么就去做吧。
（注意：还有其他解决方案，例如在提供文件时通过“按需”压缩器运行它，并将其缓存在文件系统中。）
Here are the results of a test I did a while back, using a "real life" CSS file from my website. CSS Optimiser is used for minification. The standard Linux archive app that comes with Ubuntu was used for Gzipping.
Original: 28,781 bytes
Minified: 22,242 bytes
Gzipped: 6,969 bytes
Min+Gzip: 5,990 bytes
My personal opinion is to go for Gzipping first, since that obviously makes the biggest difference. As for minification, it depends on how you work. You'd have to keep the original CSS file in order to make edits further down the line. If it doesn't bother you to minify it after every change then go for it.
(Note: there are other solutions, such as running it through a minifier "on-demand" when serving the file, and caching it in the filesystem.)
测试时要注意：这两个 CSS 片段非常小，因此它们无法从 GZIP 压缩中受益 - 仅添加 GZIP 的小页眉和页脚（大约 20 字节开销）就会失去所获得的收益。 实际上，您不会有这么小的 CSS 文件并担心压缩它。
minify+gzip 压缩的不仅仅是 gzip
最初问题的答案是，是的，minify + gzip 将比仅 gzip 获得更多的压缩。 对于任何重要的示例（即任何超过几百字节的有用 JS 或 CSS 代码）都是如此。
对于这种效果的示例，获取 Jquery 源代码，它是可用的缩小且未压缩的，将它们都压缩为gzip 并看一下。
值得注意的是，与优化良好的 CSS 相比，Javascript 从缩小中受益更多，但仍然有一个好处。
推理：
GZIP 压缩是无损的。 这意味着它必须存储所有文本，包括精确的空格、注释、长变量名等，以便以后可以完美地再现它们。 另一方面，缩小是有损的。 如果缩小代码，则会从代码中删除大部分此类信息，从而减少 GZIP 需要保留的信息。
Watch out when testing this: those two snippets of CSS are trivially small, so they don't benefit from GZIP compression - the addition of GZIP's small header and footer (about 20 bytes overhead) alone will lose the gains made. In reality you would not have a CSS file this small and be concerned about compressing it.
minify+gzip compresses more than just gzip
The answer to the original question is, yes, minify + gzip will gain a significant amount more compression than just gzip. This is true for any non-trivial example (ie any useful JS or CSS code that is more than a few hundred bytes).
For examples of this in effect, grab Jquery source code which is available minified and uncompressed, compress them both with gzip and take a look.
It's worth noting that Javascript benefits a lot more from minification than well-optimised CSS, but there is still a benefit.
Reasoning:
GZIP compression is lossless. This means that it has to store all text, including the exact whitespace, comments, long variable names and so on, so they can be perfectly reproduced later. On the other hand, minification is lossy. If you minify your code, you are removing much of this information from your code, leaving less that GZIP needs to preserve.
你说得对。
缩小与 gzipping 不同（如果是这样的话，它们将被称为相同）。 例如，它与 gzip 不一样：
比 minify 最终得到类似的结果：
当然，我想说在大多数情况下最好的方法是先缩小然后再 Gzip，而不仅仅是缩小或 gzipping，尽管这取决于有时，仅压缩或压缩代码会比同时执行这两种操作带来更好的结果。
You're right.
It's not the same to minify than gzipping (they would be called the same if that was the case). For example, it's not the same to gzip this:
Than minify to end up with something like:
Of course, I'd say the best approach in most cases it to minify FIRST then Gzip, than just minifying or gzipping, although depending on the code sometimes just minifying or gzipping will give you better results than doing both.
gzip 编码有一个有利的阈值。 一般规则是：文件越大，压缩效果越好，gzip 会轻而易举地获胜。 当然，您可以先缩小，然后再进行 gzip。
但是，如果我们在不超过 100 字节长的一小段文本上讨论 gzip 与 minify，“客观”比较是不可靠的，甚至是毫无意义的 - 除非我们拿出一个基线文本来建立标准的基准测试方法，类似于 Lorem Ipsum 类型，但用 Javascript 或 CSS 编写。
因此，让我建议使用我的 Fat-Free Minify (PHP) 代码（只是简单地去除空格和注释，不缩短变量，没有 baseX 编码）
以下是 minify 与 gzip 的结果（在保守水平上 - 5 压缩）与 minify+gzip：
在任何人行动之前，这不是 JS 库之战。
正如您所看到的，压缩+gzipping 可以为您大文件提供更好的压缩效果。 缩小代码有其优点，但主要因素是原始代码中存在多少空格和注释。 在这种情况下，jQuery 有更多，因此它提供了更好的缩小（内联文档中有更多的空格）。 Gzip 压缩的优势在于内容中有多少重复内容。 所以这不是关于 minify 与 gzip 的问题。 他们做事的方式不同。 通过使用两者，您将获得两全其美的效果。
There's a threshold at which gzip-encoding is advantageous. The general rule is: the larger the file, the better the compression and gzip will win hands down. Of course you can minify first then gzip after.
But if we're talking about gzip vs. minify on a small piece of text no more than 100bytes long, an "objective" comparison is unreliable, even pointless - unless we come out with a baseline text for establishing a standard means of benchmarking, like a Lorem Ipsum-type but written in Javascript or CSS.
So let me propose to benchmark the latest versions of jQuery and MooTools (the uncompressed versions) using my Fat-Free Minify (PHP) code (just plain stripping off whitespaces and comments, no shortening of variables, no baseX-encoding)
Here are the results of minify vs. gzip (at conservative level-5 compression) vs. minify+gzip:
Before anyone jumps the gun, this is not a battle of JS libraries.
As you can see, minifying+gzipping gives you better compression on large files. Minifying code has its advantages, but the major factor is how much whitespace and comments are present in the original code. In this case, jQuery has more so it gives better minification (a lot more whitespaces in the inline documentation). Gzip compression's strength is in how much repetition there is in the content. So it's not about minify vs. gzip. They do things differently. And you get the best of both worlds by using both.
为什么不两者都使用呢？
Why not use both?
测试很容易：只需将 css 文本放入文本文件中，然后使用 Linux 上的 gzip 等归档程序来压缩文件。
我刚刚这样做了，碰巧第一个css的大小是184字节
第二个是 162 字节。
所以，你是对的，即使对于 gzip 压缩的文件来说，空格也很重要，但是从这个小测试中可以看出，对于非常小的文件，压缩文件的大小可能大于原始文件的大小。
这只是由于您的示例的大小非常小，对于较大的文件，gzipping 将为您提供较小的文件。
It is easy to test : just put the text of your css in text files and compress the files using an archiver like gzip on linux .
I have just done this, and it happens that for the first css, the size is 184 bytes
and for the second one 162 bytes.
So, you are right, white space matters even for gzipped files, but as one can see from this little test, for really little files, the size of the compressed file may be greater than the size of the original file.
This is just due to the very little size of your example, for larger files, gzipping will get you smaller files.
我没有看到有人提到 Mangling，所以我发布了我的结果。
以下是我使用 UflifyJS 进行缩小和 Gzip 得出的一些数据。 我将大约 20 个文件连接在一起，大小约为 2.5MB，其中包含注释等。
Concat 文件 2.5MB
缩小后无损坏：929kb
缩小后并损坏：617kb
现在，如果我将这些文件进行 gzip 压缩，我将分别获得 239kb 和 190kb。
I did not see anyone mention Mangling so I am posting my results on that.
Here are some figures I came up with using UflifyJS for minification and Gzip. I had about 20 files that I concatenated together at about 2.5MB with comments and all.
Concat Files 2.5MB
Minified without mangling: 929kb
Minified and mangled: 617kb
Now if I take those files and gzip them I will get 239kb and 190kb respectively.
有一个非常简单的测试方法：创建一个仅包含空格的文件和另一个真正为空的文件。 然后对两者进行 Gzip 压缩并比较它们的大小。 带有空格的文件当然会更大。
There is a very simple method of testing this: Create a file consisting only of whitespace and another file that's really empty. Then Gzip both and compare their sizes. The file with the whitespace in it will of course be bigger.
当然，保留布局或其他一些重要内容并删除任何不需要的垃圾（空格、注释、冗余内容等）的“人为”有损压缩将比无损 gZip 压缩更好。
例如，诸如标记或函数名称之类的东西很可能具有一定的长度来描述含义。 用一个字符长的名称替换它会节省大量空间，并且无损压缩是不可能的。
顺便说一句，对于 CSS，有一些工具，例如 CSS 压缩器，它可以为你做有损的工作。
但是，将“有损优化”和无损压缩结合起来时，您将获得最佳结果。
Of course "human" lossy compression that preserves layout or some other important things and removes any not needed junk (whitespaces, comments, redundant things etc.) will be better than a lossless gZip compression.
For example, things like marks or function names will most likely be of a certain length to describe the meaning. Replacing this by names one character long will save much space and isn't possible with lossless compression.
By the way, for CSS there are tools like CSS compressor that'll do the lossy work for you.
However, you'll get the best results when combining "lossy optimization" and lossless compression.
当然，您可以测试 - 将您的内容写入文件并使用 zlib 将其压缩。 您还可以尝试使用“gzip”实用程序。
回到你的问题 - 源的长度和压缩结果之间没有明确的关系。 关键点是“熵”（源中每个元素的差异有多大）。
所以，这取决于你的来源如何。 例如，大量连续空间(例如，＞1000)可以被压缩为与少数(例如，＜10)空间相同的大小。
of course you can test - write your into a file and gzip it with zlib. You can also try with the "gzip" utility program.
back to your question - there's no definite relationship between the length of source and the compressed result. the key point is the 'entropy' (how different is each elements in the source).
so, that depends on how your source is. for example, lots of continous spaces (ex, > 1000) may be compressed as same size as few (ex, < 10) spaces.
这是 gzip 压缩两个文件时的结果
this is the results when gziping the two files
你是对的，minify+gzip 会导致更少的字节。 虽然没有科学证据。
怎么没有测试方法呢？
将代码缩小到一个文件中，然后将其保留在另一个文件中“未缩小”。 上传到能够对输出进行 gzip 压缩的网络服务器（例如 Apache 的 mod_deflate），安装适用于 Firefox 的 Firebug 扩展，清除缓存并访问这两个文件。 Firebug 的“NET”选项卡将包含传输的确切数据量，比较这些数据，您就有“经验”证明。
You are correct, minify+gzip results in less bytes. No scientific proof though.
How come you have no method of testing?
Minify your code in one file, and leave it "unminified" on another. Upload to a webserver capable of gziping the output (mod_deflate for Apache, for example), install Firebug extension for firefox, clear your cache and access both files. Firebug's "NET" tab will contain the exact amount of data transfered, compare those and you have "empirical" proof.