Czym jest kompresja Gzip i Brotli?

Gzip i Brotli to algorytmy kompresji, których Twój serwer WWW używa do zmniejszania plików przed wysłaniem ich do przeglądarki odwiedzającego. Idea jest prosta: pliki oparte na tekście, takie jak HTML, CSS i JavaScript, zawierają wiele powtarzających się wzorców, a algorytmy kompresji są w tym bardzo dobre — w znajdowaniu i eliminowaniu tej redundancji. Plik HTML 100 KB może zostać skompresowany do 15-20 KB. Przeglądarka natychmiast go dekompresuje, a odwiedzający niczego nie zauważa, poza tym, że strona ładuje się szybciej.

Jeśli kiedykolwiek spakowałeś folder na komputerze, znasz już podstawową koncepcję. Kompresja sieciowa działa w ten sam sposób, ale automatycznie i przejrzyście. Serwer kompresuje odpowiedź, przeglądarka ją dekompresuje, a ani deweloper, ani odwiedzający nie muszą robić nic szczególnego (pod warunkiem, że serwer jest poprawnie skonfigurowany).

Jak działa kompresja sieciowa na poziomie protokołu

Za każdym razem, gdy przeglądarka wysyła żądanie HTTP, dołącza nagłówek Accept-Encoding, który mówi serwerowi, jakie algorytmy kompresji obsługuje:

Accept-Encoding: gzip, deflate, br

Ten nagłówek mówi, że przeglądarka radzi sobie z Gzip, Deflate i Brotli (skrócone do br). Serwer wybiera najlepszy obsługiwany algorytm, kompresuje body odpowiedzi i dodaje nagłówek Content-Encoding, by powiedzieć przeglądarce, jakiego algorytmu użyto:

Content-Encoding: gzip

lub:

Content-Encoding: br

Przeglądarka czyta ten nagłówek, stosuje odpowiedni algorytm dekompresji i renderuje treść. Jeśli serwer nie obsługuje kompresji (lub nie jest skonfigurowany), wysyła odpowiedź nieskompresowaną i nie ma nagłówka Content-Encoding.

Ta negocjacja odbywa się przy każdym osobnym żądaniu. Serwer może wybrać różne metody kompresji dla różnych typów plików, a nawet serwować nieskompresowaną treść dla plików, które nie skorzystałyby z kompresji.

Gzip: ugruntowany standard

Gzip jest koniem roboczym kompresji sieciowej od końca lat dziewięćdziesiątych. Opiera się na algorytmie DEFLATE (kombinacja LZ77 i kodowania Huffmana) i jest obsługiwany dosłownie przez każdą używaną przeglądarkę i serwer WWW. Gdy ludzie mówią o "włączeniu kompresji" na serwerze WWW, zwykle mają na myśli Gzip.

Gzip działa z regulowanymi poziomami kompresji, zwykle od 1 (najszybszy, najmniejsza kompresja) do 9 (najwolniejszy, najlepsza kompresja). Większość serwerów WWW jest domyślnie ustawiona na poziom 6, co daje dobry balans między współczynnikiem kompresji a użyciem CPU. Na poziomie 6 Gzip zwykle osiąga 70-85% kompresji na plikach tekstowych. Plik CSS 100 KB staje się wtedy około 15-30 KB.

Główne zalety Gzip to uniwersalność (działa wszędzie), szybkość przy umiarkowanych poziomach kompresji i dziesięciolecia optymalizacji włożonych w implementacje. Główna wada to fakt, że nie kompresuje tak dobrze jak Brotli, zwłaszcza dla mniejszych plików.

Brotli: nowoczesna alternatywa

Brotli został opracowany przez Google i opublikowany w 2016 roku jako RFC 7932. Został zaprojektowany specjalnie dla treści internetowych i osiąga współczynniki kompresji o 15-25% lepsze niż Gzip na typowych zasobach webowych. Brotli osiąga to przez użycie bardziej zaawansowanego algorytmu kompresji i dołączenie wbudowanego słownika z popularnymi ciągami w treści webowej (tagi HTML, właściwości CSS, słowa kluczowe JavaScript itp.).

