Kompresja gzip i Brotli: jak zmniejszyć wagę przesyłanych plików strony

Czym jest kompresja plików przesyłanych ze strony

Kompresja to sposób zapisania tych samych danych w mniejszej liczbie bajtów na czas przesyłania ich z serwera do przeglądarki. Serwer pakuje plik, wysyła go przez sieć, a przeglądarka rozpakowuje go i odtwarza dokładnie taką zawartość, jaka leżała na serwerze. Użytkownik niczego nie zauważa poza tym, że strona pobiera się krócej, zwłaszcza na telefonie przy słabszym zasięgu.

Dokumentacja MDN opisująca kompresję w protokole HTTP wyróżnia kilka poziomów. Pierwszy to kompresja wbudowana w format pliku, na przykład w zdjęcie JPEG. Drugi to kompresja całej odpowiedzi na drodze od serwera do przeglądarki i właśnie o niej mowa, gdy pada nazwa gzip albo Brotli.

Tekst nadaje się do pakowania wyjątkowo dobrze, ponieważ pełno w nim powtórzeń. W kodzie HTML te same znaczniki i nazwy klas wracają setki razy, w arkuszach stylów powtarzają się nazwy właściwości, a w skryptach nazwy funkcji. MDN podaje, że w tekście nadmiarowość sięga zwykle nawet 60%, a dla części dokumentów kompresja zmniejsza rozmiar nawet o 70%. Mechanizmu nie trzeba samodzielnie programować, bo przeglądarki i serwery mają go wbudowany. Wystarczy upewnić się, że serwer jest właściwie skonfigurowany.

Jak przeglądarka i serwer ustalają sposób kompresji

Uzgodnienie odbywa się za pomocą dwóch nagłówków, czyli krótkich informacji dołączanych do każdego żądania i każdej odpowiedzi. Przeglądarka wysyła nagłówek Accept-Encoding, w którym wymienia obsługiwane przez siebie algorytmy. Serwer wybiera jeden z nich, pakuje nim treść odpowiedzi i w nagłówku Content-Encoding informuje, którego użył. Według opisu nagłówka Accept-Encoding w MDN typowa współczesna przeglądarka zgłasza gotowość przyjęcia kilku formatów naraz.

Żądanie przeglądarki:
Accept-Encoding: gzip, deflate, br, zstd

Odpowiedź serwera:
Content-Type: text/html; charset=UTF-8
Content-Encoding: br
Vary: Accept-Encoding

Trzeci nagłówek z przykładu, Vary, ma znaczenie dla serwerów pośredniczących. MDN wyjaśnia, że skoro wersja odpowiedzi zależy od tego, co zgłosiła przeglądarka, serwer powinien dołączyć nagłówek Vary zawierający co najmniej wartość Accept-Encoding. Dzięki temu pamięć podręczna po drodze przechowuje osobno wersję spakowaną i niespakowaną. Jeżeli serwer nie pakuje odpowiedzi, nagłówka Content-Encoding po prostu w niej nie ma.

Czym różnią się gzip i Brotli

Gzip to starszy i najbardziej rozpowszechniony format, a Brotli to nowszy algorytm, który przy tym samym pliku zwykle daje mniejszy wynik, lecz potrzebuje na pakowanie więcej czasu. Oba są bezstratne i oba służą do tego samego, dlatego na jednej stronie stosuje się je równolegle: przeglądarka dostaje Brotli, gdy go obsługuje, a w pozostałych przypadkach gzip.

MDN w opisie nagłówka Content-Encoding wymienia więcej wartości niż te dwie. Gzip oznaczany jest słowem gzip, Brotli skrótem br, a obok nich istnieją między innymi deflate oraz Zstandard oznaczany jako zstd. Dokumentacja poświęcona kompresji w HTTP stwierdza jednak, że obecnie liczą się przede wszystkim dwa algorytmy: gzip jako najczęstszy i Brotli jako jego nowszy konkurent.

