Kompresja Gzip i Brotli tnie 70-85% wagi HTML, CSS i JS. Jak sprawdzić, czy działa, jak ją włączyć na serwerze i czego nie kompresować - z liczbami z wdrożeń.
Gzip i Brotli to metody kompresji HTTP: serwer pakuje pliki tekstowe strony (HTML, CSS, JavaScript) przed wysłaniem, a przeglądarka rozpakowuje je u siebie. Typowy zysk to 70-85% mniej danych do przesłania, a włączenie kompresji na dobrym hostingu sprowadza się do jednego przełącznika - albo, jak u nas, jest domyślne.
W tym tekście wyjaśniamy różnicę między Gzipem a Brotli, co kompresować (a czego nie, żeby nie palić CPU), jak w 30 sekund sprawdzić, czy Twoja strona kompresuje, jak włączyć kompresję na różnych serwerach i ile to realnie daje - na liczbach z naszych wdrożeń.
Zanim serwer wyśle przeglądarce HTML, CSS czy skrypt, może go spakować - jak ZIP, tylko w locie. Przeglądarka rozpakowuje po swojej stronie. Tekstowe pliki kompresują się znakomicie: typowy HTML chudnie o 70-85%, CSS i JS podobnie. Mniej bajtów = szybszy transfer, szczególnie na telefonach - a kosztuje to jeden nagłówek. To najtańsza optymalizacja w całym katalogu z pillara Szybka strona WWW.
| Cecha | Gzip | Brotli |
|---|---|---|
| Rozmiar po kompresji (tekst) | dobry | lepszy o ~15-20% |
| Wsparcie przeglądarek | uniwersalne | wszystkie współczesne |
| Koszt CPU przy kompresji w locie | niski | niski-średni (zależnie od poziomu) |
| Kompresja wstępna (statyczne pliki) | możliwa | najlepszy scenariusz (najwyższy poziom bez kosztu w locie) |
Na LiteSpeed (nasz standard) Brotli jest dostępny od ręki; to jeden z powodów, dla których w testach wygrywa z klasycznym Apache - więcej w tekście o technologiach hostingu.
Przykład z naszych wdrożeń: HTML strony głównej 96 KB → 14 KB po Brotli; arkusz CSS motywu 340 KB → 42 KB. Na LTE to różnica odczuwalna gołym okiem, a serwer przy okazji wypycha kilkukrotnie mniej danych. Za darmo. Sprawdź swoją stronę testem szybkości - pokazujemy wagę strony przed i po kompresji.
Pamiętaj o proporcjach: kompresja tnie pliki tekstowe, ale na większości stron najwięcej ważą obrazy - kompletną kolejność odchudzania znajdziesz w przewodniku strona wolno się ładuje.
Przy dzisiejszych procesorach koszt jest pomijalny wobec zysku na transferze, a pliki statyczne serwer może skompresować raz i trzymać gotowe (tzw. kompresja wstępna). Problemem bywa tylko wymuszanie najwyższego poziomu Brotli dla treści generowanych w locie - domyślne ustawienia serwerów są rozsądnie wyważone.
Oba: Brotli jako preferowany, Gzip jako zapas dla starszych klientów. Serwer i przeglądarka same uzgodnią najlepszą wspólną metodę, więc taka konfiguracja nigdy nie działa na minus.
Tak - kompresji podlega odpowiedź HTTP, niezależnie od tego, czy HTML wygenerował WordPress, sklep czy plik statyczny. WordPress niczego nie musi „umieć"; wystarczy włączona kompresja na serwerze lub we wtyczce cache.
Najczęściej: cache serwuje starą, nieskompresowaną kopię (wyczyść cache), kompresji podlega HTML, ale nie CSS/JS (sprawdź typy w konfiguracji), albo zasób wskazywany przez PSI pochodzi z zewnętrznej domeny (skrypty firm trzecich - na ich kompresję nie masz wpływu).
Nie - JPG, PNG i WebP są już skompresowane wewnętrznie; kolejna warstwa nic nie daje, a zużywa CPU. Obrazy optymalizuje się zmianą formatu (WebP/AVIF), wymiarów i jakości - to osobny, zwykle największy rezerwuar oszczędności na stronie.
Wszystkie poradniki z kategorii: Szybkość i wydajność