Brotli również używa regulowanych poziomów kompresji, od 0 do 11. Przy porównywalnych poziomach jakości Brotli produkuje mniejszy wynik niż Gzip, ale na najwyższych poziomach (10-11) Brotli jest znacznie wolniejszy w kompresji. Wysoko ustawiona kompresja Brotli jest więc idealna dla statycznych zasobów, które można skompresować raz z wyprzedzeniem i potem serwować wiele razy, a mniej odpowiednia dla dynamicznej treści, która musi być kompresowana przy każdym żądaniu.

Ważne ograniczenie: Brotli działa tylko przez HTTPS. Przeglądarki nie akceptują odpowiedzi skompresowanych przez Brotli przez zwykłe połączenia HTTP. Ponieważ większość witryn WordPress powinna i tak działać na HTTPS (a HTTP/2 tego wymaga), rzadko jest to praktyczny problem.

Gzip kontra Brotli: praktyczne porównanie

Oto jak te dwa algorytmy wypadają w metrykach, które mają znaczenie dla właścicieli witryn WordPress:

• Współczynnik kompresji: Brotli zwykle produkuje pliki, które przy porównywalnych poziomach kompresji są o 15-25% mniejsze niż Gzip. Na witrynie WordPress ładującej 500 KB kompresowalnych zasobów ta różnica przekłada się na około 15-30 KB mniej ruchu danych na ładowanie strony.
• Szybkość kompresji: Gzip na poziomie 6 jest szybszy niż Brotli na równoważnym ustawieniu jakości. Dla dynamicznej treści (stron HTML generowanych przez PHP) Gzip jest często bardziej praktycznym wyborem, ponieważ kompresja odbywa się przy każdym żądaniu. Brotli na poziomie 1-4 jest porównywalny szybkością z Gzip i nadal kompresuje nieco lepiej.
• Szybkość dekompresji: Brotli dekompresuje nieco szybciej niż Gzip, pozwalając przeglądarce minimalnie szybciej przetwarzać treść. Różnica jest mała, ale konsekwentna.
• Wsparcie przeglądarek: wszystkie nowoczesne przeglądarki wspierają zarówno Gzip, jak i Brotli. Internet Explorer (już wycofany) nie wspierał Brotli, ale Edge, Chrome, Firefox i Safari tak. Globalne wsparcie przeglądarek dla Brotli przekracza 96%.
• Wsparcie serwerów: Apache wspiera Brotli przez mod_brotli (dostępne od Apache 2.4.26). Nginx wspiera go przez moduł ngx_brotli (zewnętrzny moduł, który trzeba osobno skompilować). LiteSpeed ma wbudowane wsparcie Brotli. Większość zarządzanych dostawców hostingu i CDN wspiera oba.
• Wymóg HTTPS: Brotli wymaga HTTPS. Gzip działa zarówno przez HTTP, jak i HTTPS.

W praktyce wiele serwerów jest skonfigurowanych, by preferować Brotli, gdy przeglądarka go obsługuje, i wracać do Gzip w przeciwnym razie. W ten sposób otrzymujesz najlepszą kompresję dla nowoczesnych przeglądarek i zachowujesz kompatybilność ze starszymi klientami.

Włączenie kompresji w Apache

Dla Apache włączasz kompresję Gzip przez mod_deflate (mylna nazwa, ale używa Gzip, nie surowego Deflate). Dodaj poniższe do .htaccess:

  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/json
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE application/font-woff2

Dla Brotli na Apache potrzebujesz mod_brotli:

  AddOutputFilterByType BROTLI_COMPRESS text/html
  AddOutputFilterByType BROTLI_COMPRESS text/css
  AddOutputFilterByType BROTLI_COMPRESS text/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/json

Włączenie kompresji w Nginx

Dla Nginx Gzip jest wbudowane i trzeba tylko aktywować to w konfiguracji:

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Dla Brotli na Nginx, po zainstalowaniu modułu ngx_brotli:

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Wtyczki cache WordPress i kompresja

Jeśli nie masz dostępu do konfiguracji serwera (typowe w hostingu współdzielonym), kilka wtyczek cache WordPress może obsłużyć kompresję za Ciebie:

