Kompresja HTTP według typu pliku: co mierzyć

Kompresja HTTP zmniejsza treść odpowiedzi przesyłaną przez sieć. Opłacalność gzip, Brotli lub zstd zależy od konkretnej zawartości, poziomu kompresji i kosztu przetwarzania. Samo rozszerzenie pliku nie daje wiarygodnej odpowiedzi.

Najpierw tekst, osobno formaty już skompresowane

HTML, CSS, JavaScript, JSON, XML i SVG często dobrze nadają się do kompresji. Powtarzające się ciągi znaków i inne wzorce statystyczne umożliwiają krótszy zapis. Minifikacja usuwa białe znaki lub skraca nazwy, ale powtarzalne słowa kluczowe i struktury pozostają. Zminifikowany JavaScript nadal może znacznie zmniejszyć rozmiar. JSON również nie musi składać się z niepowtarzalnych wartości.

JPEG, PNG, WebP i AVIF stosują już kompresję. WOFF2 wykorzystuje przekształcenia właściwe danym fontów oraz Brotli. Dodatkowe kodowanie HTTP często daje niewielką korzyść, ale zależnie od pliku może jeszcze oszczędzić bajty albo zwiększyć rozmiar. Odpowiedź bez dodatkowej kompresji dowodzi decyzji serwera, a nie wyniku rzeczywiście przeprowadzonej ponownej kompresji.

SVG jest tekstem XML mimo funkcji obrazu. ICO to kontener, który może zawierać dane bitmapowe lub już skompresowane obrazy PNG. Ani zasada „każdy ICO jest nieskompresowany”, ani „każdy obraz ma już optymalną kompresję” nie jest poprawna.

Brak uniwersalnej granicy stu bajtów

Małe odpowiedzi również mogą zmniejszyć rozmiar. Lokalny test z 25 października 2026 r. obejmował dokładnie 80 znaków ASCII a. gzip na poziomie 6 dał 24 bajty, Brotli na poziomie 5 dał 10 bajtów, a zstd na poziomie 3 dał 21 bajtów. Trzy znaki wejściowe abc zwiększyły natomiast rozmiar do 23, 7 i 16 bajtów. Wszystkie sześć wyników zdekodowano i porównano bajt po bajcie z danymi wejściowymi.

To sztuczne przykłady zależności od zawartości, a nie pomiar witryn lub czasu ładowania. Implementacje formatów i ustawienia mogą zmieniać wyniki. Minimalny rozmiar w konfiguracji serwera jest kompromisem eksploatacyjnym, a nie matematyczną granicą podatności na kompresję.

Narzut formatów także jest różny: gzip zawiera sumę kontrolną, zwykły strumień Brotli nie zawiera sumy kontrolnej, a suma kontrolna treści w zstd jest opcjonalna. Ogólne wyjaśnienie odwołujące się do nagłówka i sumy kontrolnej w każdym formacie byłoby więc błędne.

Między wariantami musi pozostać identyczna treść

1. Dla każdego wariantu potrzebny jest ten sam końcowy URL zasobu, istotne warunki żądania i okres pomiaru. Treść dynamiczna może zmienić się pomiędzy pobraniami.
2. Kontrola obejmuje status HTTP, końcowy typ treści i faktyczne Content-Encoding. Oferta br nie wymusza odpowiedzi Brotli; nawet status 200 może towarzyszyć stronie blokady.
3. Pełne odpowiedzi wymagają dekodowania i porównania bajt po bajcie lub za pomocą odpowiedniego skrótu. Różne lub ucięte treści nie nadają się do porównania rozmiarów.
4. Przy identycznej treści liczba zakodowanych bajtów odpowiedzi jest dzielona przez liczbę bajtów treści bez kodowania. Przykładowo 20 KiB ze 100 KiB oznacza 20 procent pozostałego rozmiaru albo 80 procent oszczędności.
5. Wnioski o szybkości lub koszcie CPU wymagają powtórzeń i oddzielnych pomiarów czasu. Wcześniej skompresowane pliki statyczne i kompresja dynamiczna mają różne koszty.

size_download w curl mierzy pobrane bajty danych, a nie pełny koszt sieciowy z nagłówkami HTTP, TLS i narzutem pakietów. Przy --compressed zapisany plik może być już zdekodowany; rozmiar pliku jest wtedy inną miarą. Lokalna wersja curl musi obsługiwać oferowane kodowanie.

Warianty pamięci podręcznej i walidatory

Gdy wybór reprezentacji zależy od Accept-Encoding, nagłówek Vary: Accept-Encoding opisuje ten wybór dla pamięci podręcznych. Kontrola obejmuje odpowiednie odpowiedzi zakodowane i niezakodowane. Brak nagłówka może przyczyniać się do błędnego wyboru ponownie używanej reprezentacji, ale sam w sobie nie dowodzi uszkodzonej strony. Znaczenie mają również zasady przechowywania i pozostała konfiguracja pamięci podręcznej.

ETag to oznaczenie wersji przesyłane w odpowiedzi serwera. Różne zakodowane ciągi bajtów wymagają różnych silnych ETagów. Wspólny słaby walidator z prefiksem W/ może oznaczać warianty o tej samej treści, na przykład skompresowaną i nieskompresowaną wersję tej samej strony, ale nie zastępuje kontroli treści ani oceny warunków zastosowania. Różne wartości ETag same w sobie nie dowodzą poprawnej implementacji.

Co rzeczywiście pokazuje narzędzie

Narzędzie do kontroli negocjacji kompresji pobiera zasób kolejno z identity, gzip, br, zstd oraz stałą kombinacją. Wariant opisany jako przeglądarka jest żądaniem curl z ofertą gzip, deflate, br, zstd, a nie pomiarem rzeczywistej przeglądarki ani uniwersalnym nagłówkiem przeglądarek.

Obecna wersja zgłasza różnice zdekodowanej treści, ale nadal oblicza proporcje rozmiarów. Limit zdekodowanej odpowiedzi wynosi 3 MiB. Takie różnice, ucięte odpowiedzi i strony błędów unieważniają porównanie. Ocena Vary obejmuje tylko jeden zakodowany wariant, a klasyfikacja typów nie analizuje zawartości plików. Narzędzie dostarcza wskazówek, a nie kompletnego potwierdzenia poprawności konfiguracji serwera.