Sprawdzanie Brotli

Wklej URL do tego darmowego Brotli Checker, żeby sprawdzić, czy serwer zwraca skompresowane zasoby. Nie musisz się rejestrować. Narzędzie szuka tokena br w nagłówkach HTTP.

Jak Brotli Checker odczytuje nagłówki

Wklejasz URL, a narzędzie wysyła żądanie HTTP z nagłówkiem Accept-Encoding ustawionym na gzip, deflate, br. Decyduje serwer. Jeśli obsługuje algorytm, zwróci Content-Encoding: br. Narzędzie parsuje ten nagłówek i podaje wynik. Sprawdza też faktyczny payload, żeby upewnić się, że serwer nie skłamał co do kodowania.

Brotli to RFC 7932. Używa predefiniowanego, 120-kilobajtowego słownika. Słownik zawiera popularne stringi HTTP i słowa kluczowe CSS. Ten współdzielony kontekst pozwala kompresować pliki tekstowe znacznie mocniej niż starsze metody. Dostajesz z powrotem surowe nagłówki, więc zweryfikujesz dokładny token. Sprawdza też magic bytes. Jeśli nagłówek mówi br, a payload to zwykły tekst, narzędzie zgłosi niezgodność.

Kiedy uruchomić test kompresji brotli

Potrzebujesz tego, gdy audyt Lighthouse narzeka na nieskompresowany tekst. Nowoczesne CDN-y to obsługują, ale źle skonfigurowane serwery origin często ucinają nagłówki. Możesz myśleć, że sieć edge sobie radzi, tylko po to, by odkryć, że origin wysyła surowy HTML. To całkowicie niweczy sens stawiania globalnej sieci dostarczania treści. Jeśli chcesz sprawdzić, czy strona używa brotli, po prostu wklej URL. Ten online Brotli Checker pozwoli przetestować zarówno edge, jak i origin bezpośrednio.

Przydaje się też przy migracji z gzip. Chcesz potwierdzić, że nowa konfiguracja faktycznie działa, zanim wypchniesz ją na produkcję. Pamiętaj tylko, że statyczne zasoby jak obrazki i wideo już są skompresowane. Narzędzie słusznie zgłosi, że te pliki nie używają kompresji tekstowej. Testuj tylko pliki HTML, CSS i JSON, żeby mieć sensowne wyniki.

• Weryfikacja konfiguracji edge w CDN.
• Testowanie zachowania fallback serwera origin.
• Debugowanie brakujących tokenów Accept-Encoding.

Ograniczenia darmowego Brotli Checker

To narzędzie sprawdza tylko finalny URL, który podasz. Nie crawluje całej strony. Jeśli homepage go używa, ale podstrony już nie, musisz je przetestować pojedynczo. Nie powie ci też, jaki jest stopień kompresji. Tylko potwierdza obecność algorytmu. Potrzebujesz osobnego profilera, żeby zmierzyć faktyczną oszczędność bajtów.

Niektóre serwery negocjują kodowanie w oparciu o user agent. Jeśli twój serwer serwuje różne kodowania różnym klientom, wynik może się różnić. Narzędzie używa standardowego user agenta dla przeglądarek desktopowych. Poza tym, jeśli strona wymaga uwierzytelnienia albo blokuje zautomatyzowane żądania, check wywali się błędem połączenia. Zabezpieczone endpointy będziesz musiał przetestować ręcznie przez curl.

Jak używać Brotli Checker

1. Wklej pełny URL zasobu, który chcesz przetestować, do pola input.
2. Kliknij przycisk check, żeby wysłać żądanie HTTP z tokenem br.
3. Przeczytaj wynik, żeby zobaczyć, czy nagłówek Content-Encoding jest obecny.
4. Przeanalizuj surowe nagłówki odpowiedzi pod kątem szczegółowych danych negocjacji.

Nagłówki kodowania kompresji

Tak wyglądają nagłówki odpowiedzi dla różnych algorytmów kompresji.

Frequently asked questions

Czy ten Brotli Checker jest w pełni darmowy?

Tak, możesz go używać tyle razy, ile potrzebujesz, bez zakładania konta. Nie ma żadnych ukrytych opłat ani kont premium do sprawdzania nagłówków HTTP.

Czy to działa dla mobilnych wersji stron?

Narzędzie sprawdza odpowiedź serwera, która jest identyczna niezależnie od urządzenia klienta. Serwer nie zmienia algorytmu kompresji w zależności od tego, czy jesteś na telefonie, czy na desktopie.

Dlaczego pokazuje brak kompresji, gdy wiem, że moja strona jej używa?

Twój serwer może sprawdzać string User-Agent i blokować zautomatyzowane narzędzia. Alternatywnie, możesz testować URL, który przekierowuje, zanim finalny skompresowany payload zostanie zaserwowany. Spróbuj przetestować bezpośrednio finalny URL docelowy.

Jaka jest różnica między br a gzip?

Brotli osiąga wyższy stopień kompresji dla zasobów tekstowych jak HTML, CSS i JavaScript. Kompresuje wolniej, ale dekompresuje szybciej. Gzip jest starszy i powszechnie obsługiwany, ale daje większe rozmiary plików dla tej samej zawartości.