Różnicę w skuteczności dobrze pokazuje zestawienie z serwisu web.dev w tekście o optymalizacji kodowania i rozmiaru zasobów tekstowych. Popularna biblioteka JavaScript w wersji roboczej ważyła tam 1346 KiB. Po spakowaniu gzipem na najwyższym poziomie zostało z niej 329 KiB, czyli o 76% mniej, a po spakowaniu Brotli 256 KiB, czyli o 81% mniej. Ta sama biblioteka w wersji produkcyjnej, już odchudzonej, zmalała ze 173 KiB do 60 KiB po gzipie i do 53 KiB po Brotli. Autorzy podsumowują, że większe pliki tekstowe da się zmniejszyć o 70-90%, i zalecają wybierać Brotli wszędzie tam, gdzie jest to możliwe.

Poziomy kompresji i czas pakowania

Oba algorytmy mają regulowany poziom, czyli ustawienie decydujące o tym, ile pracy serwer włoży w pakowanie. Według web.dev gzip ma poziomy od 1 do 9, a Brotli od 0 do 11, przy czym najwyższa wartość daje najmniejszy plik. Im wyższy poziom, tym dłużej trwa pakowanie, dlatego nie zawsze opłaca się ustawiać maksimum.

Znaczenie ma to, kiedy plik jest pakowany. Przy kompresji dynamicznej serwer pakuje odpowiedź w chwili, gdy przychodzi żądanie, więc każda milisekunda pracy procesora wydłuża oczekiwanie użytkownika. Web.dev wskazuje, że w takim trybie najlepszy kompromis między wielkością pliku a szybkością dają zwykle ustawienia ze środka skali. Przy kompresji statycznej pliki są pakowane zawczasu, na przykład podczas wdrażania nowej wersji strony, więc można użyć najmocniejszych ustawień bez kosztu dla odwiedzającego.

Słownik MDN w haśle o kompresji Brotli dodaje ważne zastrzeżenie: ponieważ Brotli pakuje wolniej niż gzip, przy treściach, których nie da się zapisać w pamięci podręcznej, gzip bywa lepszym wyborem. Dotyczy to na przykład koszyka w sklepie, który serwer buduje od nowa dla każdej osoby. Ten sam słownik podaje, że Brotli działa w większości współczesnych przeglądarek, ale zaleca przewidzieć rozwiązanie zapasowe.

Które typy plików warto kompresować, a których nie

Kompresować warto wszystko, co jest tekstem, a pomijać to, co zostało już skompresowane na poziomie formatu. MDN ujmuje to jednym zaleceniem: kompresję należy włączyć dla wszystkich plików z wyjątkiem tych już spakowanych, takich jak obrazy, pliki dźwiękowe i filmy. Web.dev precyzuje, że gzip i Brotli najlepiej sprawdzają się przy zasobach tekstowych, czyli przy CSS, JavaScript i HTML.

Serwer rozpoznaje rodzaj pliku po typie MIME, czyli po etykiecie przesyłanej w nagłówku Content-Type, na przykład text/html albo text/css. W konfiguracji podaje się więc listę typów, które mają być pakowane. Dobrym punktem odniesienia jest otwarty zbiór wzorcowych konfiguracji serwerów, do którego odsyła dokumentacja Lighthouse. Jego plik z ustawieniami kompresji dla serwera Apache obejmuje między innymi dokumenty HTML, arkusze stylów, skrypty, dane JSON i XML, kanały RSS, grafikę wektorową SVG oraz ikony.

Dlaczego obrazów to nie dotyczy

Zdjęcia i grafiki rastrowe są skompresowane już w chwili zapisu, dlatego ponowne pakowanie nic nie daje. MDN wyjaśnia, że formaty takie jak PNG i GIF stosują kompresję bezstratną, JPEG stratną, a WebP może korzystać z obu. Druga kompresja nałożona na taki plik zazwyczaj nie przynosi zysku, a bywa wręcz szkodliwa: algorytm dokłada własne dane pomocnicze i plik potrafi urosnąć. To samo ostrzeżenie znajduje się w opisie nagłówka Content-Encoding, gdzie jako przykłady podano pliki zip i jpeg.

