Dwa narzędzia, dwa wyniki. Które kłamie o kompresji

👁 117 przeczytań

Raport z audytu twierdził, że serwer nie kompresuje odpowiedzi. Sprawdzenie bezpośrednie pokazało, że serwer wysyła br i zstd, a na wyraźną prośbę o gzip oddaje stronę główną w 71 306 bajtach zamiast 289 394 nieskompresowanych. Nagłówki wygasania też były na miejscu, z max-age 31557600 - czyli dokładnie to, czego raport nie zobaczył.

Co dokładnie pokazał raport, a co serwer

Raport miał jedną pozycję na czerwono: brak kompresji odpowiedzi. Bez szczegółów, bez informacji o tym, jakie kodowania klient zadeklarował. Do tego zero uwag o nagłówkach wygasania - co samo w sobie było dziwne, bo nagłówki wygasania na tym serwerze są ustawione z max-age=31557600, czyli na rok. Jeśli narzędzie poprawnie odczytało cache, ale nie odczytało kompresji, to albo serwer ma bardzo selektywną konfigurację, albo pytanie było zadane inaczej niż myślałem.

Sprawdzenie bezpośrednie rozstrzygnęło sprawę. Serwer negocjuje br i zstd. Przy jawnym żądaniu gzip strona główna przyjeżdża w 71 306 bajtach. Ta sama strona bez żadnej kompresji to 289 394 bajty. Czyli kompresja działa, i to nie tylko w wersji legacy.

Różnica 289 394 do 71 306 bajtów to spadek do jednej czwartej pierwotnej wagi. Dla użytkownika na wolnym łączu to sekundy, nie milisekundy. Trudno uznać taki efekt za „brak kompresji”.

Dlaczego gzip brotli test daje różne wyniki w różnych narzędziach

Kompresja HTTP jest negocjowana. Klient wysyła Accept-Encoding z listą kodowań, które umie rozpakować, serwer wybiera jedno z nich i odpowiada nagłówkiem Content-Encoding. Jeżeli listy się nie przecinają, serwer wysyła treść surową - i robi to poprawnie, zgodnie ze specyfikacją.

Narzędzia audytowe to zwykli klienci HTTP. Niektóre używają pełnego silnika przeglądarkowego i deklarują wszystko, co przeglądarka. Inne używają prostego klienta z zaszytą listą kodowań, która nie była aktualizowana od lat. Brotli ma już dobre kilka lat, zstd w kontekście HTTP jest nowszy - i to właśnie on najczęściej wypada z takich zaszytych list.

Mechanizm jest prosty:

1. Narzędzie wysyła żądanie z Accept-Encoding: gzip, deflate albo w ogóle bez tego nagłówka.
2. Serwer skonfigurowany pod br i zstd nie ma dopasowania albo dostaje pustą deklarację.
3. Serwer odpowiada bez Content-Encoding.
4. Narzędzie widzi brak nagłówka i raportuje brak kompresji.

Nikt tu nie kłamie w złej wierze. Narzędzie raportuje to, co dostało. Problem jest w tym, że komunikat brzmi jak diagnoza serwera, a jest opisem jednego konkretnego żądania.

Pingdom gtmetrix różnice - czego się z nich dowiesz, a czego nie

Moja opinia, oparta na tym jednym pomiarze i na latach patrzenia w takie raporty: narzędzia do syntetycznego testowania wydajności są dobre w mierzeniu czasów i w wyłapywaniu ciężkich zasobów, a słabe w ocenie konfiguracji serwera. Czas do pierwszego bajtu, waga transferu, kolejność ładowania - to mierzą sensownie. Ale gdy raport wypowiada się o tym, co serwer „obsługuje” albo „ma włączone”, opiera się na wnioskowaniu z jednego żądania wysłanego własnym klientem.

Stąd rozbieżności między narzędziami przy tej samej stronie. Jedno pokazuje kompresję na zielono, drugie na czerwono, a serwer przez cały czas robi to samo. Różni się tylko to, o co go poproszono. To nie jest błąd konkretnego serwisu - to konsekwencja architektury negocjacji treści w HTTP.

Drugi element tego samego wzorca: nagłówek Vary. Serwer, który negocjuje kodowanie, powinien wysyłać Vary: Accept-Encoding, żeby pośredniki nie podawały skompresowanej odpowiedzi klientowi, który jej nie rozumie. Narzędzia rzadko o tym mówią, a bez tego nagłówka można zobaczyć bardzo dziwne wyniki na losowych pomiarach - raz skompresowane, raz nie, w zależności od tego, co akurat leży w cache CDN.

Kiedy ostrzeżenie o kompresji strony jest prawdziwe

Nie każdy taki alert to fałszywy pozytyw. Warto go potraktować poważnie, jeśli:

• ręczne żądanie z Accept-Encoding: gzip też zwraca treść bez Content-Encoding;
• kompresja działa na HTML, ale nie na CSS, JS czy JSON - typowy efekt zbyt wąskiej listy typów MIME w konfiguracji;
• pliki poniżej progu minimalnej długości nie są kompresowane, a próg ustawiono absurdalnie wysoko;
• przed serwerem stoi proxy albo CDN, które rozpakowuje odpowiedź i nie pakuje jej ponownie.

W moim przypadku żaden z tych warunków nie zachodził. Trzy kodowania, sensowny rozmiar wyjściowy, poprawne nagłówki wygasania. Zostawiłem konfigurację bez zmian.

Jak to sprawdzić u siebie

1. Wyślij żądanie z jawnym nagłówkiem tylko dla gzip: curl -sI -H "Accept-Encoding: gzip" https://twojadomena.pl/. Szukaj w odpowiedzi Content-Encoding: gzip.
2. Powtórz z Accept-Encoding: br, a potem z Accept-Encoding: zstd. Zapisz, które kodowania serwer potwierdza nagłówkiem Content-Encoding.
3. Zmierz rozmiar skompresowany: curl -s -H "Accept-Encoding: gzip" -o /dev/null -w "%{size_download}n" https://twojadomena.pl/. U mnie wyszło 71 306.
4. Zmierz rozmiar surowy: to samo polecenie z Accept-Encoding: identity. U mnie 289 394. Podziel jedno przez drugie - jeśli iloraz jest bliski 1, kompresji naprawdę nie ma.
5. Sprawdź Vary: w odpowiedzi powinno być Vary: Accept-Encoding. Brak tego nagłówka przy aktywnej negocjacji to realny problem z pośrednikami.
6. Przy okazji odczytaj Cache-Control. U mnie na zasobach statycznych siedzi max-age=31557600, czyli rok - jeśli narzędzie tego nie zgłosiło, a widzisz to w nagłówku, masz kolejny dowód, że raport patrzył na coś innego.
7. Powtórz testy 1-3 dla pliku CSS i JS, nie tylko dla HTML. Selektywna kompresja po typach MIME to najczęstsza realna luka.
8. Jeśli używasz CDN, wykonaj cały zestaw dwa razy: raz na adresie CDN, raz bezpośrednio na origin. Rozbieżność wskazuje, gdzie ginie kompresja.

Całość zajmuje kilka minut i daje odpowiedź, której raport nie da: nie „czy w tym jednym żądaniu była kompresja”, ale „co ten serwer faktycznie umie”.