Przejdź do treści 
Na stronie brotli kontra gzip Na podstawie mierzalnych efektów dotyczących TTFB, objętości danych i Core Web Vitals decyduję, który format dostarczyć na żywo. Z wiarygodnych benchmarków wiem, że: Pałeczka do chleba kompresuje HTML, CSS i JS średnio o 15–21 % i w wielu przypadkach dekompresuje je w przeglądarce szybciej, częściowo nawet do 64 % [1][4][5].
Punkty centralne
- współczynnik kompresji: Brotli redukuje zasoby tekstowe średnio o 15–21 % bardziej niż Gzip – zauważalne dla FCP/LCP [1][4][5].
- Scenariusze: Statyczne zasoby na obrzeżach sieci z Brotli, dynamiczne odpowiedzi często z Gzip lub umiarkowanym poziomem Brotli.
- Poziomy wydajności: Poziom 4 Brotli jest często szybszy i wydajniejszy niż poziom 6 Gzip; wysokie poziomy tylko w przypadku wstępnej kompresji [4][5].
- Hosting: Wydajny hosting kompresji z HTTP/2/3, buforowaniem i CDN znacznie skraca czas przesyłania danych [3][5][8].
- Monitoring: Zawsze sprawdzaj zmiany za pomocą RUM i testów syntetycznych poprzez FCP, LCP i TTFB.
Kompatybilność, nagłówki i klucze buforowania
Aby Brotli lub Gzip działały stabilnie, zwracam uwagę na czystość Negocjowanie treści. Przeglądarka wysyła Akceptuj kodowanie, serwer odpowiada komunikatem Kodowanie treści (br, gzip lub identity). Ważne: Zmieniaj: Akceptuj kodowanie słucha każdej skompresowanej odpowiedzi, aby pamięci podręczne i sieci CDN poprawnie rozdzielały różne warianty. W przeciwnym razie pamięć podręczna dostarczy plik Brotli do klienta, który rozumie tylko Gzip. Na poziomie CDN sprawdzam, czy Akceptuj kodowanie Część Klucze pamięci podręcznej i że węzły brzegowe mogą przechowywać zarówno wersje .br, jak i .gz.
Dodatkowo posiadam solidny Fallback gotowy: jeśli klient nie obsługuje Brotli, otrzymuje Gzip; jeśli nie obsługuje niczego, otrzymuje plik nieskompresowany. Dla lokalnych serwerów proxy lub starszych urządzeń ta ścieżka jest na wagę złota – i nie kosztuje mnie to żadnego czasu w codziennej pracy, jeśli łańcuch Vary jest poprawny. Świadomie pracuję z ETagami: silne ETagi dla każdej wersji lub hash uwzględniający formę kompresji zapobiegają błędom. 304 Niezmieniony Trafienia między br/gz.
Co naprawdę daje kompresja pocztowa w codziennym życiu
Wydajność Kompresja nie tylko skraca czas przesyłania, ale także stabilizuje czas ładowania przy zmiennej jakości sieci komórkowej. Im mniejsze pliki HTML, CSS, JavaScript i JSON, tym szybciej pojawiają się pierwsze treści, ponieważ przeglądarka musi pobrać i rozpakować mniej bajtów. Dlatego priorytetowo traktuję zasoby tekstowe, ponieważ obrazy i filmy w większym stopniu korzystają z własnych kodeków niż z kompresji HTTP. Na dobrze skonfigurowanych hostach można wyraźnie skrócić czas do pierwszego bajtu, ponieważ czas procesora i czas oczekiwania sieci są lepiej zrównoważone. Kto uporządkuje swoją potok, zyskuje podwójnie: mniej przepustowości dla Dane i mniej reflowów dzięki wcześniej dostępnym stylom i skryptom.
Jakie treści kompresować, a jakich nie
Kompresuję w sposób ukierunkowany tekstowy Typy: text/html, text/css, application/javascript, application/json, application/xml, image/svg+xml, application/manifest+json i podobne. W przypadku już skompresowanych formatów binarnych (obrazy, filmy, pliki PDF w wielu przypadkach, WOFF2) oszczędzam procesor: efekt jest minimalny, a opóźnienie może wzrosnąć. Równie ważne: wartość progowa(np. od 1024 do 2048 bajtów), aby niepotrzebnie nie opóźniać niewielkich odpowiedzi bez zauważalnej korzyści. W CI regularnie sprawdzam typ zawartości i rozmiar, aby wcześnie wykrywać błędne konfiguracje.
Brotli kontra Gzip: liczby, które zmieniają czas ładowania
Skompresowane w testach Pałeczka do chleba HTML około 21 %, JavaScript około 14 % i CSS około 17 % silniejsze niż Gzip [1][4]. Inne pomiary potwierdzają około 20 % przewagę nad Deflate, procesem stojącym za Gzip [5][6]. Różnica ta sprawia, że strony działają zauważalnie szybciej, zwłaszcza w przypadku wielu zasobów tekstowych i na urządzeniach mobilnych o zmiennej przepustowości. Ponadto dekompresja w przeglądarce w przypadku Brotli przebiega w wielu przypadkach szybciej; zmierzono nawet 64 % szybszy czas rozpakowywania w interfejsie użytkownika [1]. Podsumowując, lepsze Współczynniki kompresji i szybkie rozpakowanie wyraźnie uwidoczniło ścieżkę krytyczną do widocznej zawartości.
Z perspektywy sieci: pierwsze RTT i CWV
Wiele wymiernych korzyści wynika z faktu, że mniejsze odpowiedzi lepiej pasują do pierwszych Loty TCP/QUIC pasują. Jeśli dzięki Brotli początkowy kod HTML mieści się w jednym lub dwóch pakietach mniej, skraca się czas do FCP/LCP i blokady dla zasobów krytycznych dla renderowania. W protokole HTTP/3 połączenia dodatkowo korzystają z mniejszego Head-of-LineBlokada. W sieciach komórkowych o wyższym wskaźniku utraty pakietów mniejsze transfery wyrównują JitterKrzywa – dane RUM wykazują wtedy mniej wartości odstających w górę. Dla mnie jest to powód, aby konsekwentnie zmniejszać pierwszy HTML i krytyczny CSS [3][5][8].
Kiedy używam Brotli, a kiedy Gzip
Dla statyczny W przypadku zasobów takich jak HTML, CSS, JS, SVG i WOFF2 używam Brotli z wysokim poziomem, wstępnie skompresowanego podczas kompilacji lub bezpośrednio na krawędzi CDN. Pliki trafiają do pamięci podręcznej i są dostarczane tysiące razy bez obciążenia procesora. W przypadku bardzo dynamicznych odpowiedzi – spersonalizowane widoki HTML, API-JSON, wyszukiwanie – zazwyczaj stawiam na Gzip lub Brotli z umiarkowanym poziomem, aby serwer szybko przesyłał odpowiedź. Decydująca pozostaje krzywa TTFB: jeśli gwałtownie rośnie, zmniejszam poziom lub dostarczam nieblokowane treści częściowe raczej wcześniej. W ten sposób utrzymuję Czasy reakcji niski, bez utraty zalet kompaktowych plików.
Właściwy wybór poziomów jakości (poziom)
Zaczynam pragmatycznie: Brotli poziom 4 dla on-the-fly, poziomy 9–11 tylko dla pre-kompresji; Gzip poziom 6 jako solidny punkt wyjścia [4][5][6]. Jeśli obciążenie procesora wzrasta w godzinach szczytu, najpierw zmniejszam poziom Brotli i sprawdzam, czy nagłówki buforowania i CDN Edge działają poprawnie. Często niewielka zmiana w Schowek więcej niż wysoki poziom kompresji. W pomiarach Brotli wykazał, że poziom 4 często zapewnia lepsze rozmiary plików przy podobnym lub mniejszym opóźnieniu niż poziom 6 Gzip [4]. Kto dokładnie mierzy iteracje, szybko dochodzi do konfiguracji, która zapewnia Serwer oszczędza i jednocześnie zauważalnie zmniejsza ilość danych.
Konfiguracja: Nginx, Apache, Caddy – bezpieczne ustawienia domyślne
Stawiam na proste, sprawdzalne ustawienia domyślne. W przypadku Nginx oznacza to: stosowanie wariantów statycznych, umiarkowane stosowanie on-the-fly, odpowiednie typy, sensowne minimalne rozmiary, czyste ustawianie Vary.
# Nginx (przykład) brotli on; brotli_comp_level 4; brotli_static on; brotli_types text/html text/plain text/css application/javascript application/json application/xml image/svg+xml;
gzip on; gzip_comp_level 6; gzip_min_length 1024; gzip_static on; gzip_vary on; gzip_types text/plain text/css application/javascript application/json application/xml image/svg+xml; add_header Vary "Accept-Encoding" always;
W Apache aktywuję mod_brotli oraz mod_deflate z jasnym podziałem odpowiedzialności: najpierw Brotli, Deflate jako rezerwa. Minimalne rozmiary i typy pozostają niezmienne.
# Apache (przykład) AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css application/javascript application/json application/xml image/svg+xml BrotliCompressionQuality 4 BrotliWindowSize 22
AddOutputFilterByType DEFLATE text/html text/plain text/css application/javascript application/json application/xml image/svg+xml DeflateCompressionLevel 6 Header append Vary "Accept-Encoding"
Ważne pozostają zabezpieczenia: brak kompresji dla już skompresowanych mediów, testy podwójnej kompresji i proxy. bez transformacji unikaj, jeśli pamięci podręczne w przeciwnym razie blokują warianty. Sprawdzam za pomocą curl: -H „Accept-Encoding: br,gzip“ oraz -I, czy Kodowanie treści, Różne i wielkości są wiarygodne.
Wstępne kompresowanie zasobów statycznych: kompilacja, krawędź, pamięć podręczna
W przypadku frontendów obciążonych pakietami wstępnie kompresuję Aktywa w kompilacji i umieść wersje .br/.gz obok oryginałów, aby Nginx lub CDN dostarczały bezpośrednio odpowiednią wersję. Duże biblioteki, powtarzające się klasy CSS i kod frameworka odnoszą ponadprzeciętne korzyści, ponieważ Brotli wykorzystuje większe okno wyszukiwania i wbudowany słownik [2][9]. Legalne długoterminowe pamięci podręczne (niezmienne + wersjonowanie) dodatkowo redukują liczbę żądań i pracę związaną z rozpakowywaniem. Jeśli chcesz dostarczać treści globalnie, połącz to z inteligentnym Optymalizacja CDN, aby węzły brzegowe znajdujące się blisko użytkownika dostarczały dane. W ten sposób mniejsze pliki i bliskość geograficzna zapewniają łącznie niższe Opóźnienia.
Kontrola dynamicznych odpowiedzi i TTFB
W przypadku generowanych po stronie serwera HTML-W przypadku wyświetleń ważniejsze są streaming i niskie opóźnienia niż ostatnie punkty procentowe rozmiaru pliku. Kompresuję na bieżąco za pomocą Gzip lub Brotli na umiarkowanym poziomie, sprawdzam TTFB i CPU na pracownika i zwiększam poziom tylko wtedy, gdy dostępne są wystarczające rezerwy. Inteligentna kolejność szablonów wysyła pierwsze bajty wcześnie, aby przeglądarka mogła rozpocząć renderowanie. Dodatkowo stabilizuje Buforowanie po stronie serwera czas odpowiedzi, ponieważ powtarzające się fragmenty nie są za każdym razem ponownie obliczane. Ta konfiguracja utrzymuje Wskazówki bez spowalniania działania serwisu.
Prawidłowe dostarczanie strumieniowych transmisji i częściowych treści
W przypadku widoków HTML stawiam na Wczesne rzeki: krytyczne CSS inline, wczesna sekcja head, a następnie szybkie przesyłanie treści. Kompresja nie może tego spowalniać. Dlatego zwracam uwagę na rozmiary bufora i punkty flush i unikam skomplikowanych poziomów Brotli w trybie on-the-fly. Poziom Gzip 6 lub Brotli 3–4 zapewnia tutaj dobrą równowagę. Decydujące znaczenie ma to, aby serwer nie czekał, aż „wszystko będzie gotowe“, ale wysyłał dane w sensownych blokach – poprawia to FCP i postrzeganą responsywność.
HTTP/2 i HTTP/3: skuteczne łączenie kompresji
Multipleksowanie pod HTTP/2 i QUIC w HTTP/3 doskonale współpracują z mniejszymi plikami, ponieważ więcej obiektów przepływa równolegle i z mniejszym blokowaniem head-of-line. Zwłaszcza w przypadku połączeń komórkowych zmniejszone RTT i mniejsze straty pakietów w HTTP/3 zapewniają dodatkową stabilność. Dlatego zawsze sprawdzam, czy host obsługuje oba protokoły z prawidłowym priorytetem i zastępowaniem serwera (Early Hints). Porównując konfigurację, można znaleźć pomocne szczegóły w kompaktowym HTTP/3 kontra HTTP/2 Przegląd. W połączeniu z Brotli dla plików statycznych i Gzip dla Live-HTML zmniejsza się czas oczekiwania i Jitter zauważalne.
Strategie CDN: klucze pamięci podręcznej, stare dane i wstępna kompresja brzegowa
W CDN zwracam uwagę na to, aby .br oraz .gz Warianty są buforowane osobno, a węzły brzegowe dostarczają preferencyjnie już wstępnie skompresowane artefakty. Aktywuję stale-while-revalidate oraz stale-if-error, aby szczyty lub przerwy w działaniu zaplecza nie były widoczne. W przypadku tras API często pozwalam na kompresję CDN na żywo, ale przy zachowaniu konserwatywnych poziomów. Ważne: nagłówki takie jak Kontrola pamięci podręcznej, ETag, Różne oraz Kodowanie treści muszą tworzyć spójny obraz – w przeciwnym razie powstają dziwaczne fale cache miss, które pogarszają TTFB.
Użytkownicy urządzeń mobilnych: oszczędzaj przepustowość i baterię
Na smartfonie każda zaoszczędzona bajt bezpośrednio na czas ładowania i zużycie energii. Pliki Brotli mniejsze o 15–21 % skracają czas transferu i aktywność radiową; przy ograniczonej przepustowości odciążenie jest szczególnie odczuwalne [4][5]. Mniejsze ładunki stabilizują również wskaźniki FCP i LCP, ponieważ zasoby krytyczne dla renderowania są dostarczane szybciej. Zwracam również uwagę na czysty krytyczny CSS i podejmuję jasną decyzję, które skrypty mogą naprawdę blokować renderowanie. W rezultacie zmniejsza się współczynnik odrzuceń, a interakcje rozpoczynają się wcześniej, ponieważ przeglądarka ma mniej Obciążenie nosi.
Przepływ pracy zespołu, CI i budżety
Sprawiam, że kompresja staje się Temat rurociągu: Etapy kompilacji generują pliki .br/.gz, CI mierzy rozmiar artefaktów i porównuje je z budżetami. Pull request, który zwiększa rozmiar krytycznych zasobów o 30 %, natychmiast rzuca się w oczy. Dodatkowo zapisuję testy dymne (curl-checks dotyczące kodowania treści, Vary, porównanie rozmiarów), aby błędy nie były zauważalne dopiero w produkcji. Wdrożenia przeprowadzam jako Kanarek: Podziel ruch na nowe poziomy, obserwuj RUM i metryki serwera, a następnie w pełni wdroż. Jasne dźwignie rollback (flagi funkcji, mapa Nginx dla poziomów jakości) dają mi pewność w przypadku szczytowego ruchu.
Tabela porównawcza: mocne strony w skrócie
Poniższy przegląd pomaga mi w rozmowach z Zespoły, podejmować szybkie decyzje. Nie zastępuje ona testów we własnym stosie, ale pokazuje, gdzie można uzyskać największe efekty. Zawsze oceniam kombinację rozmiaru pliku, profilu procesora i wpływu na użytkownika. Ci, którzy skupiają się wyraźnie na statycznych zasobach tekstowych, prawie zawsze będą zadowoleni z Brotli. W przypadku bardzo dynamicznych aplikacji Gzip pozostaje niezawodnym rozwiązaniem. Wszechstronny.
| Kryterium | Pałeczka do chleba | Gzip | Efekt praktyczny |
|---|---|---|---|
| współczynnik kompresji | ~15–21 % mniejszy w przypadku HTML/CSS/JS [1][4][5] | Dobrze, ale większy niż Brotli | Mniej bajtów, szybsze Transmisja |
| Rozpakowywanie w przeglądarce | Często szybszy; do 64 % w testach [1] | Solidna prędkość | Szybszy start widoczny Zawartość |
| Profil procesora w locie | Umiarkowane poziomy szybko; wysokie poziomy drogie | Średnie poziomy bardzo szybko | W przypadku Live-HTML wybierz poziom konserwatywny. |
| Najlepsze zastosowania | Zasoby statyczne, wstępna kompresja, pamięć podręczna brzegowa | Dynamiczne odpowiedzi, strumienie, interfejsy API | Rozdzielanie konfiguracji według typu zasobów |
| Typowe stopnie | 4 (w locie), 9–11 (wcześniej) [4][5][6] | 6 jako punkt wyjścia | Równowaga między rozmiarem a TTFB |
| Kompatybilność | Szerokie wsparcie, możliwość powrotu do poprzedniej wersji [3][5][6] | Dostępny niemal wszędzie | Brak rzeczywistych przeszkód w nowoczesnych stosach |
Monitorowanie i testy: jak mierzyć postępy
Najpierw instaluję jasne Metryki: TTFB, FCP, LCP, bajty/żądanie i CPU na pracownika. Następnie porównuję warianty – Gzip vs. Brotli, dostosowania poziomu, włączanie/wyłączanie pamięci podręcznej brzegowej – w identycznych przedziałach czasowych. Testy syntetyczne wykazują powtarzalne różnice, a monitorowanie rzeczywistych użytkowników potwierdza wpływ na prawdziwych użytkowników. Ważne jest czyste cofnięcie zmian w przypadku wystąpienia szczytów obciążenia procesora lub fal braku pamięci podręcznej. Dopiero gdy efekty są stabilne, wdrażam konfigurację. Ruch ulicznytrasy o dużej intensywności.
Rozwiązywanie problemów: typowe błędy i szybkie kontrole
- Podwójna kompresja: Kodowanie treści pokazuje „br, br“ lub „gzip, gzip“. Przyczyną są często łańcuchy filtrów lub proxy + Origin. Rozwiązanie: powierzyć odpowiedzialność tylko jednej jednostce, preferować warianty statyczne.
- Nieprawidłowa wersja z pamięci podręcznej: Brotli jest dostępny dla klientów bez obsługi br. Najczęściej brakuje Zmieniaj: Akceptuj kodowanie lub klucz pamięci podręcznej CDN nie zawiera tego pola. Rozwiązanie: wymuś Vary i dostosuj klucz CDN.
- Eksplodujący TTFB Po aktywacji: poziom on-the-fly zbyt wysoki, nasycenie procesora lub brak pamięci podręcznej Edge. Rozwiązanie: obniżyć poziom, włączyć kompresję wstępną, sprawdzić nagłówek pamięci podręcznej.
- Brak przyrostu wielkości: nieprawidłowe typy (już skompresowane media), minimalna długość zbyt mała lub brak agresywnego minifikowania. Rozwiązanie: selekcjonowanie typów, zwiększenie minimalnej długości, sprawdzenie optymalizacji kompilacji.
- Uszkodzone pliki do pobrania: Długość treści nie pasuje do skompresowanej odpowiedzi lub upstream usuwa kodowanie treści. Rozwiązanie: w przypadku kompresji użyj kodowania transferu: chunked lub ponownie oblicz prawidłową długość.
- Nierówne ścieżki renderowania: HTML przesyła strumień zbyt późno, mimo że jest skompresowany. Rozwiązanie: uporządkuj szablon, wyślij wczesne bajty, użyj krytycznego CSS, wybierz umiarkowane poziomy.
W skrócie: moja strategia domyślna
W przypadku wszystkich zasobów tekstowych, które można zapisać w pamięci podręcznej, aktywuję Pałeczka do chleba i dostarczam wstępnie skompresowane pliki za pośrednictwem Build lub CDN‑Edge. Bardzo dynamiczne treści otrzymują Gzip lub Brotli na umiarkowanym poziomie, aby TTFB i interaktywność pozostały stabilne. HTTP/2 lub HTTP/3 działają z czystymi nagłówkami pamięci podręcznej, wczesnymi wskazówkami i priorytetowym ładowaniem krytycznych zasobów. Utrzymuję ustawienia jakości na jak najniższym poziomie, o ile rozmiary plików wykazują wyraźną korzyść. Takie podejście łączy niskie Ilość danych przy niskim obciążeniu serwera – i wyraźnie przyspiesza działanie stron.
