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의 작은 머리글과 바닥 글 (약 20 바이트 오버 헤드) 만 추가하면 얻는 이익을 잃을 것입니다. 실제로는 CSS 파일이 작고 압축에 관심이 없습니다.

축소 + gzip은 단순한 gzip 이상을 압축합니다.

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

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

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

추리:

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

• 축소는 불필요한 공백을 버리고 구문상의 이유로 필요한 경우에만 공백을 남깁니다.
• 축소는 주석을 제거합니다.
• 코드 축소는 식별자 이름을 부작용이없는 짧은 이름으로 대체 할 수 있습니다.
• 코드 축소는 실제로 코드를 구문 분석하여 가능한 코드에 대한 간단한 '컴파일러 최적화'를 만들 수 있습니다.
• CSS 축소는 중복 규칙을 제거하거나 선택기가 동일한 규칙을 결합 할 수 있습니다.

네가 옳아.

gzipping보다 축소하는 것은 동일하지 않습니다 (이 경우에는 동일하다고 함). 예를 들어, gzip을 사용하는 것과 동일하지 않습니다.

var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null;

축소하면 다음과 같은 결과가 나타납니다.

var a = null;

물론, 대부분의 경우 코드에 따라 축소 또는 gzipping 만하면 두 가지를 수행하는 것보다 더 나은 결과를 얻을 수 있지만 대부분의 경우 FIRST 다음 Gzip을 축소하는 것보다 축소 또는 축소하는 것이 가장 좋습니다.

gzip 인코딩이 유리한 임계 값이 있습니다. 일반적인 규칙은 파일이 클수록 압축과 gzip이 더 잘 처리되는 것입니다. 물론 먼저 축소 한 다음 gzip을 사용할 수 있습니다.

그러나 우리가 100 바이트 이하의 작은 텍스트에서 gzip과 minify에 대해 이야기하고 있다면, "객관적인"비교는 신뢰할 수없고 무의미합니다. 표준 벤치마킹 수단을 설정하기위한 기본 텍스트를 제시하지 않으면, Lorem Ipsum 유형과 비슷하지만 Javascript 또는 CSS로 작성되었습니다.

따라서 PHP ( Fat-Free Minify ) 코드를 사용하여 최신 버전의 jQuery 및 MooTools (압축되지 않은 버전)를 벤치마킹하도록 제안합니다 ( 공백 및 주석의 일반적인 제거, 변수 단축, baseX 인코딩 없음).

다음은 minify vs. gzip (보수적 수준 5 압축) 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%)

누군가가 총을 뛰어 넘기 전에 이것은 JS 라이브러리와의 싸움이 아닙니다.

보시다시피, 축소 + gzipping은 큰 파일에서 더 나은 압축 을 제공 합니다 . 코드 축소에는 장점이 있지만 주요 요소는 원래 코드에 공백과 주석이 얼마나 많이 있는지입니다. 이 경우 jQuery가 더 많기 때문에 더 나은 축소를 제공합니다 (인라인 문서에서 더 많은 공백). Gzip 압축의 강점은 내용에 얼마나 많은 반복이 있는지에 있습니다. 따라서 gzip에 대한 축소는 아닙니다. 그들은 다르게 일을합니다. 그리고 당신은 두 가지를 모두 사용하여 두 세계를 최대한 활용할 수 있습니다.

왜 둘 다 사용하지 않습니까?

테스트하기 쉽습니다. CSS의 텍스트를 텍스트 파일에 넣고 Linux의 gzip과 같은 아카이버를 사용하여 파일을 압축하십시오.

방금이 작업을 수행했으며 첫 번째 CSS의 경우 크기는 184 바이트이고 두 번째는 162 바이트입니다.

따라서 zip 파일은 공백이 중요하지만이 작은 테스트에서 볼 수 있듯이 실제로는 작은 파일의 경우 압축 파일의 크기가 원본 파일의 크기보다 클 수 있습니다.

큰 크기의 파일의 경우 gzipping하면 작은 파일을 얻을 수 있습니다.

나는 Mangling에 대해 언급하지 않았으므로 그 결과를 게시하고 있습니다.

다음은 축소 및 Gzip에 UflifyJS를 사용하여 얻은 몇 가지 그림입니다. 나는 약 20MB의 파일을 의견과 함께 약 2.5MB로 함께 연결했습니다.

Concat 파일 2.5MB

uglify({
    mangle: false
})

맹 글링없이 축소 : 929kb

uglify({
    mangle: true
})

축소 및 엉망 : 617kb

이제 파일을 가져 와서 압축하면 각각 239kb와 190kb를 얻습니다.

이를 테스트하는 매우 간단한 방법이 있습니다. 공백으로 만 구성된 파일과 실제로 비어있는 다른 파일을 만듭니다. 그런 다음 둘 다 Gzip을 사용하여 크기를 비교하십시오. 공백이있는 파일은 물론 더 커질 것입니다.

물론 레이아웃이나 다른 중요한 것들을 보존하고 불필요한 정크 (공백, 주석, 중복되는 것들 등)를 제거하는 "인간"손실 압축은 손실없는 gZip 압축보다 낫습니다.

예를 들어, 마크 또는 함수 이름과 같은 것은 의미를 설명하기 위해 특정 길이 일 것입니다. 한 문자 길이로 이름을 바꾸면 많은 공간이 절약되며 무손실 압축으로는 불가능합니다.

그런데 CSS에는 CSS 압축기 와 같은 도구 가있어 손실이 많은 작업을 수행합니다.

그러나 "손실 최적화"와 무손실 압축을 결합하면 최상의 결과를 얻을 수 있습니다.

물론 파일에 테스트를 작성하고 zlib로 gzip으로 압축 할 수 있습니다. "gzip"유틸리티 프로그램으로 시도 할 수도 있습니다.

귀하의 질문으로 돌아 가기-소스 길이와 압축 결과 사이에는 명확한 관계가 없습니다. 핵심은 '엔트로피'(소스의 각 요소가 얼마나 다른가)입니다.

소스의 상태에 따라 다릅니다. 예를 들어, 많은 연속 공간 (예 :>> 1000)은 소수 (예 : <10) 공간과 동일한 크기로 압축 될 수 있습니다.

이것은 두 파일을 압축 할 때의 결과입니다

bytes  File
45     min.txt
73     min.gz

72     normal.txt
81     normal.gz

바이트 수가 적은 올바른 minify + gzip 결과입니다. 과학적인 증거는 없습니다.

테스트 방법이 없습니까?

한 파일에서 코드를 축소하고 다른 파일에서는 "축소하지 않은"상태로 둡니다. 출력을 gzip으로 압축 할 수있는 웹 서버 (예 : Apache의 경우 mod_deflate)를 업로드하고 Firefox 용 Firebug 확장을 설치하고 캐시를 지우고 두 파일 모두에 액세스하십시오. Firebug의 "NET"탭에는 전송 된 정확한 양의 데이터가 들어 있으며이를 비교하면 "임시"증거가 있습니다.