Gzip과 축소

Gzip과 축소

---

다른 날 Gzip을 선호하는 사람과 Javascript 및 CSS를 축소하는 것에 대해 다소 활발한 토론을했습니다.

이 사람을 X라고 부르겠습니다.

X는 Gzip이 파일을 압축하기 때문에 코드를 최소화한다고 말했다.

동의하지 않습니다. Zip은 파일 크기를 줄이는 무손실 방법입니다. 무손실은 원본을 완벽하게 복원해야 함을 의미합니다. 즉, 공백, 불필요한 문자, 주석 처리 된 코드 및 기타 모든 항목을 복원 할 수 있도록 정보를 저장해야합니다. 더 많은 공간을 압축해야하므로 더 많은 공간을 차지합니다.

테스트 방법이 없지만이 코드의 Gzip은 다음과 같습니다.

.a1 {
    background-color:#FFFFFF;
    padding: 40px 40px 40px 40px;
}

이 코드의 Gzip보다 여전히 더 큽니다.

.a1{body:background-color:#FFF;padding:40px}

이 옳고 그름을 증명할 수있는 사람이 있습니까?
그리고 "내가 항상 사용했던 것이 맞다"고 말하지 마십시오.

나는 여기에 과학적 증거를 요구하고 있습니다.

---

테스트하기 매우 간단합니다. 나는 당신의 js를 다른 파일에 넣고 gzip -9를 실행했습니다. 결과는 다음과 같습니다. 이는 Cygwin 및 gzip 1.3.12를 실행하는 WinXP 시스템에서 수행되었습니다.

-rwx------  1 xxxxxxxx mkgroup-l-d     88 Apr 30 09:17 expanded.js.gz

-rwx------  1 xxxxxxxx mkgroup-l-d     81 Apr 30 09:18 minified.js.gz

다음은 실제 JS 예제를 사용한 추가 테스트입니다. 소스 파일은 "common.js"입니다. 원본 파일 크기는 73134 바이트입니다. 축소되었으므로 26232 바이트가되었습니다.

원본 파일 :

-rwxrwxrwx 1 xxxxxxxx mkgroup-l-d 73134 Apr 13 11:41 common.js

축소 된 파일 :

-rwxr-xr-x 1 xxxxxxxx mkgroup-l-d 26232 Apr 30 10:39 common-min.js

-9 옵션으로 압축 된 원본 파일 (위와 동일한 버전) :

-rwxrwxrwx 1 xxxxxxxx mkgroup-l-d 12402 Apr 13 11:41 common.js.gz

-9 옵션으로 압축 된 축소 파일 (위와 동일한 버전) :

-rwxr-xr-x 1 xxxxxxxx mkgroup-l-d  5608 Apr 30 10:39 common-min.js.gz

보시다시피 다양한 방법 사이에는 명확한 차이가 있습니다. 가장 좋은 방법은 축소하고 gzip을 모두 사용하는 것입니다.

---

다음은 내 웹 사이트에서 "실제"CSS 파일을 사용하여 잠시 전에 수행 한 테스트 결과입니다. CSS 최적화 프로그램 은 축소에 사용됩니다. Ubuntu와 함께 제공되는 표준 Linux 아카이브 앱이 Gzipping에 사용되었습니다.

원본 : 28,781 바이트
축소 된 : 22,242 바이트
Gzip으로 압축 : 6,969 바이트
최소 + Gzip으로 : 5990 바이트

내 개인적인 의견은 Gzipping에 먼저가는 것입니다. 왜냐하면 그것이 가장 큰 차이를 만들기 때문입니다. 축소는 작업 방식에 따라 다릅니다. 줄을 더 편집하려면 원본 CSS 파일을 유지해야합니다. 모든 변경 후에 그것을 축소하지 않아도되면 갈 수 있습니다.

(참고 : 파일을 제공 할 때 "주문형"축소기를 통해 파일을 실행하고 파일 시스템에서 캐싱하는 등의 다른 솔루션이 있습니다.)

---

이것을 테스트 할 때 조심하십시오 : CSS의 두 스 니펫은 사소하게 작기 때문에 GZIP 압축의 이점을 얻지 못합니다. GZIP의 작은 헤더 만 추가하면 얻을 수있는 이익을 잃을 것입니다. 실제로는 CSS 파일이 작고 압축에 관심이 없습니다.

축소 + gzip은 단순한 gzip 이상의 압축

원래 질문에 대한 대답은 그렇습니다. 축소 + gzip은 gzip보다 압축률이 훨씬 높습니다. 이것은 사소한 예제 (즉, 수백 바이트가 넘는 유용한 JS 또는 CSS 코드)에 해당됩니다.

이것의 예를 들어, 축소 및 압축 해제로 제공되는 Jquery 소스 코드 를 가져 와서 gzip으로 압축하고 살펴보십시오.

Javascript는 잘 최적화 된 CSS보다 축소로 인해 더 많은 이점이 있지만 여전히 이점이 있다는 점은 주목할 가치가 있습니다.

추리:

GZIP 압축은 무손실입니다. 즉, 정확한 공백, 주석, 긴 변수 이름 등을 포함한 모든 텍스트를 저장해야하므로 나중에 완벽하게 재현 할 수 있습니다. 반면, 축소는 손실됩니다. 코드를 축소하면 코드에서이 정보를 많이 제거하므로 GZIP가 보존해야 할 정보가 줄어 듭니다.

• 축소는 불필요한 공백을 버리고 구문상의 이유로 필요한 경우에만 공백을 남깁니다.
• 축소는 주석을 제거합니다.
• Code minification may replace identifier names with shorter names where there would be no side-effects.
• Code minification may make trivial 'compiler optimizations' to the code which are only possible by actually parsing the code
• CSS minification may eliminate redundant rules or combine rules which have the same selector.

---

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:

var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null;

Than minify to end up with something like:

var a = null;

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.

---

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:

MooTools-Core
-------------
Baseline 102,991 bytes
Minified 79,414 (77.1% of original)
Gzipped 27,406 (26.6%)
Minified+Gzipped 22,446 (21.8%)

jQuery
------
Baseline 170,095
Minified 99,735 (58.6% of original)
Gzipped 46,501 (27.3%)
Minified+Gzipped 27,938 (16.4%)

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?

---

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.

---

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

uglify({
    mangle: false
})

Minified without mangling: 929kb

uglify({
    mangle: true
})

Minified and mangled: 617kb

Now if I take those files and gzip them I will get 239kb and 190kb respectively.

---

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.

---

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.

---

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.

---

this is the results when gziping the two files

bytes  File
45     min.txt
73     min.gz

72     normal.txt
81     normal.gz

---

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.

참고URL : https://stackoverflow.com/questions/807119/gzip-versus-minify