Po co kompresować pliki tekstowe?
Gdy przeglądarka otwiera stronę, pobiera między innymi dokument HTML, arkusze CSS i pliki JavaScript. Takie zasoby zawierają wiele powtarzających się fragmentów: nazw, znaczników, odstępów czy wzorców kodu. Kompresja pozwala przesłać je w mniejszej postaci, a przeglądarka rozpakowuje je przed użyciem. Dzięki temu można ograniczyć ilość danych pobieranych przez użytkownika, szczególnie gdy pliki tekstowe są duże lub połączenie jest wolniejsze.
Kompresja dotyczy przesyłanej odpowiedzi, nie rozmiaru pliku widocznego w edytorze. Dlatego przy ocenie efektu warto odróżnić rozmiar zasobu po rozpakowaniu od liczby bajtów pobranych przez sieć. Mniejszy transfer może pomóc w szybszym dostarczeniu zasobów, ale nie usunie opóźnień wynikających na przykład z długiego oczekiwania na odpowiedź serwera albo wykonywania dużej ilości JavaScriptu.
Czym różnią się Brotli i Gzip?
Gzip i Brotli to dwa sposoby kodowania odpowiedzi HTTP. Oba nadają się do zasobów tekstowych i są obsługiwane przez współczesne przeglądarki. Brotli często pozwala uzyskać mniejszy plik niż Gzip, lecz wynik zależy od zawartości zasobu i ustawień kompresji. Różnice nie należy więc oceniać wyłącznie po nazwie algorytmu: istotne są rzeczywiste rozmiary odpowiedzi i koszt ich przygotowania.
W przypadku plików statycznych, takich jak arkusz CSS zmieniany dopiero przy publikacji nowej wersji strony, serwer może przechowywać wcześniej skompresowaną kopię. Przy odpowiedziach generowanych na żądanie kompresja wykonywana w trakcie obsługi użytkownika zużywa zasoby serwera. Wysoki poziom kompresji nie zawsze będzie wtedy najlepszym wyborem. Gzip może też pełnić funkcję wariantu zapasowego, gdy klient nie obsługuje Brotli.
Przeglądarka informuje serwer o obsługiwanych metodach w nagłówku żądania Accept-Encoding. Serwer wybiera odpowiednią wersję i podaje zastosowaną metodę w nagłówku odpowiedzi Content-Encoding, na przykład br albo gzip. Jeśli po drodze działa pamięć podręczna, warto zadbać o prawidłowe rozróżnianie wariantów odpowiedzi; służy do tego między innymi nagłówek Vary: Accept-Encoding.
Które zasoby warto objąć kompresją?
Najpierw sprawdź HTML, CSS i JavaScript. W typowym sklepie internetowym będą to na przykład kod strony kategorii, wspólny arkusz stylów oraz skrypty odpowiedzialne za menu i koszyk. Kompresja może mieć sens również dla innych odpowiedzi tekstowych, takich jak JSON czy SVG, jeśli serwer je udostępnia i przeglądarka z nich korzysta. Nie zakładaj jednak, że wszystkie adresy są obsługiwane tak samo: pliki statyczne, strony generowane dynamicznie i odpowiedzi z zewnętrznych usług mogą mieć różne ustawienia.
Obrazy w formatach przeznaczonych do publikacji w sieci oraz inne pliki już skompresowane zwykle niewiele zyskują na dodatkowym użyciu Gzip lub Brotli. Dla nich większe znaczenie może mieć dobranie formatu, wymiarów i jakości do sposobu wyświetlania. Jeśli strona przesyła zbyt dużo nieużywanego kodu, samo włączenie kompresji również nie rozwiąże problemu. Warto równolegle ograniczać zbędne zasoby.
Jak samodzielnie sprawdzić konfigurację?
Otwórz narzędzia deweloperskie przeglądarki i przejdź do zakładki sieciowej. Odśwież stronę, wybierz dokument HTML, a następnie sprawdź nagłówki odpowiedzi. Obecność Content-Encoding: br wskazuje na Brotli, a Content-Encoding: gzip na Gzip. Powtórz kontrolę dla plików CSS i JavaScript. Porównaj też rozmiar przesłanych danych z rozmiarem zasobu po rozpakowaniu, jeśli narzędzie pokazuje obie wartości. Pamiętaj, że odpowiedź pobrana z lokalnej pamięci podręcznej może nie pokazywać zwykłego transferu sieciowego.
Krótka lista kontrolna obejmuje cztery pytania: czy ważne zasoby tekstowe są kompresowane, czy odpowiedzi mają właściwy Content-Encoding, czy pamięć podręczna rozróżnia warianty kodowania oraz czy rozmiar przesyłanych plików jest rozsądny po kompresji? Sprawdź kilka reprezentatywnych podstron, nie tylko stronę główną. Jeśli korzystasz z CDN lub serwera pośredniczącego, skontroluj odpowiedź widoczną dla przeglądarki, ponieważ może ona różnić się od odpowiedzi serwera źródłowego.
Co zrobić, gdy kompresja nie działa?
Zacznij od ustalenia, których odpowiedzi dotyczy problem. Brak kompresji jednego pliku nie oznacza, że nie działa ona w całym serwisie. Sprawdź typ zawartości odpowiedzi, ustawienia serwera lub CDN oraz to, czy testowany zasób rzeczywiście został pobrany z sieci. Przy plikach generowanych przez aplikację zweryfikuj konfigurację tej ścieżki osobno.
Po zmianie ustawień wykonaj ponowny test dla HTML, CSS i JavaScript, a także sprawdź, czy strona działa poprawnie. Nie traktuj samego włączenia Brotli jako celu: ważniejsze jest dostarczenie prawidłowej odpowiedzi bez niepotrzebnego transferu i nadmiernego obciążenia serwera. Kompresja jest jednym z elementów pracy nad szybkością i wygodą strony, obok ograniczania zbędnego kodu, odpowiedniego buforowania i kontroli działania witryny.
