Gzip a minify

Pewnego dnia odbyłem nieco ożywioną dyskusję na temat zmniejszania JavaScript i CSS w porównaniu z kimś, kto woli używać Gzip.

Nazwę tę osobę X.

X powiedział, że Gzip już minimalizuje kod, ponieważ kompresuje twoje pliki.

Nie zgadzam się. Zip to bezstratna metoda zmniejszania rozmiaru plików. Bezstratny oznacza, że ​​oryginał musi zostać doskonale odtworzony, co oznacza, że ​​informacje muszą być przechowywane, aby można było przywrócić spacje, niepotrzebne znaki, skomentowany kod i wszystko inne. Zajmuje to więcej miejsca, ponieważ więcej trzeba skompresować.

Nie mam metody testowania, ale uważam, że Gzip tego kodu:

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

Nadal będzie większy niż Gzip tego kodu:

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

Czy jest ktoś, kto może to udowodnić, dobrze lub źle.
I proszę, nie przychodźcie i nie mówcie: „To prawda, bo tego zawsze używałem”.

Proszę tutaj o dowód naukowy.

Bardzo proste do przetestowania. Wziąłem twoje js, umieściłem je w różnych plikach i uruchomiłem na nich gzip -9. Oto wynik. Zrobiono to na maszynie WinXP z Cygwin i gzip 1.3.12.

-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

Oto kolejny test z użyciem rzeczywistego przykładu JS. Plik źródłowy to „common.js”. Oryginalny rozmiar pliku to 73134 bajty. Zminifikowano, otrzymano 26232 bajty.

Oryginalny plik:

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

Zminimalizowany plik:

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

Oryginalny plik spakowany gzip z opcją -9 (ta sama wersja co powyżej):

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

Zminimalizowany plik spakowany gzip z opcją -9 (ta sama wersja co powyżej):

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

Jak widać, istnieje wyraźna różnica między różnymi metodami. Najlepszym rozwiązaniem jest ich zminimalizowanie i zgzipowanie.

Oto wyniki testu, który przeprowadziłem jakiś czas temu, używając „prawdziwego” pliku CSS z mojej strony internetowej. Optymalizator CSS jest używany do minifikacji. Do Gzippingu użyto standardowej aplikacji do archiwizacji Linuksa dostarczanej z Ubuntu.

Oryginał: 28781 bajtów
Minifikacja: 22242 bajty
Skompresowane: 6969 bajtów
Min + Gzip: 5 990 bajtów

Osobiście uważam, że najpierw zdecyduję się na Gzipping, ponieważ to oczywiście robi największą różnicę. Jeśli chodzi o minifikację, zależy to od tego, jak pracujesz. Będziesz musiał zachować oryginalny plik CSS, aby wprowadzić zmiany w dalszej kolejności. Jeśli nie przeszkadza ci to zminimalizować po każdej zmianie, idź do tego.

(Uwaga: istnieją inne rozwiązania, takie jak uruchamianie go przez minifier „na żądanie” podczas udostępniania pliku i buforowanie go w systemie plików).

Uważaj podczas testowania tego: te dwa fragmenty kodu CSS są banalnie małe, więc nie korzystają z kompresji GZIP - samo dodanie małego nagłówka i stopki GZIP (około 20 bajtów narzutu) spowoduje utratę uzyskanych korzyści. W rzeczywistości nie miałbyś tak małego pliku CSS i martwiłbyś się o jego kompresję.

minify + gzip kompresuje więcej niż tylko gzip

Odpowiedź na pierwotne pytanie brzmi: tak, minify + gzip uzyska znacznie większą kompresję niż tylko gzip. Dotyczy to każdego nietrywialnego przykładu (tj. Dowolnego użytecznego kodu JS lub CSS, który ma więcej niż kilkaset bajtów).

Aby zobaczyć przykłady tego w efekcie, pobierz kod źródłowy Jquery, który jest dostępny zminimalizowany i nieskompresowany, skompresuj je za pomocą gzip i przyjrzyj się.

Warto zauważyć, że Javascript zyskuje znacznie więcej na minifikacji niż dobrze zoptymalizowany CSS, ale nadal jest to korzystne.

Rozumowanie:

Kompresja GZIP jest bezstratna. Oznacza to, że musi przechowywać cały tekst, w tym dokładne białe znaki, komentarze, długie nazwy zmiennych i tak dalej, aby można je było później doskonale odtworzyć. Z drugiej strony minifikacja jest stratna. Jeśli zminimalizujesz swój kod, usuniesz wiele z tych informacji z kodu, pozostawiając mniej tego, co GZIP musi zachować.

• Minifikacja odrzuca niepotrzebne białe spacje, pozostawiając spacje tylko tam, gdzie jest to konieczne ze względów składniowych.
• Minifikacja usuwa komentarze.
• Minifikacja kodu może zastąpić nazwy identyfikatorów krótszymi nazwami, w przypadku których nie byłoby żadnych skutków ubocznych.
• Minifikacja kodu może spowodować trywialne `` optymalizacje kompilatora '' w kodzie, które są możliwe tylko poprzez faktyczną analizę kodu
• Minifikacja CSS może wyeliminować zbędne reguły lub połączyć reguły, które mają ten sam selektor.

Masz rację.

Minifikacja to nie to samo, co zgzipowanie (gdyby tak było). Na przykład gzip to nie to samo:

var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null;

Następnie zminimalizuj, aby otrzymać coś takiego:

var a = null;

Oczywiście, powiedziałbym, że najlepszym podejściem w większości przypadków jest zminimalizowanie PIERWSZEJ, a następnie Gzipa, niż tylko minifikacja lub gzipowanie, chociaż w zależności od kodu czasami samo zminimalizowanie lub zgzipowanie da lepsze wyniki niż zrobienie obu tych rzeczy.

