Sprawdzanie kompresji

Sprawdzanie kompresji gzip i Brotli: jak czytać wynik

Narzędzie dwukrotnie pobiera podany adres. Za pierwszym razem zachowuje się jak przeglądarka akceptująca skompresowaną odpowiedź: w nagłówku Accept-Encoding wymienia obsługiwane algorytmy, a serwer wybiera jeden. Za drugim razem wysyła Accept-Encoding: identity, czyli prosi o odpowiedź bez kompresji. Z porównania wynikają trzy liczby: rozmiar bez kompresji, liczba bajtów faktycznie przesłanych i procent oszczędności.

• Etykieta algorytmu (GZIP, Brotli lub Deflate) to wartość, którą serwer wpisał w Content-Encoding. Świeci się tylko jedna, bo odpowiedź zawsze jest kodowana jednym sposobem. Jeśli serwer obsługuje gzip i Brotli, zwykle wybierze Brotli, a etykieta gzip zostanie szara — to normalne.
• Oszczędność. HTML zwykle zmniejsza się o 70–90%. Jeśli kompresja jest włączona, a oszczędność poniżej 30%, strona jest pewnie bardzo mała albo kompresowana na niskim poziomie.
• Żadna etykieta się nie świeci, a rozmiar „z kompresją” jest dużo mniejszy. Najpewniej serwer odpowiedział algorytmem zstd, który nie ma osobnej etykiety — tak robi m.in. Cloudflare. Potwierdź to przez curl (polecenia niżej).

Sprawdzany jest tylko dokument pod podanym adresem. Aby upewnić się, że kompresowane są też CSS, JS i SVG, wpisz bezpośredni link do pliku.

Gzip, Brotli czy zstd

Kompresuj formaty tekstowe: HTML, CSS, JS, JSON, XML, SVG, czcionki TTF/OTF. JPEG, PNG, WebP, AVIF, MP4 i WOFF2 są już skompresowane — ponowna kompresja tylko obciąża procesor.

Jak włączyć kompresję

nginx: gzip

gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_vary on;
gzip_proxied any;
gzip_types text/css application/javascript application/json
           application/xml image/svg+xml font/ttf font/otf;

text/html nie trzeba dopisywać — jest kompresowany zawsze. gzip_vary on dodaje nagłówek Vary: Accept-Encoding, dzięki czemu proxy i CDN nie podadzą skompresowanej kopii klientowi, który jej nie obsługuje.

nginx: Brotli

Brotli nie ma w standardowym nginx — potrzebny jest moduł ngx_brotli. Część dystrybucji ma go jako gotowy pakiet; w przeciwnym razie kompiluje się go jako moduł dynamiczny pod posiadaną wersję nginx.

load_module modules/ngx_http_brotli_filter_module.so;
load_module modules/ngx_http_brotli_static_module.so;

brotli on;
brotli_comp_level 5;
brotli_static on;
brotli_types text/css application/javascript application/json
             application/xml image/svg+xml font/ttf font/otf;

brotli_static on serwuje gotowe pliki .br (np. app.js.br skompresowany na poziomie 11 podczas budowania), a dynamiczny HTML jest kompresowany w locie na poziomie 4–6. Gzip zostaw włączony dla klientów bez Brotli.

Apache i .htaccess

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

mod_brotli jest dostępny od Apache 2.4.26. Mimo nazwy mod_deflate serwuje gzip. Na hostingu współdzielonym moduły bywają wyłączone — wtedy kompresję włącza się w panelu (np. DirectAdmin, cPanel) albo przez pomoc techniczną.

Cloudflare i inne CDN

Cloudflare sam kompresuje odpowiedzi tekstowe dla odwiedzających (gzip, Brotli, zstd); szczegóły ustawisz w Compression Rules. Pamiętaj, że test widzi odpowiedź CDN, a nie Twojego serwera — połączenie serwer → CDN może pozostać nieskompresowane. Aby sprawdzić sam serwer, odpytaj go bezpośrednio.

WordPress i kreatory stron

W WordPressie lepiej włączyć kompresję na serwerze niż wtyczką: wtyczki cache zwykle tylko dopisują reguły do .htaccess, których nginx nie czyta. Na platformach typu Shoper czy Wix kompresją zarządza dostawca.

Test Brotli i gzip przez curl

Aby zobaczyć, co serwer zwraca dla konkretnego algorytmu, wyślij zapytanie GET (niektóre serwery na HEAD odpowiadają bez kompresji):

curl -s -o /dev/null -D - -H 'Accept-Encoding: br' https://example.com/ | grep -i content-encoding
curl -s -o /dev/null -D - -H 'Accept-Encoding: gzip' https://example.com/ | grep -i content-encoding
curl -s -o /dev/null -D - -H 'Accept-Encoding: zstd' https://example.com/ | grep -i content-encoding

Liczbę przesłanych bajtów pokaże curl -s -o /dev/null -H 'Accept-Encoding: br' -w '%{size_download}\n' https://example.com/; bez nagłówka dostaniesz rozmiar nieskompresowany. W przeglądarce to samo widać w DevTools → Network: kolumna Content-Encoding i różnica między rozmiarem przesłanym a rozmiarem zasobu.

Wstępna kompresja plików statycznych

CSS, JS i SVG lepiej skompresować raz, podczas budowania, na najwyższym poziomie, niż przy każdym żądaniu. Obok oryginałów odkłada się pliki .br i .gz, a serwer (brotli_static on i gzip_static on w nginx) podaje gotowy plik klientom, które go obsługują:

brotli -q 11 -k dist/app.js      # utworzy dist/app.js.br
gzip -9 -k dist/app.js           # utworzy dist/app.js.gz
zstd -19 -k dist/app.js          # utworzy dist/app.js.zst

Flaga -k zachowuje oryginał dla klientów bez obsługi kompresji. W bundlerach robią to wtyczki kompresji (są dla Vite i webpacka). Skompresowane kopie odbudowuj razem z oryginałem: nieaktualny .br obok nowego app.js to typowa przyczyna sytuacji „w jednej przeglądarce działa, w innej nie”.

Co kompresja daje dla SEO: mniej bajtów to szybciej dostarczony HTML i wcześniejsze wykrycie CSS oraz obrazu z pierwszego ekranu, co bezpośrednio skraca LCP w wolnych sieciach komórkowych. Googlebot również prosi o skompresowane odpowiedzi, więc serwer szybciej mu je podaje.

Najczęstsze problemy

• Kompresja tylko dla części typów. HTML jest kompresowany, a JS i CSS nie, bo ich typów MIME brakuje w gzip_types. Sprawdź bezpośredni link do dużego skryptu.
• Podwójna kompresja. Aplikacja (np. PHP z zlib.output_compression) kompresuje odpowiedź, a serwer próbuje zrobić to ponownie. Kompresuj w jednym miejscu — najlepiej na serwerze WWW.
• Brak Vary: Accept-Encoding. Proxy z cache może podać skompresowaną kopię klientowi bez obsługi. Wszystkie nagłówki odpowiedzi zobaczysz w sprawdzaniu nagłówków HTTP.
• Za wysoki poziom w locie. Brotli 11 lub gzip 9 dla stron dynamicznych wydłuża czas odpowiedzi serwera bardziej, niż oszczędza na transferze.

Kompresja to jeden z najtańszych sposobów na szybsze ładowanie: mniej bajtów oznacza, że HTML dociera szybciej, a renderowanie zaczyna się wcześniej. Pełny obraz da test szybkości strony, a wersję protokołu sprawdzisz w teście HTTP/2.