Gzip i Brotli - jak włączyć kompresję strony WWW i sprawdzić efekt?

Gzip i Brotli kompresują treść odpowiedzi HTTP, czyli dane wysyłane przez serwer do przeglądarki. HTTP to protokół przesyłania zasobów między klientem a serwerem, a kompresja zmniejsza ilość przesyłanych danych kosztem ich późniejszego odtworzenia przez odbiorcę.

Serwer zwykle dobiera kompresję na podstawie typu MIME, który opisuje format odpowiedzi w nagłówku `Content-Type`. Tekstowe typy często obejmowane kompresją to `text/html`, `text/css`, `text/javascript`, `application/javascript`, `application/json` i `application/xml`. Przed dodaniem typu do konfiguracji sprawdź faktyczny `Content-Type` zwracany dla danego zasobu, ponieważ serwer może oznaczyć JavaScript innym typem niż zakładany.

Zdjęcia JPEG, WebP i AVIF oraz pliki wideo są już skompresowane w swoich formatach. Ponowne pakowanie ich przez Gzip lub Brotli zazwyczaj nie zmniejsza istotnie transferu, a może zużywać CPU. Kompresja HTTP nie zastępuje zmiany formatu, wymiarów ani jakości obrazu; osobnym zadaniem jest optymalizacja zdjęć na stronie WWW.

Jeśli kompresja jest częścią większego planu, porównaj ją z pozostałymi etapami opisanymi w poradniku jak przyspieszyć stronę internetową.

Gzip działa w szerokim zakresie serwerów i klientów, a Brotli często uzyskuje mniejszy rozmiar tekstowych odpowiedzi przy porównywalnym zastosowaniu. Wynik zależy od treści, poziomu kompresji, sposobu generowania zasobu i serwera, więc nie przypisujemy każdej stronie jednej uniwersalnej oszczędności.

Przeglądarka przekazuje listę akceptowanych kodowań w `Accept-Encoding`. Serwer wybiera kodowanie obsługiwane przez klienta i zwraca je w `Content-Encoding`, na przykład `gzip` albo `br`. Typowa konfiguracja wybiera jeden algorytm spośród alternatyw kompresji dla danej odpowiedzi. Protokół HTTP dopuszcza jednak kilka kodowań zastosowanych kolejno i wymaga wtedy wymienienia ich w kolejności zastosowania. Nagłówek `Vary: Accept-Encoding` wskazuje cache, że wariant odpowiedzi może zależeć od nagłówka żądania. Zasady opisuje RFC 9110.

Dostępność Brotli zależy od oprogramowania serwera, dostępnych modułów i ustawień hostingu lub CDN. Tabela porównuje praktyczne różnice istotne przy wyborze konfiguracji.

Wniosek: sprawdź możliwości obecnego hostingu, bo sama dostępność Gzip nie potwierdza obsługi Brotli.

Jeśli chcesz ocenić kompresję razem z cache, skryptami i obrazami, optymalizacja szybkości WooCommerce obejmuje analizę tych elementów.

Nagłówek `Content-Encoding: br` albo `Content-Encoding: gzip` potwierdza kodowanie odpowiedzi dla danego żądania. Porównaj odpowiedź z CDN i serwera źródłowego, ponieważ przeglądarka może otrzymać inną reprezentację niż ta zwrócona przez origin.

W Chrome lub Edge otwórz DevTools klawiszem F12, wybierz kartę Network, odśwież stronę i kliknij odpowiedź HTML, CSS lub JavaScript. W Headers sprawdź `Accept-Encoding` w Request Headers oraz `Content-Encoding`, `Content-Type`, `Vary`, `Cache-Control` i ewentualne `Age` lub nagłówek cache dostawcy w Response Headers. W kolumnie Size porównaj rozmiar przesłany z rozmiarem zasobu, jeśli przeglądarka pokazuje obie wartości.

