Brotli potrafi zmniejszyć pliki tekstowe strony, ale nie jest magicznym przyciskiem od szybkości. Działa najlepiej na HTML, CSS, JavaScript, SVG i innych zasobach tekstowych. Nie zastąpi kompresji obrazów, porządku w JavaScripcie ani sensownego cache.

Jeśli strona jest ciężka, Brotli może pomóc. Jeśli strona ładuje 8 MB zdjęć i kilka bibliotek do prostego formularza, sama kompresja będzie tylko plasterkiem.

Co właściwie robi Brotli?

Brotli to algorytm kompresji używany przy przesyłaniu zasobów przez HTTP. Przeglądarka wysyła w żądaniu informację, jakie kodowania obsługuje. Serwer może odpowiedzieć zasobem skompresowanym i dodać nagłówek Content-Encoding, na przykład br dla Brotli albo gzip dla gzip.

MDN opisuje Content-Encoding jako nagłówek, który mówi odbiorcy, jak odkodować przesłaną reprezentację zasobu. W praktyce użytkownik nadal dostaje ten sam CSS czy HTML. Różnica polega na mniejszej liczbie bajtów przesłanych przez sieć.

Co warto kompresować?

HTML, CSS i JavaScript,
SVG, JSON, XML i manifesty,
odpowiedzi API, jeśli są tekstowe i wystarczająco duże,
pliki fontów zależnie od formatu i konfiguracji.

Nie ma sensu przepychać przez Brotli wszystkiego. JPEG, PNG, WebP, AVIF, MP4 i inne formaty skompresowane wewnętrznie zwykle nie zyskają dużo, a czasem serwer tylko traci czas.

Brotli czy gzip?

Gzip jest starszy i szeroko obsługiwany. Brotli często daje lepszy stopień kompresji dla zasobów tekstowych, szczególnie statycznych plików przygotowanych wcześniej. Dobry hosting lub CDN zwykle obsługuje oba warianty i dobiera odpowiedź do przeglądarki.

Przy dynamicznych odpowiedziach trzeba uważać na koszt kompresji w czasie rzeczywistym. Dla statycznych assetów najlepszy model to przygotowanie skompresowanych plików podczas builda albo użycie CDN, który robi to za ciebie.

Jak sprawdzić, czy Brotli działa?

Najprostszy test wykonasz w DevTools albo komendą curl. Otwórz zakładkę Network, kliknij plik CSS lub JS i sprawdź nagłówki odpowiedzi. Szukaj content-encoding: br. Możesz też porównać rozmiar przesłany przez sieć z rozmiarem po rozpakowaniu.

curl -I -H "Accept-Encoding: br,gzip" https://example.com/app.css

Jeżeli odpowiedź nie ma Content-Encoding, to jeszcze nie dowód katastrofy. Może testujesz za mały plik, zasób z innej domeny albo konfigurację, która używa gzip. Ważny jest efekt w realnym ładowaniu strony.

Gdzie Brotli pomaga w Core Web Vitals?

Mniejszy transfer może przyspieszyć pobranie HTML, CSS i JavaScriptu. To pomaga szczególnie na wolniejszym internecie i przy pierwszej wizycie bez cache. Nie rozwiąże jednak problemu długiego wykonywania JavaScriptu, render blocking CSS, wolnego serwera albo zbyt późno ładowanego obrazu LCP.

Checklista wdrożenia

Sprawdź, czy hosting lub CDN obsługuje Brotli.
Włącz Brotli dla typów tekstowych, nie dla każdego pliku.
Zostaw gzip jako fallback.
Upewnij się, że nagłówek Vary: Accept-Encoding jest poprawny przy cache.
Przetestuj kilka zasobów w DevTools i curl.
Porównaj Lighthouse/WebPageTest przed i po, ale patrz też na realne zasoby w Network.

Brotli jest sensownym elementem optymalizacji, gdy strona ma już podstawowy porządek. Największą wartość daje jako część zestawu: dobry build, mało zbędnego JS, lekkie obrazy, cache i poprawne nagłówki.

Źródło pomocnicze: MDN: Content-Encoding header.