• WP Rocket: automatycznie włącza kompresję Gzip, dodając reguły do Twojego .htaccess. Tworzy też skompresowane wcześniej statyczne pliki cache HTML.
• W3 Total Cache: oferuje kompresję Gzip jako regulowaną opcję w ustawieniach Browser Cache. Może też serwować skompresowane wcześniej pliki.
• LiteSpeed Cache: jeśli Twój host działa na serwerze LiteSpeed, ta wtyczka automatycznie włącza zarówno Gzip, jak i Brotli.
• WP Super Cache: zawiera opcję kompresji Gzip, która kompresuje cache'owane strony.
• Autoptimize: choć głównie wtyczka optymalizacji CSS/JS, może też serwować skompresowane wersje generowanych plików.

Pamiętaj, że jeśli Twój serwer już obsługuje kompresję na poziomie serwera, włączanie jej ponownie przez wtyczkę jest niepotrzebne i może czasem powodować konflikty (podwójną kompresję, której przeglądarki nie mogą zdekompresować).

Jakie typy plików najbardziej korzystają z kompresji

Kompresja działa najlepiej na treściach tekstowych i powtarzających się. Przegląd według typu pliku:

• HTML: kompresuje się świetnie (70-90% redukcji). Strony HTML generowane przez WordPress są pełne powtarzających się struktur tagów, nazw klas i białych znaków.
• CSS: kompresuje się bardzo dobrze (80-90% redukcji). Arkusze stylów zawierają wiele powtarzających się nazw właściwości i selektorów.
• JavaScript: kompresuje się bardzo dobrze (70-85% redukcji). Pliki JS mają powtarzające się słowa kluczowe, nazwy funkcji i wzorce strukturalne.
• SVG: kompresuje się świetnie (80-95% redukcji). SVG są oparte na XML i mocno powtarzające się.
• JSON: kompresuje się bardzo dobrze (75-90% redukcji). Odpowiedzi API i dane konfiguracyjne znacznie korzystają.
• XML- i RSS-feedy: kompresują się bardzo dobrze dzięki ich powtarzającej się strukturze tagów.
• Webfonty (WOFF/WOFF2): fonty WOFF2 zawierają już wewnętrznie kompresję Brotli, więc dodatkowa kompresja po stronie serwera niewiele daje. Fonty WOFF zawierają lżejszą kompresję i mogą marginalnie skorzystać z Gzip.

Co NIE powinno być kompresowane

Nie wszystkie typy plików korzystają z kompresji, a niektóre powinny być aktywnie wykluczone:

• Obrazy JPEG, PNG, WebP, AVIF: te formaty są już skompresowane. Przepuszczanie ich przez Gzip lub Brotli marnuje czas CPU i może nawet nieznacznie zwiększyć rozmiar pliku.
• Pliki wideo (MP4, WebM): już skompresowane bardzo wydajnymi kodekami. Kompresja po stronie serwera dodaje narzut bez korzyści.
• Pliki audio (MP3, AAC, OGG): tak samo jak wideo, już skompresowane.
• Pliki ZIP, GZIP i inne archiwa: już skompresowane z definicji.
• Pliki PDF: większość PDF-ów używa wewnętrznej kompresji. Dodatkowa kompresja daje pomijalne oszczędności.

Kompresowanie już skompresowanych plików marnuje CPU serwera przy każdym żądaniu i może nawet dawać nieznacznie większy wynik. Większość konfiguracji serwerów WWW i wtyczek cache WordPress poprawnie ogranicza kompresję do typów MIME opartych na tekście, ale warto zweryfikować, że pliki binarne są wykluczone.

Co sprawdza InspectWP

InspectWP analizuje nagłówek odpowiedzi Content-Encoding zwracany przez Twoją witrynę WordPress, aby określić, czy kompresja jest aktywna. Szuka konkretnie gzip, br (Brotli) lub deflate w wartości nagłówka. Jeśli nie wykryto kompresji, raport sygnalizuje to jako problem wydajnościowy z zaleceniem włączenia kompresji Gzip lub Brotli. Wykryta metoda kompresji jest pokazywana w sekcji wydajności raportu i daje jasny obraz, czy Twój serwer jest poprawnie skonfigurowany, by ograniczać rozmiar transferu.