[WP] Kompresja Gzip a Brotli: różnice między dwoma algorytmami kompresji

Aby przyspieszyć witryny, w tym te zbudowane na CMS WordPress, warto ustawić kompresję danych na serwerze. Dzięki temu dane przesyłane między serwerem a przeglądarką ładują się szybciej, a cała witryna przyspiesza. To jeden z czynników, o których administratorzy witryn myślą najczęściej. Kompresja gzip jest powszechna, a na wielu serwerach coraz częściej przechodzi się z gzip na Brotli .

1️⃣ Czym jest kompresja?

Witryna URL: po jego otwarciu zaczyna się rozmowa przeglądarki z serwerem. Przeglądarka mówi wtedy serwerowi, czy potrafi rozpakować kompresję treści (Compression) i jakich algorytmów kompresji używa. Pomaga to przeglądarce poprawnie rozpakować dane, gdy serwer wysyła je skompresowane. Z serwerem i przeglądarką obsługującymi algorytmy kompresji twoja witryna ładuje się więc jeszcze szybciej.

Gdy przeglądarka łączy się z serwerem, wysyła nagłówki, np. o kompresji gzip lub Brotli. Do przeglądarki trafiają dane skompresowane jedną z tych metod, a dane skompresowane ładują się szybciej niż nieskompresowane.

Content-encoding: gzip
Content-encoding: br

Kompresji podlegają głównie pliki tekstowe:
· HTML
· CSS
· JavaScript

2️⃣ Czym jest kompresja Gzip?

Najczęstsze algorytmy kompresji u dostawców hostingu to Gzip i Brotli. Beta Gzip ukazała się w 1992 roku, a wersja 1.0 w 1993. Ogólnie Gzip to jedna ze standardowych metod kompresji danych przesyłanych przez internet. Opiera się na DEFLATE, wczesnym algorytmie kompresji, a nazwę wziął od gzip, wcześniejszego uniksowego programu do kompresji plików.

DEFLATE łączy algorytm LZ77 (Lempel-Ziv 1977) z kodowaniem Huffmana. LZ77 szuka powtarzających się danych, znajduje pasujące ciągi i zastępuje je kodami. Kodowanie Huffmana wykorzystuje częstość występowania znaków, by przypisać najkrótsze kody bitowe.

Gzip kompresuje dane metodą DEFLATE i dzięki nagłówkowi ‘Accept-Encoding: gzip’ w żądaniach i odpowiedziach HTTP kompresuje tylko wtedy, gdy klient obsługuje Gzip. Ta kompresja pomaga witrynom szybciej się ładować.

3️⃣ Czym jest kompresja Brotli?

Brotli opracowali w 2013 roku inżynierowie Google Jyrki Alakuijala i Zoltán Szabadka.

Gzip był pierwotnie przeznaczony do kompresji plików, ale został dostosowany do użytku w sieci. Brotli natomiast od początku powstał z myślą o sieci. Dzięki temu z Brotli serwer może skompresować treść przed wysłaniem jej do przeglądarki. Ponieważ kompresja następuje przed przesłaniem strumienia do przeglądarki, to lepsze i nowocześniejsze podejście.

Brotli korzysta z tych samych dwóch podstawowych technik co kompresja GZIP: LZ77 i kodowania Huffmana.

4️⃣ Kompresja Gzip a kompresja Brotli

Gzip kompresuje (i rozpakowuje) dane metodą DEFLATE, a Brotli używa własnego formatu, który do LZ77 i kodowania Huffmana dodaje modelowanie kontekstu.

• Gzip kompresuje szybciej niż Brotli.
• Brotli zaprojektowano specjalnie dla sieci.
• Brotli zapewnia lepszy współczynnik kompresji (czyli mniejsze pliki) na każdym poziomie.
• W porównaniu z Gzip Brotli lepiej kompresuje trzy typy plików: HTML o 21%, CSS o 17% i JavaScript o 14%.

Coraz więcej serwerów woli Brotli od Gzip. Ponieważ Brotli zaprojektowano do kompresji strumieni w locie, rozpakowywanie po stronie front-endu ma być nawet o 64% szybsze niż przy Gzip.

RFC 1952 z maja 1996 roku wyjaśnia, że format Gzip używa metody kompresji DEFLATE i zawiera wartość CRC do wykrywania uszkodzeń danych. Na końcu skompresowanych danych zapisane są wartość CRC-32 i rozmiar danych oryginalnych.

RFC 7932 z lipca 2016 roku podaje, że Brotli kompresuje, łącząc algorytm LZ77 z kodowaniem Huffmana. Dodatkowo używa dwóch poprzednich bajtów nieskompresowanych danych jako kontekstu do wyboru kodów Huffmana, a zamiast powtarzających się ciągów może odwoływać się do słów ze statycznego słownika o rozmiarze 122 784 bajtów.

Oba formaty pojawiają się w nagłówku odpowiedzi jako [Content-Encoding: gzip] i [Content-Encoding: br]. Wartość [br] zarejestrowano jako kodowanie treści HTTP w RFC 7932.

5️⃣ Pomiar kompresji Gzip i Brotli: serwer Nginx + Apache

Na serwerze WordPress z Nginx i Apache porównałem odpowiedzi dla jednego wpisu, domyślnego pliku CSS bloków WordPressa i pliku jQuery, zmieniając tylko nagłówek żądania. Żądania z samym gzip w [Accept-Encoding], samym br i bez nagłówka wysłałem curlem z tego samego serwera.

