{"id":13564,"date":"2026-10-16T18:25:00","date_gmt":"2026-10-16T16:25:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13564"},"modified":"2026-10-09T23:19:52","modified_gmt":"2026-10-09T21:19:52","slug":"gzip-brotli-i-zstd-czym-naprawde-kompresuje-dwadziescia-duzych-stron","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/pl\/tworzenie-stron-internetowych\/tutorials-pl-tworzenie-stron-internetowych\/gzip-brotli-i-zstd-czym-naprawde-kompresuje-dwadziescia-duzych-stron\/","title":{"rendered":"gzip, Brotli i zstd: czym naprawd\u0119 kompresuje dwadzie\u015bcia du\u017cych stron"},"content":{"rendered":"

Strona, kt\u00f3ra dociera do przegl\u0105darki, zwykle nie jest t\u0105 stron\u0105, kt\u00f3ra le\u017cy na serwerze, lecz jej spakowan\u0105 wersj\u0105 – a rozpakowanie dzieje si\u0119 tak wcze\u015bnie, \u017ce dalej nic ju\u017c tego nie zauwa\u017ca.<\/p>\n

Kt\u00f3ry spos\u00f3b pakuje, uzgadniane jest mi\u0119dzy przegl\u0105dark\u0105 a serwerem przy ka\u017cdym pojedynczym zapytaniu. W obiegu s\u0105 trzy, a pomiar na dwudziestu du\u017cych stronach g\u0142\u00f3wnych pokazuje, \u017ce jeden wykonuje prawie ca\u0142\u0105 prac\u0119.<\/p>\n

\n\"Cztery
Cztery sposoby by\u0142y oferowane w ka\u017cdym zapytaniu. Dwa z nich w og\u00f3le wesz\u0142y w u\u017cycie.<\/figcaption><\/figure>\n

Rozstrzygaj\u0105 to dwie linijki nag\u0142\u00f3wka<\/h2>\n

Przegl\u0105darka zaczyna od listy. Jej zapytanie niesie linijk\u0119 o nazwie Accept-Encoding<\/code>, a w niej stoi wszystko, co przegl\u0105darka potrafi rozpakowa\u0107 – dzi\u015b zwykle gzip, deflate, br, zstd<\/code>.<\/p>\n

Serwer wybiera z tej listy jeden spos\u00f3b, pakuje odpowied\u017a i podaje sw\u00f3j wyb\u00f3r w linijce o nazwie Content-Encoding<\/code>. Gdy nie wybiera nic, tej linijki po prostu brakuje, a tre\u015b\u0107 podr\u00f3\u017cuje dok\u0142adnie tak, jak le\u017cy na dysku.<\/p>\n

Jeszcze jedna linijka liczy si\u0119 wsz\u0119dzie tam, gdzie po drodze siedzi pami\u0119\u0107 podr\u0119czna. Vary: Accept-Encoding<\/code> m\u00f3wi tej pami\u0119ci, \u017ce odpowied\u017a zale\u017cy od pytania – \u017ceby spakowana kopia nigdy nie trafi\u0142a do programu, kt\u00f3ry nie umie jej rozpakowa\u0107.<\/p>\n

Nic w tej wymianie nie jest sta\u0142ym ustawieniem po kt\u00f3rejkolwiek stronie. Prowadzona jest od nowa dla ka\u017cdego pliku, za ka\u017cdym razem.<\/p>\n

Trzy sposoby<\/h2>\n

gzip<\/code> jest najstarszy i najbezpieczniejszy. Od dziesi\u0119cioleci tkwi w ka\u017cdej przegl\u0105darce i ka\u017cdym narz\u0119dziu wiersza polece\u0144, i nigdzie nikt go nie odmawia.<\/p>\n

br<\/code>, skr\u00f3t od Brotli, jest m\u0142odszy i og\u00f3lnie pakuje tekst cia\u015bniej ni\u017c gzip, przy por\u00f3wnywalnej pr\u0119dko\u015bci odczytu. Przegl\u0105darki oferuj\u0105 go wy\u0142\u0105cznie przez HTTPS.<\/p>\n

zstd<\/code> jest jeszcze m\u0142odszy. Jego argumentem jest tempo, nie g\u0119sto\u015b\u0107: pakuje i rozpakowuje szybciej przy podobnym stosunku, co liczy si\u0119 przede wszystkim tam, gdzie pakowanie odbywa si\u0119 na \u015bwie\u017co przy ka\u017cdym pojedynczym zapytaniu.<\/p>\n

deflate<\/code> stoi na li\u015bcie g\u0142\u00f3wnie z przyzwyczajenia. To ten sam algorytm co gzip w innym opakowaniu i bywa oferowany znacznie cz\u0119\u015bciej, ni\u017c kiedykolwiek u\u017cywany.<\/p>\n

Co naprawd\u0119 wysy\u0142a dwadzie\u015bcia stron g\u0142\u00f3wnych<\/h2>\n

Dwadzie\u015bcia du\u017cych stron zapytano 2 wrze\u015bnia 2026 po jednym razie, ka\u017cde zapytanie z wszystkimi czterema sposobami w ofercie. Wszystkie dwadzie\u015bcia odpowiedzia\u0142y statusem 200.<\/p>\n

Trzyna\u015bcie odpowiedzia\u0142o przez gzip<\/code>: Wikipedia, GitHub, BBC, New York Times, Apple, Spiegel, Heise, python.org, debian.org, kernel.org, gnu.org, nginx.org i postgresql.org.<\/p>\n

Sze\u015b\u0107 odpowiedzia\u0142o przez br<\/code>: cloudflare.com, mozilla.org, w3.org, zeit.de, tagesschau.de i php.net.<\/p>\n

Jedna odpowiedzia\u0142a zupe\u0142nie niczym.<\/p>\n

A zstd<\/code>, zaoferowany we wszystkich dwudziestu zapytaniach, nie zosta\u0142 wybrany przez \u017cadne. Dlaczego, z zewn\u0105trz nie wida\u0107. Wida\u0107, \u017ce gzip po trzech dziesi\u0119cioleciach pozostaje zwyczajn\u0105 odpowiedzi\u0105.<\/p>\n

\n\"Wysoki
\n<\/figure>\n

Ile to naprawd\u0119 oszcz\u0119dza<\/h2>\n

Zmierzone stosunki si\u0119gaj\u0105 od 2,88 do 12,63.<\/p>\n

Najcia\u015bniej spakowa\u0142a cloudflare.com: 1 315 964 bajt\u00f3w znacznik\u00f3w podr\u00f3\u017cowa\u0142o jako 104 114. Najlu\u017aniej nginx.org z wynikiem 2,88, i nie jest to pora\u017cka – strona jest kr\u00f3tka i prosta, a ma\u0142y plik niesie po prostu mniej powt\u00f3rze\u0144, z kt\u00f3rych da\u0142oby si\u0119 czerpa\u0107.<\/p>\n

Rozmiar zatem pomaga. Du\u017ce strony z\u0142o\u017cone przez zestaw narz\u0119dzi pakuj\u0105 si\u0119 znacznie lepiej ni\u017c ma\u0142e pisane r\u0119cznie, bo kompresja \u017cyje z powt\u00f3rze\u0144, a strona wygenerowana jest ich pe\u0142na.<\/p>\n

Brotli te\u017c nie wygrywa sam z siebie. tagesschau.de osi\u0105gn\u0119\u0142a z nim 11,99, podczas gdy zeit.de tym samym sposobem dosz\u0142a do 3,38. To, co jest pakowane, liczy si\u0119 bardziej ni\u017c czym.<\/p>\n

Ta jedna, kt\u00f3ra nie wysy\u0142a nic<\/h2>\n

microsoft.com da\u0142a jedyn\u0105 odpowied\u017a bez linijki Content-Encoding<\/code>: 201 253 bajt\u00f3w HTML, dok\u0142adnie tak jak zapisane.<\/p>\n

Odpowied\u017a podaje swoje pochodzenie dostatecznie wyra\u017anie – server: AkamaiNetStorage<\/code>, nagie content-length<\/code>, \u017cadnego vary<\/code>. Kompresja usun\u0119\u0142aby z tego jakie\u015b dziewi\u0119\u0107 dziesi\u0105tych.<\/p>\n

Trzeba to powiedzie\u0107 dok\u0142adnie, bo jeden pomiar to jeden pomiar: to, co dotar\u0142o tutaj, o tej godzinie, t\u0105 drog\u0105, by\u0142o nieskompresowane. Inny w\u0119ze\u0142 albo inna droga odpowie by\u0107 mo\u017ce inaczej. Odpowied\u017a i tak by\u0142a prawdziwa, a 201 KB przesz\u0142o przez \u0142\u0105cze.<\/p>\n

B\u0142\u0105d pomiaru, kt\u00f3ry wymy\u015bla wynik<\/h2>\n

Pozornie prosty spos\u00f3b obliczenia wsp\u00f3\u0142czynnika to wys\u0142a\u0107 dwa zapytania: jedno z Accept-Encoding: identity<\/code>, a drugie z wszystkimi sposobami kompresji w ofercie. Nast\u0119pnie dzieli si\u0119 rozmiar pierwszej odpowiedzi przez rozmiar drugiej.<\/p>\n

Ta metoda da\u0142a tutaj pozornie jednoznaczny, ale b\u0142\u0119dny wynik. python.org zwr\u00f3ci\u0142a oba razy 11 672 bajty, czyli stosunek dok\u0142adnie 1,00. Sugeruje to, \u017ce strona w og\u00f3le nie kompresuje odpowiedzi.<\/p>\n

Wra\u017cenie myli. Serwer pomin\u0105\u0142 pro\u015bb\u0119 o brak kompresji i mimo to wys\u0142a\u0142 gzip, wi\u0119c oba razy chodzi\u0142o o rozmiar spakowany. Zmierzona poprawnie python.org pakuje 52 820 bajt\u00f3w do 11 672 – stosunek 4,52.<\/p>\n

Droga, kt\u00f3rej nie da si\u0119 zmyli\u0107, potrzebuje tylko jednego zapytania: policzy\u0107 bajty docieraj\u0105ce na \u0142\u0105czu i por\u00f3wna\u0107 je z plikiem po rozpakowaniu. Obie liczby pochodz\u0105 z tej samej odpowiedzi, wi\u0119c \u017caden serwer nie dostaje okazji, by odpowiedzie\u0107 inaczej na drugie pytanie.<\/p>\n

\n

Pytania i odpowiedzi<\/h2>\n

Czy kompresja op\u0142aca si\u0119 tak\u017ce przy obrazach i plikach czcionek?<\/h3>\n

Raczej nie. JPEG, PNG, WebP i WOFF2 s\u0105 ju\u017c skompresowane same w sobie, a gzip czy Brotli nie znajduj\u0105 w nich prawie \u017cadnych powt\u00f3rze\u0144, z kt\u00f3rych da\u0142oby si\u0119 czerpa\u0107; czasem plik nawet nieco ro\u015bnie. Serwery ograniczaj\u0105 wi\u0119c kompresj\u0119 zwykle do format\u00f3w tekstowych, takich jak HTML, CSS, JavaScript, JSON i SVG.<\/p>\n

Czy Brotli kosztuje serwer wi\u0119cej czasu oblicze\u0144 ni\u017c gzip?<\/h3>\n

To zale\u017cy od poziomu. Brotli zna poziomy jako\u015bci od 0 do 11, a najwy\u017csze pakuj\u0105 wyra\u017anie wolniej ni\u017c gzip. Przy odpowiedziach powstaj\u0105cych od nowa przy ka\u017cdym zapytaniu, na przyk\u0142ad przy HTML z WordPressa, zwykle stosowane s\u0105 wi\u0119c poziomy \u015brednie, przy kt\u00f3rych nak\u0142ad czasu jest zbli\u017cony do gzip, a wynik i tak jest mocniej skompresowany.<\/p>\n

Przy plikach statycznych rachunek wygl\u0105da inaczej. CSS i JavaScript da si\u0119 spakowa\u0107 raz, przy wdro\u017ceniu, na najwy\u017cszym poziomie i po\u0142o\u017cy\u0107 jako gotowy plik obok orygina\u0142u; serwer wydaje wtedy ju\u017c tylko pasuj\u0105c\u0105 wersj\u0119. Wolny poziom kosztuje czas jeden raz, a nie przy ka\u017cdym pobraniu. Argument tempa, kt\u00f3rym przekonuje zstd, dotyczy w\u0142a\u015bnie przypadku odwrotnego: pakowania przy ka\u017cdym zapytaniu.<\/p>\n

Czy kompresja przez HTTPS stanowi zagro\u017cenie dla bezpiecze\u0144stwa?<\/h3>\n

W jednym, w\u0105sko okre\u015blonym przypadku. Atak BREACH wykorzystuje to, \u017ce skompresowana odpowied\u017a staje si\u0119 kr\u00f3tsza, gdy tekst wstrzykni\u0119ty przez atakuj\u0105cego pokrywa si\u0119 z sekretem w tej samej odpowiedzi. Potrzebne s\u0105 jednocze\u015bnie trzy rzeczy: sekret w tre\u015bci odpowiedzi, na przyk\u0142ad token CSRF, dane od atakuj\u0105cego, kt\u00f3re pojawiaj\u0105 si\u0119 z powrotem w tej samej odpowiedzi, oraz mo\u017cliwo\u015b\u0107 wywo\u0142ania bardzo wielu zapyta\u0144 i obserwowania d\u0142ugo\u015bci zaszyfrowanych odpowiedzi.<\/p>\n

Typowa obrona zostawia kompresj\u0119 w\u0142\u0105czon\u0105, a usuwa jeden z warunk\u00f3w: tokeny maskowane inaczej przy ka\u017cdym wydaniu strony albo brak niefiltrowanego odbijania danych wej\u015bciowych na stronach z sekretami. Kompresji na poziomie TLS, w kt\u00f3r\u0105 celowa\u0142 starszy atak CRIME, w TLS 1.3 ju\u017c nie ma; nie ma ona nic wsp\u00f3lnego z Content-Encoding.<\/p>\n

Jak wygl\u0105da pomiar jednym zapytaniem w wierszu polece\u0144?<\/h3>\n

Najpro\u015bciej za pomoc\u0105 curl bez automatycznego rozpakowywania: zapytanie oferuje wy\u0142\u0105cznie gzip, a odpowied\u017a trafia do pliku dok\u0142adnie w takiej postaci, w jakiej przesz\u0142a przez \u0142\u0105cze.<\/p>\n

curl -s -D - -H \"Accept-Encoding: gzip\" -o strona.gz https:\/\/example.com\/<\/code><\/p>\n

Wypisane nag\u0142\u00f3wki pokazuj\u0105, czy serwer rzeczywi\u015bcie ustawi\u0142 Content-Encoding: gzip. Nast\u0119pnie wc -c < strona.gz<\/code> podaje rozmiar spakowanej tre\u015bci w postaci przes\u0142anej, a gzip -dc strona.gz | wc -c<\/code> rozmiar po rozpakowaniu; stosunek obu liczb to szukana warto\u015b\u0107. Obie pochodz\u0105 z tej samej odpowiedzi i w\u0142a\u015bnie o to chodzi.<\/p>\n

Je\u015bli brakuje linijki Content-Encoding, plik w og\u00f3le nie jest spakowany, a gzip ko\u0144czy prac\u0119 komunikatem o b\u0142\u0119dzie. To tak\u017ce jest wynik, przypadek microsoft.com. Dla Brotli obowi\u0105zuje to samo z br w ofercie i programem brotli do rozpakowania, o ile jest zainstalowany.<\/p>\n<\/div>\n

\n

\u0179r\u00f3d\u0142a<\/h2>\n