Wagę zdjęć zmniejsza się inaczej: przez dobór formatu, wymiarów i poziomu jakości, a także przez usunięcie zbędnych metadanych, które według web.dev potrafią zajmować dziesiątki kilobajtów w jednym pliku. Opisujemy to szerzej we wpisie obrazy na stronie a SEO.

Małe pliki i minifikacja

Bardzo małych plików zwykle się nie kompresuje. Web.dev podaje, że serwery często pomijają pliki poniżej pewnego progu, typowo czterech lub pięciu kilobajtów, ponieważ po spakowaniu mogłyby być większe niż przed. Brak nagłówka Content-Encoding przy maleńkim pliku nie powinien więc niepokoić.

Przed kompresją warto wykonać minifikację, czyli usunięcie z kodu znaków potrzebnych tylko człowiekowi: odstępów, wcięć, komentarzy. Web.dev podkreśla, że minifikacja nie jest algorytmem kompresji, lecz osobnym zabiegiem, a kompresja daje oszczędność dodatkową, która się z nią sumuje. W przykładzie z tego serwisu sam kod HTML skrócił się po minifikacji z 516 do 204 znaków.

Jak potwierdzić nagłówek Content-Encoding w narzędziach przeglądarki

Najpewniejszym sposobem jest otwarcie narzędzi deweloperskich w przeglądarce Chrome i odczytanie nagłówków odpowiedzi dla wybranego pliku. Jeżeli w sekcji nagłówków odpowiedzi widnieje content-encoding z wartością br albo gzip, plik dotarł spakowany. Jeżeli takiego nagłówka nie ma, serwer wysłał plik w pełnym rozmiarze.

Poniższa kolejność czynności pochodzi z dokumentacji Lighthouse poświęconej włączaniu kompresji tekstu, a nazwy kart podajemy w brzmieniu polskiej wersji przeglądarki.

1. Otwarcie narzędzi deweloperskich

   Na badanej stronie należy nacisnąć klawisze Control, Shift i J, a na komputerze Mac klawisze Command, Option i J.

2. Przejście do karty Sieć

   Karta Sieć pokazuje wszystkie pliki pobierane przez stronę. Po jej otwarciu trzeba odświeżyć stronę, aby lista wypełniła się żądaniami.

3. Wskazanie badanego pliku

   Na liście należy kliknąć wiersz z plikiem. Na początek najlepiej wskazać pierwszy wiersz, czyli sam dokument HTML, a potem największy arkusz stylów i największy skrypt.

4. Otwarcie karty Nagłówki

   Po kliknięciu wiersza otwiera się panel szczegółów. Karta Nagłówki zawiera osobne sekcje dla żądania i dla odpowiedzi.

5. Odczytanie sekcji Nagłówki odpowiedzi

   W sekcji Nagłówki odpowiedzi należy odszukać pozycję content-encoding. Wartość br oznacza Brotli, gzip oznacza gzip, a zstd format Zstandard.

Warto zajrzeć także do sekcji nagłówków żądania w tej samej karcie. Pozycja accept-encoding pokazuje, jakie formaty zgłosiła przeglądarka. Jeżeli jest wśród nich br, a serwer mimo to odpowiada gzipem, Brotli nie został na serwerze włączony albo nie obejmuje danego typu pliku.

Porównanie rozmiaru przed kompresją i po niej

Ta sama karta Sieć pozwala zobaczyć, ile bajtów faktycznie udało się zaoszczędzić. Dokumentacja Lighthouse opisuje, że po włączeniu w ustawieniach karty opcji dużych wierszy żądań w kolumnie Rozmiar pojawiają się dwie wartości: górna to rozmiar po kompresji, czyli to, co przeszło przez sieć, a dolna to rozmiar po rozpakowaniu. Jeśli obie liczby są niemal równe, plik nie był pakowany.