for ae in gzip br ''; do echo == ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/hello-world/ | grep -i -E '^(content-encoding|size)'; done

== gzip
content-encoding: gzip
size: 21390
== br
content-encoding: br
size: 20190
== none
size: 90833

HTML jednego wpisu skompresowano do 21 390 bajtów przy żądaniu gzip i do 20 190 bajtów przy br, a żądanie bez nagłówka dostało nieskompresowane 90 833 bajty. Odpowiedź br była o 1200 bajtów (5,6%) mniejsza niż gzip.

for f in wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do for ae in gzip br ''; do echo == ${f##*/} ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/$f | grep -i -E '^(content-encoding|size)'; done; done

== style.min.css gzip
content-encoding: gzip
size: 19655
== style.min.css br
size: 140829
== style.min.css none
size: 140829
== jquery.min.js gzip
content-encoding: gzip
size: 30633
== jquery.min.js br
size: 87553
== jquery.min.js none
size: 87553

Przy żądaniu gzip plik CSS skompresowano do 19 655 bajtów, a plik jQuery do 30 633 bajtów. Przy samym br lub bez nagłówka serwer zwrócił bez zmian oryginały o rozmiarze 140 829 i 87 553 bajtów, bez nagłówka [Content-Encoding].

nginx -V 2>&1 | grep -c brotli

0

httpd -M 2>/dev/null | grep -E 'brotli|deflate'

 deflate_module (shared)
 brotli_module (shared)

Pliki statyczne, takie jak CSS i JS, serwuje i kompresuje bezpośrednio Nginx, a ponieważ Nginx w tej konfiguracji nie ma modułu Brotli, kompresuje tylko gzipem.

W przypadku HTML na żądanie przekazane przez Nginx do Apache odpowiada WordPress, a kompresuje Apache. Apache ma zarówno moduł Brotli, jak i moduł [mod_deflate] odpowiedzialny za kompresję Gzip.

for f in hello-world/ wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do echo == $f; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H 'Accept-Encoding: gzip, deflate, br, zstd' https://example.com/$f | grep -i -E '^(content-encoding|size)'; done

== hello-world/
content-encoding: gzip
size: 21390
== wp-includes/css/dist/block-library/style.min.css
content-encoding: gzip
size: 19655
== wp-includes/js/jquery/jquery.min.js
content-encoding: gzip
size: 30633

Moduł Brotli na serwerze nie oznacza, że przeglądarka dostanie odpowiedzi skompresowane Brotli. Przy żądaniu [gzip, deflate, br, zstd], czyli wartości wysyłanej przez Edge 155, Apache też skompresował HTML gzipem i wszystkie trzy pliki wróciły w gzip.

Nawet gdy br stało przed gzip albo było oznaczone jako preferowane, jak w [br;q=1.0, gzip;q=0.5], HTML wracał w gzip. Po otwarciu tego samego wpisu i dwóch plików w Edge też wszystkie przyszły w gzip.

Czas do pierwszego bajtu to mediana wartości [time_starttransfer] z curla, mierzonych po 40 razy w losowej kolejności; każde żądanie otwierało nowe połączenie, więc wliczono czas połączenia TLS. Dla HTML odpowiedź bez kompresji trwała 22,7 ms, gzip 26,3 ms, br 26,5 ms, a żądanie jak z przeglądarki 25,0 ms. CSS i JS trwały 18–21 ms z kompresją i bez.

Szybkości kompresji Gzip i Brotli nie mierzyłem tutaj, tylko porównałem źródła publiczne. RFC 7932 podaje, że Brotli kompresuje ze znacznie wyższym współczynnikiem niż program gzip i rozpakowuje dużo szybciej niż obecne implementacje LZMA. W repozytorium Brotli Google wyjaśnia, że Brotli ma szybkość podobną do deflate, ale kompresuje gęściej.

W 2015 roku Cloudflare przetestował obie metody na 10 655 plikach HTML, CSS i JavaScript. Brotli w najwyższej jakości dawało wyniki średnio 1,19 raza mniejsze niż zlib w najwyższej jakości, ale kompresowało 0,5 MB na sekundę, znacznie wolniej niż 41,9 MB zlib na poziomie 9. Brotli poziom 4 miało współczynnik podobny do zlib poziom 8 i średnio było nieco szybsze, ale przy samych plikach mniejszych niż 64 KB – 1,48 raza wolniejsze.

Omówiliśmy optymalizację witryny przez kompresję plików takich jak HTML, CSS i JavaScript. Dla szybszej witryny kompresja plików i Optymalizacja obrazków to jedne z podstawowych elementów.

🔢 FAQ & polecane treści

ℹ️ Informacja o linkach partnerskich
Treści tej witryny zawierają linki partnerskie. Jeśli odwiedzający kupi produkt lub usługę przez taki link, witryna otrzymuje od sprzedawcy prowizję. Kwota płacona przy tym przez kupującego ^{(podczas promocji spada↓)} nie wzrasta. Podane ceny, rabaty i dostępność odnoszą się do chwili pisania i mogą różnić się od stanu faktycznego, dlatego przed zakupem sprawdź je u sprzedawcy. Produkty wybieramy i oceniamy według własnych kryteriów, a prowizja nie wpływa ani na kolejność prezentacji, ani na treść ocen.