`Content-Encoding` może zawierać więcej niż jedno kodowanie, jeśli zastosowano je kolejno. W zwykłej konfiguracji Gzip i Brotli są jednak alternatywami i typowo dla jednej odpowiedzi zobaczysz jedno z nich. Brak `Content-Encoding` nie dowodzi sam w sobie błędnej konfiguracji: żądanie mogło nie akceptować kompresji, odpowiedź mogła być za mała albo wyłączona z reguły.

Jeśli nie widzisz kompresji, porównaj odpowiedź z CDN i originem. Origin to serwer źródłowy, do którego CDN przekazuje żądanie. Gdy origin zwraca zakodowaną odpowiedź, a CDN nie, sprawdź reguły transformacji i cache; gdy obie warstwy zwracają odpowiedź bez kompresji, zweryfikuj konfigurację serwera lub ograniczenia hostingu.

Na Nginx Gzip włącza dyrektywa `gzip on`, a dodatkowe typy MIME określa `gzip_types`; Apache udostępnia kompresję Gzip przez moduł `mod_deflate`. Przed zmianą zrób kopię konfiguracji i sprawdź, czy hosting lub CDN nie kompresuje już tych odpowiedzi.

Przykładowy zakres konfiguracji Nginx:

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

`gzip_min_length` określa minimalną długość odpowiedzi na podstawie `Content-Length`, a `gzip_comp_level` przyjmuje poziomy od 1 do 9. Wyższy poziom może zmniejszyć transfer, ale zwiększyć pracę CPU. Nginx domyślnie obejmuje Gzip typ `text/html`; `gzip_types` dodaje pozostałe typy MIME. Typ `text/javascript` jest w przykładzie, ponieważ serwer może używać go do odpowiedzi JavaScript. Dokumentacja Nginx opisuje dyrektywy modułu Gzip.

Przykład dla Apache, jeśli odpowiedzi używają wskazanych typów MIME:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/css text/javascript application/javascript application/json application/xml image/svg+xml
</IfModule>

Apache wymaga aktywnego `mod_deflate`, a filtr zależy od typu MIME odpowiedzi. Przed wdrożeniem sprawdź nagłówek `Content-Type` rzeczywistych plików i dostosuj listę typów. Zmiana w `.htaccess` zadziała tylko wtedy, gdy hosting zezwala na tę dyrektywę. Dokumentacja Apache opisuje `mod_deflate` oraz filtrowanie według typu MIME.

Przykłady dotyczą Gzip i nie włączają Brotli. Nginx potrzebuje dostępnego modułu Brotli lub wsparcia pakietu, a Apache i hosting muszą udostępniać odpowiadającą mu konfigurację. Przed przeładowaniem sprawdź składnię: dla Nginx użyj `nginx -t`, dla Apache `apachectl configtest` albo polecenia wskazanego przez hosting. Przeładuj serwer dopiero po poprawnym teście.

W WordPressie kompresję odpowiedzi najczęściej ustawia się na serwerze lub CDN, natomiast wtyczka cache może sterować własnymi plikami i regułami. Nie aktywuj tej samej funkcji niezależnie w kilku warstwach bez sprawdzenia łańcucha odpowiedzi.

Sprawdź po kolei:

1. Panel hostingu: znajdź ustawienie Gzip lub Brotli i dokumentację używanego serwera WWW.
2. Wtyczkę cache: ustal, czy kompresuje HTML, czy tylko wygenerowane pliki CSS i JavaScript.
3. CDN: sprawdź reguły kompresji oraz typy MIME objęte regułą.
4. Odpowiedź z przeglądarki: po wyczyszczeniu właściwego cache potwierdź `Content-Encoding` i `Content-Type`.

Cloudflare opisuje dostarczanie treści tekstowych z użyciem Gzip, Brotli lub innych obsługiwanych kodowań, zależnie od nagłówka `Accept-Encoding` klienta. Reguły kompresji mogą określać preferowane algorytmy na podstawie typu treści i rozszerzenia pliku. Jeśli CDN zmienia odpowiedź lub przechowuje kilka jej wersji, sprawdź obsługę `Vary` i cache.