Podsumowanie dla całej strony znajduje się na dole karty Sieć. Web.dev opisuje, że widać tam liczbę żądań, łączny rozmiar przesłanych danych po kompresji oraz łączny rozmiar zasobów po rozpakowaniu. Sklep z Poznania, który ma kilka dużych skryptów i rozbudowany arkusz stylów, zobaczy w tym miejscu wyraźną różnicę, natomiast prosta wizytówka hydraulika z Łodzi zyska mniej, bo zwyczajnie ma mniej kodu do spakowania.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Co oznacza zalecenie włączenia kompresji tekstu w raporcie szybkości

Zalecenie to oznacza, że audyt znalazł na stronie pliki tekstowe wysłane bez kompresji i oszacował, ile bajtów dałoby się na nich zaoszczędzić. Nie jest to ocena treści ani wyglądu strony, tylko informacja o konfiguracji serwera, którą da się poprawić bez zmieniania czegokolwiek w samych podstronach.

Dokumentacja Lighthouse opisuje sposób działania tego audytu dość dokładnie. Narzędzie zbiera odpowiedzi o tekstowym typie zasobu, które nie mają nagłówka content-encoding z wartością br, gzip lub deflate. Każdą z nich pakuje na próbę gzipem i w ten sposób wylicza możliwą oszczędność. Odpowiedź nie jest zgłaszana, jeżeli jej pierwotny rozmiar nie przekracza 1,4 KiB albo jeżeli możliwa oszczędność jest mniejsza niż 10% pierwotnego rozmiaru. Podawane wartości są więc szacunkiem opartym na gzipie, a autorzy dodają, że Brotli mógłby dać jeszcze lepszy wynik. O samym narzędziu piszemy we wpisie Lighthouse: jak uruchomić audyt strony w Chrome.

Gdzie to zalecenie znaleźć obecnie

W nowszych wydaniach Lighthouse osobny audyt kompresji tekstu został włączony do szerszej statystyki dotyczącej opóźnienia żądania dokumentu. Informuje o tym ostrzeżenie na stronie dokumentacji. Opis tej statystyki, czyli Document request latency, wymienia trzy sytuacje, w których pierwsze żądanie dokumentu zostaje zgłoszone: żądanie nawigacji było przekierowane co najmniej raz, serwer odpowiadał dłużej niż 600 ms albo odpowiedź została wysłana bez kompresji.

Warto zwrócić uwagę na zakres. Ta statystyka ocenia sam dokument HTML, czyli pierwszy plik, od którego przeglądarka zaczyna budować stronę. Dopóki on nie dotrze, przeglądarka nie wie nawet, jakie style i skrypty ma pobrać. Pozostałe dwa warunki opisujemy osobno: czas odpowiedzi serwera we wpisie TTFB: czas odpowiedzi serwera, a sposób odczytywania całego raportu we wpisie PageSpeed Insights: jak czytać raport.

Jak włączyć kompresję na popularnych serwerach

Kompresję włącza się w konfiguracji oprogramowania serwera, a na hostingu współdzielonym często jednym przełącznikiem w panelu klienta. MDN wskazuje, gdzie szukać ustawień w trzech popularnych rozwiązaniach: w serwerze Apache odpowiada za to moduł mod_deflate, w serwerze nginx moduł ngx_http_gzip_module, a w serwerze IIS element konfiguracji o nazwie httpCompression. Dokumentacja Lighthouse dodaje ogólną zasadę: używać Brotli, gdy przeglądarka go obsługuje, a gzip traktować jako rozwiązanie zapasowe.

Zanim cokolwiek zostanie zmienione, warto wykonać pomiar opisany wcześniej. Z naszych obserwacji wynika, że na wielu hostingach kompresja jest włączona domyślnie i wystarczy potwierdzić ją w karcie Sieć. Jeżeli jej nie ma, pierwszym krokiem powinno być pytanie do dostawcy hostingu, czy obsługuje gzip i Brotli oraz jak je uruchomić dla danej domeny. O wyborze dostawcy piszemy we wpisie hosting a SEO.

Serwer Apache