Istnieje próg, przy którym kodowanie gzip jest korzystne. Ogólna zasada jest taka: im większy plik, tym lepsza kompresja i gzip wygrywają. Oczywiście możesz najpierw zminimalizować, a potem zgzipować.

Ale jeśli mówimy o gzip kontra minify na małym fragmencie tekstu nie dłuższym niż 100 bajtów, „obiektywne” porównanie jest niewiarygodne, a nawet bezcelowe - chyba że wyjdziemy z podstawowym tekstem do ustalenia standardowych metod analizy porównawczej, jak typ Lorem Ipsum, ale napisany w Javascript lub CSS.

Więc pozwól mi zaproponować test porównawczy najnowszych wersji jQuery i MooTools (wersje nieskompresowane) przy użyciu mojego kodu Fat-Free Minify (PHP) (po prostu usunięcie białych znaków i komentarzy, bez skracania zmiennych, bez kodowania baseX)

Oto wyniki porównania minify i gzip (z konserwatywną kompresją na poziomie 5) w porównaniu z 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%)

Zanim ktokolwiek rzuci broń, to nie jest walka bibliotek JS.

Jak widać, kompresja + kompresja zapewnia lepszą kompresję dużych plików . Minimalizacja kodu ma swoje zalety, ale głównym czynnikiem jest ilość białych znaków i komentarzy w oryginalnym kodzie. W tym przypadku jQuery ma więcej, więc daje lepszą minifikację (dużo więcej białych znaków w dokumentacji wbudowanej). Siła kompresji Gzip polega na liczbie powtórzeń w treści. Więc nie chodzi o minify kontra gzip. Robią rzeczy inaczej. I uzyskujesz to, co najlepsze z obu światów, używając obu.

Dlaczego nie użyć obu?

Jest to łatwe do przetestowania: po prostu umieść tekst swojego css w plikach tekstowych i skompresuj pliki za pomocą archiwizatora, takiego jak gzip w systemie Linux.

Właśnie to zrobiłem i zdarza się, że dla pierwszego css ma rozmiar 184 bajty, a dla drugiego 162 bajty.

Więc masz rację, białe znaki mają znaczenie nawet w przypadku plików spakowanych gzipem, ale jak widać z tego małego testu, w przypadku naprawdę małych plików rozmiar skompresowanego pliku może być większy niż rozmiar oryginalnego pliku.

Wynika to tylko z bardzo małego rozmiaru twojego przykładu, w przypadku większych plików, gzipowanie da ci mniejsze pliki.

Nie widziałem, żeby ktoś wspominał o Mangling, więc publikuję moje wyniki na ten temat.

Oto kilka liczb, które wymyśliłem, używając UflifyJS do minifikacji i Gzip. Miałem około 20 plików, które połączyłem razem po około 2,5 MB z komentarzami i wszystkim.

Pliki Concat 2,5 MB

uglify({
    mangle: false
})

Minifikacja bez zniekształcania: 929kb

uglify({
    mangle: true
})

Zminimalizowany i zniekształcony: 617kb

Teraz, jeśli wezmę te pliki i spakuję je, otrzymam odpowiednio 239kb i 190kb.

Istnieje bardzo prosta metoda sprawdzenia tego: Utwórz plik składający się tylko z białych znaków i innego pliku, który jest naprawdę pusty. Następnie spakuj oba pliki i porównaj ich rozmiary. Plik z białymi znakami będzie oczywiście większy.

Oczywiście "ludzka" kompresja stratna, która zachowuje układ lub inne ważne rzeczy i usuwa niepotrzebne śmieci (białe spacje, komentarze, zbędne rzeczy itp.), Będzie lepsza niż bezstratna kompresja gZip.

Na przykład rzeczy takie jak znaki lub nazwy funkcji będą najprawdopodobniej mieć pewną długość, aby opisać znaczenie. Zastąpienie tego nazwami o długości jednego znaku pozwoli zaoszczędzić dużo miejsca i nie jest możliwe przy kompresji bezstratnej.

Nawiasem mówiąc, w przypadku CSS istnieją narzędzia takie jak kompresor CSS, który wykona za Ciebie stratną pracę.

Jednak najlepsze wyniki uzyskasz łącząc „optymalizację stratną” i bezstratną kompresję.

oczywiście możesz przetestować - zapisz go do pliku i spakuj go za pomocą zlib . Możesz także spróbować za pomocą programu narzędziowego „gzip”.

wracając do pytania - nie ma określonej zależności między długością źródła a skompresowanym wynikiem. kluczową kwestią jest „entropia” (jak różne są poszczególne elementy w źródle).

więc to zależy od tego, jakie jest twoje źródło. na przykład wiele ciągłych spacji (np.> 1000) może być skompresowanych do tego samego rozmiaru, co kilka (np. <10) spacji.

to jest wynik przy rozpakowaniu dwóch plików

bytes  File
45     min.txt
73     min.gz

72     normal.txt
81     normal.gz

Masz rację, minify + gzip daje mniej bajtów. Nie ma jednak dowodów naukowych.

Dlaczego nie masz metody testowania?

Zmniejsz kod w jednym pliku i pozostaw go „niezminifikowany” w innym. Prześlij na serwer WWW zdolny do gzipowania danych wyjściowych (na przykład mod_deflate dla Apache), zainstaluj rozszerzenie Firebug dla Firefoksa, wyczyść pamięć podręczną i uzyskaj dostęp do obu plików. Zakładka „NET” programu Firebug będzie zawierać dokładną ilość przesłanych danych, porównaj je i masz dowód „empiryczny”.