Z naszych wdrożeń wynika, że częstym źródłem rozbieżności jest wtyczka, która serwuje przygotowany plik `.gz`, podczas gdy serwer lub CDN kompresuje odpowiedź na żądanie. Porównaj URL pliku i nagłówki na każdej warstwie, zanim wyłączysz jedną z nich.

Efekt kompresji mierz na tych samych adresach, typach plików i warunkach cache przed zmianą oraz po niej. Mniejszy transfer nie musi oznaczać krótszego czasu odpowiedzi, jeśli kompresja nadmiernie obciąża CPU albo opóźnia wygenerowanie strony.

Tabela wskazuje, co porównywać po wdrożeniu. Dla wiarygodnego wyniku zachowaj ten sam URL, typ żądania, stan cache i klienta testowego.

Wniosek: utrzymaj zmianę, gdy transfer spada, a czas odpowiedzi i obciążenie pozostają akceptowalne dla danego ruchu.

Podwójna kompresja może wystąpić, gdy warstwa pośrednia ponownie koduje odpowiedź już skompresowaną. Sprawdzaj nagłówki na każdym przejściu między przeglądarką, CDN i originem; sam wpis w konfiguracji WordPressa nie potwierdza, co otrzymał klient. Błędny `Content-Type` może wykluczyć odpowiedź z reguły MIME, a nieodświeżony cache może nadal serwować poprzedni wariant.

Wybór zależy od obsługi Brotli, zapasu CPU i tego, czy CDN przejmuje kompresję odpowiedzi. Gzip jest praktycznym wyborem, gdy serwer go obsługuje, a Brotli warto rozważyć, gdy konkretna warstwa prawidłowo negocjuje kodowanie i rozdziela warianty cache.

Dla statycznych plików można rozważyć przygotowanie skompresowanych wariantów, jeśli serwer potrafi je bezpiecznie serwować. Dynamiczny HTML jest kompresowany na żądanie, więc znaczenie ma koszt obliczeń podczas generowania odpowiedzi. Dobierz poziom pomiarem na kopii środowiska, bo wynik zależy od serwera i rodzaju treści.

Tabela pokazuje kierunek decyzji dla typowych warunków serwera.

Wniosek: przypisz kompresję do jednej kontrolowanej warstwy i porównaj transfer z kosztem serwera. Jeśli prowadzisz sklep i potrzebujesz wykonawcy, optymalizacja szybkości sklepu WooCommerce obejmuje ocenę kompresji w kontekście całej strony.

Bezpieczne wdrożenie wymaga kopii konfiguracji, testu składni, pomiaru i gotowego sposobu cofnięcia zmiany. Pracuj na środowisku testowym, jeśli modyfikujesz reguły serwera lub globalną konfigurację CDN.

1. Zapisz stan początkowy nagłówków, transferu, cache i obciążenia CPU.
2. Wybierz jedną warstwę kompresji i sprawdź faktyczne typy MIME.
3. Zrób kopię konfiguracji, wprowadź zmianę i uruchom test składni serwera.
4. Sprawdź odpowiedź dla klienta obsługującego Gzip i Brotli oraz dla żądania bez kompresji.
5. Wyczyść właściwy cache i powtórz testy z tabeli pomiarów po wdrożeniu.
6. Cofnij zmianę, jeśli odpowiedzi zwracają błędy, cache miesza warianty albo obciążenie przekracza ustalony limit.

Kompresja HTTP nie zmniejszy kosztu dużych skryptów. Sprawdź też metody minifikacji JavaScript w WordPressie oraz kolejność prac opisaną w poradniku jak przyspieszyć WordPress.

• EWWW Image Optimizer w WordPressie: jak skonfigurować i sprawdzić optymalizację obrazów
• Cloudflare - co to jest, jak działa i kiedy przydaje się firmie
• Optymalizacja stron z dynamicznymi tabelami danych pod szybkość i SEO
• Jak skonfigurować DNS dla domeny i sprawdzić, czy działa poprawnie
• Tailwind CSS toast: jak wdrożyć powiadomienia, które są czytelne i dostępne