Na serwerze Apache ustawienia można umieścić w głównej konfiguracji albo, jeśli hosting na to pozwala, w pliku .htaccess w katalogu strony. Wzorcowa konfiguracja, do której odsyła dokumentacja Lighthouse, korzysta z dyrektywy AddOutputFilterByType DEFLATE, po której wymienia się typy MIME przeznaczone do pakowania. Poniżej skrócony przykład zbudowany według tego wzoru.

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

Znacznik IfModule sprawia, że polecenia zadziałają tylko wtedy, gdy moduł jest na serwerze dostępny. Brotli na serwerze Apache obsługuje osobny moduł. Z praktyki agencji wiemy, że nie każdy hosting go udostępnia, dlatego jego dostępność najlepiej potwierdzić u dostawcy, zamiast dopisywać polecenia na próbę.

Serwer nginx

Na serwerze nginx kompresję ustawia się w pliku konfiguracyjnym serwera, do którego dostęp ma administrator, a nie w katalogu strony. Poniższy przykład pochodzi z naszej praktyki i pokazuje ogólną postać ustawień. Dokładne wartości należy uzgodnić z dokumentacją używanej wersji serwera.

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

Poszczególne wiersze odpowiadają zasadom omówionym wcześniej: włączenie kompresji, dołączanie nagłówka Vary, poziom ze środka skali, pominięcie najmniejszych plików i lista typów tekstowych.

Kompresja w WordPressie, sieci CDN i pamięci podręcznej

W WordPressie kompresji tekstu nie ustawia się w treści ani w motywie, lecz na serwerze. Dokumentacja Chrome mówi to wprost: w przypadku WordPressa kompresję tekstu należy włączyć w konfiguracji serwera WWW. Podręcznik administracji WordPressa w rozdziale o optymalizacji dodaje, że sposobów kompresowania plików i danych na serwerze jest kilka, a część wtyczek pamięci podręcznej potrafi zmniejszać i łączyć arkusze stylów oraz skrypty.

W praktyce właściciel strony na WordPressie albo sklepu na WooCommerce ma trzy drogi. Może poprosić o włączenie kompresji dostawcę hostingu, może skorzystać z wtyczki pamięci podręcznej, która dopisze odpowiednie polecenia do konfiguracji, albo może przekazać ruch przez sieć dostarczania treści, czyli CDN. Taka sieć to zespół serwerów w wielu miejscach, które podają pliki strony z punktu najbliższego odwiedzającemu. Podręcznik WordPressa zaznacza, że CDN potrafi znacząco odciążyć serwer i działa najskuteczniej razem z wtyczką pamięci podręcznej. Z naszych wdrożeń wynika, że sieci tego typu zwykle same pakują pliki tekstowe, także w formacie Brotli.

Przy pamięci podręcznej wraca nagłówek Vary. Jeżeli odpowiedź nie zawiera Vary z wartością Accept-Encoding, pamięć serwera pośredniczącego nie rozróżnia wersji spakowanej od niespakowanej. Dlatego po uruchomieniu kompresji warto sprawdzić w karcie Sieć nie tylko content-encoding, ale i ten nagłówek. Ustawienia czasu przechowywania plików omawiamy we wpisie o nagłówkach Cache-Control, a ich rodzaje we wpisie pamięć podręczna strony.

Typowe pomyłki przy włączaniu kompresji

Najczęstsza pomyłka polega na uznaniu sprawy za załatwioną po sprawdzeniu samej strony głównej. Kompresja bywa ustawiona tylko dla dokumentów HTML, podczas gdy arkusze stylów i skrypty, często znacznie cięższe, nadal wędrują w pełnym rozmiarze. Dlatego w karcie Sieć trzeba obejrzeć przynajmniej po jednym pliku każdego rodzaju, a nie tylko pierwszy wiersz listy.

Druga pomyłka to pakowanie wszystkiego bez wyjątku. Włączenie kompresji dla zdjęć, filmów i archiwów obciąża procesor, a nie zmniejsza plików, co wynika wprost z przytoczonych wcześniej zaleceń MDN. Lista typów w konfiguracji powinna obejmować tekst i nic poza nim.

Kolejna dotyczy poziomu kompresji. Ustawienie najwyższego poziomu Brotli dla stron budowanych przy każdym żądaniu wydłuża pracę serwera, a tym samym czas oczekiwania na odpowiedź. Najmocniejsze ustawienia mają sens przy plikach pakowanych zawczasu.

Mylące bywa też oczekiwanie, że serwer skompresuje odpowiedź zawsze. MDN zastrzega, że nawet przy wspólnie obsługiwanych algorytmach serwer może zrezygnować z pakowania, na przykład gdy dane są już skompresowane albo gdy jest przeciążony i nie ma wolnych zasobów. Jeżeli więc nagłówek content-encoding raz jest, a raz go nie ma, warto przyjrzeć się obciążeniu serwera, a nie tylko konfiguracji.

Ostatnia pomyłka to traktowanie kompresji jako lekarstwa na wszystko. Spakowanie kodu nie zastąpi usunięcia nieużywanych skryptów ani odchudzenia zdjęć. Kancelaria z Krakowa, której strona ładuje kilka ciężkich bibliotek tylko po to, by wyświetlić prosty formularz, zyska więcej na rezygnacji ze zbędnego kodu niż na zmianie gzipa na Brotli.

Kompresja a widoczność w Google

Kompresję warto traktować jako element porządku technicznego, a nie jako sposób na szybki awans w wynikach. Jej rola jest pośrednia: mniejsze pliki szybciej docierają do przeglądarki, co pomaga w krótszym wczytaniu strony i poprawia odczucia odwiedzających. Jak szybkość wiąże się z oceną strony, opisujemy we wpisach szybkość strony a pozycje w Google oraz Core Web Vitals: jak poprawić LCP, INP i CLS.

Kolejność działań i sytuacje, w których potrzebna jest pomoc

Całą pracę da się zamknąć w kilku krokach: pomiar, ustalenie, kto zarządza serwerem, włączenie kompresji dla typów tekstowych i ponowny pomiar. Większość właścicieli stron poradzi sobie z pierwszą i ostatnią czynnością samodzielnie, a środkowe wykona dostawca hostingu albo osoba opiekująca się stroną.

• Dokument HTML strony głównej i przykładowej podstrony ma nagłówek content-encoding z wartością br, gzip lub zstd.
• Największy arkusz stylów i największy skrypt także mają ten nagłówek.
• Pliki SVG, JSON i XML, w tym mapa witryny, są pakowane.
• Zdjęcia JPEG, PNG i WebP oraz filmy nie mają nagłówka content-encoding.
• Odpowiedzi zawierają nagłówek Vary z wartością Accept-Encoding.
• W kolumnie Rozmiar wartość po kompresji jest wyraźnie mniejsza od wartości po rozpakowaniu.
• Raport szybkości nie zgłasza już plików tekstowych wysłanych bez kompresji.
• Po zmianie konfiguracji strona, koszyk i formularze działają bez błędów.

Pomoc specjalisty przydaje się wtedy, gdy strona działa na własnym serwerze i nikt w firmie nie zna jego konfiguracji, gdy po włączeniu kompresji pojawiają się błędy wyświetlania albo gdy wyniki są różne dla różnych podstron i trudno wskazać przyczynę. Wsparcie jest też wskazane przy rozbudowanych sklepach, w których kompresja, pamięć podręczna i sieć CDN muszą współpracować.

Kompresja jest zwykle jednym z wielu punktów szerszego przeglądu. W ramach SEO technicznego sprawdzamy ją razem z czasem odpowiedzi serwera, pamięcią podręczną, wagą zdjęć i kodem strony, ponieważ dopiero zestawienie tych elementów pokazuje, co naprawdę spowalnia witrynę. Jeżeli nie wiadomo, od czego zacząć, punktem wyjścia bywa audyt SEO, który porządkuje zalecenia według wagi.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl