HTTP/3 i kompresja Brotli na polskich stronach
39% z 7785 stron .pl ogłasza HTTP/3, a 44% wysyła stronę z Brotli lub zstd, w większości przez Cloudflare lub LiteSpeed; nginx i Apache dają zwykle gzip.
Dwie na pięć polskich stron ogłaszają HTTP/3, a mniej niż połowa wysyła stronę główną z kompresją Brotli lub zstd. Odczytaliśmy nagłówki odpowiedzi stron głównych 7785 witryn .pl z listy popularnych stron Tranco (otwiera się w nowej karcie): 39% wymienia HTTP/3 w nagłówku Alt-Svc, 44% przyszło skompresowanych Brotli lub Zstandardem, 50% gzipem, a 5,5% bez żadnej kompresji.
Kto to włączył, widać w nagłówkach. 67% stron ogłaszających HTTP/3 stoi za Cloudflare, a większość pozostałych działa na LiteSpeedzie, serwerze WWW, który ma HTTP/3 od razu po instalacji. Strony obsługiwane przez nginx lub Apache bez CDN przed nimi wysyłają zwykle gzip i tylko po TCP. HTTP/3 i wybór między kompresją Brotli a gzipem to więc w polskim internecie przede wszystkim ustawienia domyślne tego, kto odpowiada na żądanie. To ten sam spis, na którym oparliśmy badanie skryptów zewnętrznych na polskich stronach, tym razem odczytany pod kątem transportu, a nie treści.
- 7785
- 39%
- 44%
- 67%
Czym są HTTP/3 i kodowanie treści
HTTP/3 (RFC 9114 (otwiera się w nowej karcie), czerwiec 2022) przenosi HTTP przez QUIC, transport na UDP, zamiast przez TCP. Zgubiony pakiet wstrzymuje wtedy tylko swój strumień, a nie całe połączenie, a nowe połączenie potrzebuje mniej wymian, zanim przyjdzie pierwszy bajt. Przeglądarka nie zaczyna od HTTP/3. Pierwsza wizyta idzie po TCP, a serwer ogłasza HTTP/3 w nagłówku odpowiedzi, Alt-Svc: h3=":443"; ma=86400, opisanym w sekcji 3.1.1 tego RFC. Przeglądarka może wtedy spróbować QUIC, a gdy UDP jest zablokowane, wraca do TCP.
Kompresja to osobne negocjacje. Przeglądarka wymienia w Accept-Encoding, co potrafi rozpakować, serwer wybiera jedno i podaje je w Content-Encoding. Gzip to stary wspólny mianownik; Brotli (RFC 7932 (otwiera się w nowej karcie), 2016) ściska tekst mocniej; Zstandard (RFC 8878 (otwiera się w nowej karcie)) trafił do Chrome 123, którego notatki z wersji beta wymieniają kodowanie zstd (otwiera się w nowej karcie), i do Firefoksa 126 (otwiera się w nowej karcie), oba w 2024 roku.
Ile polskich stron używa HTTP/3?
3042 stron, 39% próby, ogłasza ostateczny token h3. Kolejne 4 oferują tylko wersje robocze sprzed standardu (h3-29, quic Google’a), których nie liczymy. Wykres dzieli strony według tego, kto odpowiedział: Cloudflare, gdy widać jego nagłówki, inny CDN albo, gdy w nagłówkach nie ma CDN, serwer WWW podany w Server.
HTTP/3 w polskim internecie niosą Cloudflare i LiteSpeed
Udział stron głównych .pl, których nagłówek Alt-Svc ogłasza h3, według tego, kto odpowiedział na żądanie · n dla każdej grupy w tabeli niżej · przedziały 95%
Pokaż dane
| Pozycja | Wartość | Przedział 95% | n |
|---|---|---|---|
| Cloudflare | 79% | 77%–81% | 2563 |
| Apache, bez CDN | 5,7% | 4,7%–6,9% | 1767 |
| nginx, bez CDN | 4,2% | 3,3%–5,3% | 1547 |
| LiteSpeed, bez CDN | 96% | 94%–97% | 675 |
| Bez nagłówka Server, bez CDN | 11% | 7,9%–14% | 399 |
| Inny CDN | 31% | 26%–37% | 284 |
| Inne serwery, bez CDN | 31% | 25%–38% | 192 |
| dcsaas (Shoper), bez CDN | 0% | 0%–2,6% | 145 |
| IdeaWebServer, bez CDN | 9,8% | 5,9%–16% | 143 |
| Microsoft IIS, bez CDN | 1,4% | 0,3%–7,7% | 70 |
Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.
Dwie grupy się wyróżniają. Za Cloudflare HTTP/3 ogłasza 79% stron, na LiteSpeedzie bez CDN 96%. Dokumentacja LiteSpeeda (otwiera się w nowej karcie) (czytana 14 października 2026) mówi, że „QUIC is on by default”, a hosting musi otworzyć port UDP 443 i mieć zaufany certyfikat. Na nginx i Apache HTTP/3 jest rzadkie: 4,2% stron na nginx i 5,7% na Apache. Nginx ma HTTP/3 w module (otwiera się w nowej karcie), który „is not built by default” i wciąż jest oznaczony jako eksperymentalny. Największe strony ogłaszają HTTP/3 rzadziej. Wśród pierwszego tysiąca próby robi to 29%, wśród stron niżej 41%, choć jedne i drugie równie często korzystają z Cloudflare. Różnią się dwie rzeczy. LiteSpeed bez CDN jest na szczycie rzadszy (2,7% wobec 9,6%), a największe strony za Cloudflare rzadziej ogłaszają HTTP/3 (63% wobec 81%). Z nagłówków nie widać, dlaczego.
Brotli czy gzip czy zstd: z czym przychodzą polskie strony główne
Nasz crawler prosił o zstd, br, gzip bez wskazania preferencji, więc każdy serwer wybierał według własnych ustawień. Połowa próby odpowiedziała gzipem. Podział biegnie tą samą linią co przy HTTP/3.
Za Cloudflare strony przychodzą z zstd lub Brotli, bez CDN zwykle z gzipem
Content-Encoding stron głównych .pl według tego, kto odpowiedział na żądanie · Accept-Encoding: zstd, br, gzip · n dla każdego wiersza w tabeli
- Zstandard
- Brotli
- gzip
- Bez kompresji
Pokaż dane
| Pozycja | Zstandard | Brotli | gzip | Bez kompresji | n |
|---|---|---|---|---|---|
| Wszystkie strony | 18% | 26% | 50% | 5,5% | 7785 |
| Cloudflare | 55% | 40% | 3,9% | 0,2% | 2563 |
| Apache, bez CDN | 0% | 7% | 83% | 10% | 1767 |
| nginx, bez CDN | 0,3% | 6,3% | 87% | 6,3% | 1547 |
| LiteSpeed, bez CDN | 0% | 82% | 16% | 1,3% | 675 |
| Bez nagłówka Server, bez CDN | 1% | 12% | 69% | 18% | 399 |
| Inny CDN | 0% | 37% | 56% | 7% | 284 |
| Inne serwery, bez CDN | 1% | 26% | 62% | 11% | 192 |
| dcsaas (Shoper), bez CDN | 0% | 0% | 100% | 0% | 145 |
| IdeaWebServer, bez CDN | 0% | 0% | 99% | 1,4% | 143 |
| Microsoft IIS, bez CDN | 0% | 1,4% | 66% | 33% | 70 |
Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.
Za Cloudflare 55% stron głównych przyszło z Zstandardem, a 40% z Brotli. To zgadza się z dokumentacją kompresji Cloudflare (otwiera się w nowej karcie) (aktualizacja 17 kwietnia 2026): w planie Free „content is compressed by default using Zstandard”, w Pro i Business Brotli, w Enterprise gzipem. Planu strony nie widzimy, ale prawie każda odpowiedź z zstd w próbie przyszła od Cloudflare.
Bez CDN ustawienia domyślne są starsze. Moduł gzip w nginx (otwiera się w nowej karcie) jest wyłączony, dopóki ktoś go nie włączy, a Brotli nie ma w rdzeniu nginx; Apache ma mod_brotli (otwiera się w nowej karcie) od wersji 2.4.26, ale hosting musi go włączyć. Strony na LiteSpeedzie znów się wyróżniają: Brotli ma 82% z nich. Strony na Microsoft IIS najrzadziej są w ogóle kompresowane.
Kompresja Brotli czy gzip: co daje lepszy wynik?
Żeby odpowiedzieć na polskich stronach, a nie na zestawie testowym, skompresowaliśmy HTML każdej strony głównej ponownie na jednym komputerze, gzipem, Brotli i Zstandardem na jedenastu poziomach, i porównaliśmy każdy rozmiar z gzipem na poziomie 6, domyślnym w zlib. Wzięło w tym udział 7435 stron głównych (bez tych uciętych na limicie spisu 1 MiB oraz kilku z pustą odpowiedzią), z medianą 154 kB HTML-a.
Brotli zmniejsza polskie strony główne bardziej niż gzip i zstd od średniego wysiłku wzwyż
Mediana oszczędności wobec gzip 6 na tym samym HTML-u strony głównej, według kodeka i poziomu · zlib z Node.js · n = 7435 stron głównych · przedziały bootstrap 95%
Pokaż dane
| Pozycja | Wartość | Przedział 95% | n |
|---|---|---|---|
| gzip 1 | -18% | -18%–-18% | 7435 |
| gzip 9 | 0,7% | 0,7%–0,7% | 7435 |
| Brotli 1 | -10% | -10%–-10% | 7435 |
| Brotli 5 | 10% | 9,9%–10% | 7435 |
| Brotli 9 | 12% | 12%–12% | 7435 |
| Brotli 11 | 20% | 20%–20% | 7435 |
| zstd 1 | -6,9% | -7%–-6,8% | 7435 |
| zstd 3 | -2,4% | -2,6%–-2,3% | 7435 |
| zstd 9 | 6,4% | 6,2%–6,5% | 7435 |
| zstd 19 | 11% | 11%–11% | 7435 |
Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.
Z gzipem Brotli wygrywa rozmiarem na każdym poziomie. Z zstd wygrywa od średniego wysiłku wzwyż (Brotli 5 wobec zstd 9, Brotli 9 wobec zstd 19); przy najszybszych ustawieniach zstd 1 i 3 dają mniejsze pliki niż Brotli 1 i robią je szybciej. Na poziomie 5, domyślnym w Apache dla treści dynamicznych, medianowa strona główna jest o 10% mniejsza niż z gzipem 6; na poziomie 11, najwolniejszym, o 20%. Podniesienie gzipa z 6 na 9 nie daje prawie nic: 0,7%.
Czy Brotli jest szybsze niż gzip? Czy zstd je wyprzedza?
Kodeki różnią się przede wszystkim szybkością. Tabela podaje szybkość każdego poziomu na losowej próbie 400 stron głównych (ze stałym ziarnem), kompresowanych po jednej na jednym wątku (Apple silicon, zlib z Node.js; rozmiary nie zależą od komputera, szybkości tak).
| Kodek i poziom | Mediana oszczędności wobec gzip 6 | Oszczędność na wszystkich bajtach | Mediana rozmiaru | Szybkość, MB/s |
|---|---|---|---|---|
| gzip 1 | -18% | -20% | 30,9 kB | 195,1 |
| gzip 6 | 0% | 0% | 26,1 kB | 81,3 |
| gzip 9 | 0,7% | 1,1% | 25,8 kB | 42,6 |
| Brotli 1 | -10% | -6,3% | 28,4 kB | 452,3 |
| Brotli 5 | 10% | 14% | 23,1 kB | 106,3 |
| Brotli 9 | 12% | 17% | 22,7 kB | 66,7 |
| Brotli 11 | 20% | 24% | 20,7 kB | 1 |
| zstd 1 | -6,9% | -2,3% | 27,5 kB | 596,4 |
| zstd 3 | -2,4% | 3,4% | 26,2 kB | 568,1 |
| zstd 9 | 6,4% | 12% | 23,9 kB | 129,1 |
| zstd 19 | 11% | 17% | 22,8 kB | 4,5 |
Atutem Zstandardu jest szybkość, nie rozmiar. Na domyślnym poziomie 3 daje medianową stronę nie mniejszą niż gzip 6 („oszczędność” -2,4%, czyli odrobinę większą; licząc wszystkie bajty razem 3,4%) i kompresuje 568,1 MB/s; Brotli 5 oszczędza 10% przy 106,3 MB/s. Brotli 11 to poziom dla plików kompresowanych raz i przechowywanych, a nie dla HTML-a tworzonego przy każdym żądaniu: osiągnęło 1 MB/s.
Co serwery naprawdę wysyłają
Ponowna kompresja pokazuje też, jak mocno kompresował każdy serwer. Dla stron głównych, które przyszły z gzipem, porównaliśmy bajty wysłane z tym, co gzip robi z tym samym HTML-em na poziomach 1 i 6.
13% stron z gzipem wysłano co najmniej tak dużych, jak robi je gzip na poziomie 1, czyli ustawienie, którego nginx używa, jeśli nikt go nie zmieni (gzip_comp_level 1). Przejście wszystkich stron z gzipem na Brotli 5 oszczędziłoby w medianie 11% wysyłanych dziś bajtów, około 2,4 kB na każde wyświetlenie strony głównej. Podobnie zyskałyby strony z zstd, prawie wszystkie za Cloudflare: Brotli 5 zdjęłoby w medianie 12% z tego, co wysyłają, bo zstd w postaci, w jakiej przychodzi, ma mniej więcej rozmiar gzip 6. Dla stron wysyłanych bez kompresji zysk jest dużo większy: medianowa waży w transferze 42 kB, a Brotli 5 zdjęłoby z tego 78%.
Czy HTTP/3 jest szybsze niż HTTP/2?
Nasze dane tego nie zmierzą: wiemy, które strony HTTP/3 ogłaszają, a nie, które wizyty go użyły. Możemy pokazać kontekst od prawdziwych użytkowników Chrome. Chrome UX Report ma TTFB (czas do pierwszego bajtu) na telefonach dla 6076 stron, z 28 dni do 22 września 2026, pobrany dla tych samych originów w badaniu skryptów zewnętrznych.
Za Cloudflare strony z HTTP/3 mają niższy TTFB na telefonach, bez CDN różnicy nie ma
Mediana TTFB p75 originów na telefonach, w sekundach, według CDN i tego, czy HTTP/3 jest ogłaszane · CrUX, 26 sie – 22 wrz 2026 · przedziały bootstrap 95%
Pokaż dane
| Pozycja | Wartość | Zakres | n |
|---|---|---|---|
| Cloudflare, HTTP/3 ogłaszane | 0,72 s | 0,68 s–0,76 s | 1656 |
| Cloudflare, nieogłaszane | 0,82 s | 0,79 s–0,9 s | 519 |
| Bez CDN, HTTP/3 ogłaszane | 0,76 s | 0,72 s–0,82 s | 651 |
| Bez CDN, nieogłaszane | 0,76 s | 0,74 s–0,78 s | 2977 |
| LiteSpeed z HTTP/3, bez CDN | 0,75 s | 0,7 s–0,82 s | 453 |
| nginx lub Apache bez HTTP/3, bez CDN | 0,78 s | 0,75 s–0,81 s | 2272 |
Wykres jako obraz. Możesz go użyć na licencji CC BY 4.0, podając Outofplace jako źródło i link do tej strony.
Obie grupy mówią co innego. Za Cloudflare strony ogłaszające HTTP/3 mają niższą medianę TTFB niż te, które go nie ogłaszają: 717 ms wobec 819 ms. Bez CDN różnicy nie ma: 763 ms z ogłaszanym HTTP/3, 759 ms bez. Gdyby TTFB zależał od samego protokołu, widać by to było w obu grupach. Strony za Cloudflare bez HTTP/3 mogą różnić się też planem, cache albo serwerem źródłowym, czego nagłówki nie pokazują. Wykres traktujemy jako kontekst, a nie efekt HTTP/3.
Platformy sklepowe: platforma decyduje za sklep
W sklepach internetowych serwer prowadzi platforma, więc wyborem właściciela sklepu jest platforma. Platformy rozpoznaliśmy klasyfikatorem z naszego badania Core Web Vitals według platformy sklepu. Najwyraźniej widać to na platformach hostowanych, które działają na własnych serwerach.
| Platforma sklepu | Sklepy | Ogłaszają HTTP/3 | Brotli lub zstd | Za Cloudflare |
|---|---|---|---|---|
| PrestaShop | 557 | 63% | 68% | 44% |
| WooCommerce | 384 | 68% | 67% | 45% |
| Shoper | 227 | 31% | 36% | 34% |
| Sklep autorski | 224 | 37% | 48% | 37% |
| IdoSell | 217 | 2,3% | 2,3% | 2,3% |
| Magento | 202 | 46% | 69% | 69% |
| Inne platformy | 173 | 30% | 45% | 27% |
| Shopify | 127 | 99% | 100% | 100% |
| headless | 44 | 36% | 52% | 48% |
| AtomStore | 36 | 22% | 31% | 31% |
Sklepy na Shopify stoją za Cloudflare i mają jedno i drugie. Prawie wszystkie sklepy na IdoSell w próbie odpowiadały z nginx, z gzipem i bez HTTP/3. Sklepy na Shoperze dzielą się według tego, czy stoją za Cloudflare, a platformy open source (PrestaShop, WooCommerce) według hostingu.
Jak włączyć HTTP/3 i kompresję Brotli
Sprawdź, co wysyła twoja strona
Pobierz stronę tak, jak robi to przeglądarka, i przeczytaj nagłówki:
curl -sI -H 'Accept-Encoding: zstd, br, gzip' https://www.example.pl/ | grep -iE '^(content-encoding|alt-svc|server|cf-ray):'content-encoding: brlubzstdoznacza nowoczesną kompresję; liniaalt-svczh3oznacza ogłaszane HTTP/3. W Chrome DevTools kolumna Protocol w panelu Network pokazujeh3przy żądaniach, które go użyły.Za Cloudflare włącz przełącznik
HTTP/3 to przełącznik w panelu (Speed, Settings, Protocol Optimization), dostępny w każdym planie według dokumentacji HTTP/3 w Cloudflare (otwiera się w nowej karcie). Kompresja idzie za ustawieniem domyślnym planu; regułą kompresji można je zmienić.
Na LiteSpeedzie otwórz port UDP 443
Według dokumentacji LiteSpeed QUIC jest włączony domyślnie; potrzebuje otwartego portu UDP 443 i zaufanego certyfikatu. Gdy brakuje
alt-svc, zapytaj hosting.Na nginx wbuduj HTTP/3 i dodaj Brotli
Zbuduj nginx 1.25 lub nowszy z
--with-http_v3_module, dodajlisten 443 quic reuseport;obok nasłuchu TLS i wysyłajAlt-Svc: h3=":443"; ma=86400. Brotli wymaga modułu spoza rdzenia. Jeśli zostajesz przy gzipie, podnieśgzip_comp_levelz domyślnego 1 do 5 lub 6 i wymień typy tekstowe wgzip_types.Na Apache włącz mod_brotli, a dla HTTP/3 postaw CDN
AddOutputFilterByType BROTLI_COMPRESS text/html text/css text/javascript application/javascriptwłącza Brotli dla tekstu. Apache nie ma HTTP/3, więc żeby je zaoferować, potrzebny jest CDN lub proxy, które je obsługuje.Zostaw gzip i wysyłaj Vary
Nie każdy klient prosi o Brotli lub zstd. Zostaw gzip jako zapas i wysyłaj
Vary: Accept-Encoding, żeby cache trzymał osobną kopię dla każdego kodowania. 13% skompresowanych stron głównych w naszej próbie go nie wysłało.
| Kto odpowiedział | Strony | Ogłaszają HTTP/3 | Brotli lub zstd | Skompresowane w ogóle |
|---|---|---|---|---|
| Cloudflare | 2563 | 79% | 96% | 100% |
| Apache, bez CDN | 1767 | 5,7% | 7% | 90% |
| nginx, bez CDN | 1547 | 4,2% | 6,5% | 94% |
| LiteSpeed, bez CDN | 675 | 96% | 82% | 99% |
| Bez nagłówka Server, bez CDN | 399 | 11% | 13% | 82% |
| Inny CDN | 284 | 31% | 37% | 93% |
| Inne serwery, bez CDN | 192 | 31% | 27% | 89% |
| dcsaas (Shoper), bez CDN | 145 | 0% | 0% | 100% |
| IdeaWebServer, bez CDN | 143 | 9,8% | 0% | 99% |
| Microsoft IIS, bez CDN | 70 | 1,4% | 1,4% | 67% |
Jak mierzyliśmy
Czego te dane nie powiedzą
Jedna odpowiedź na stronę: strona główna, 24 września 2026, z jednego komputera w Polsce. Obrazy, skrypty i arkusze stylów mogą być kompresowane inaczej, a serwer może odpowiadać przeglądarkom inaczej niż naszemu crawlerowi, na przykład wybierając pierwsze kodowanie z listy przeglądarki. Alt-Svc to ogłoszenie; strona może też ogłaszać HTTP/3 w rekordzie DNS HTTPS, którego spis nie czytał, więc udział HTTP/3 to dolna granica dla stron ogłaszających je tylko tam. CDN i serwer pochodzą z nagłówków, które strona może ukryć lub zmienić, więc „bez CDN” znaczy, że żadnego nie było widać. Porównanie TTFB to związek między hostingami, a nie test protokołu.
Ile stron używa HTTP/3?
W polskim internecie 39% z 7785 stron głównych .pl, które odczytaliśmy 24 września 2026, ogłaszało HTTP/3 w nagłówku Alt-Svc. To udział stron, które HTTP/3 oferują, a nie udział żądań nim wysłanych: przeglądarka przełącza się dopiero, gdy zobaczy nagłówek i gdy przepuszczony zostanie ruch UDP.
Brotli czy gzip: co kompresuje lepiej?
Dla HTML-a Brotli. Na 7435 polskich stronach głównych Brotli na poziomie 5 zmniejszało medianową stronę o 10% względem gzipa na domyślnym poziomie 6, a poziom 11 o 20%. Gzip warto zostawić jako zapas dla klientów, którzy o Brotli nie proszą.
Zstd czy Brotli: co lepsze dla stron?
Pod względem rozmiaru Brotli. Na domyślnym poziomie 3 zstd dawało stronę mniej więcej tak dużą jak gzip 6 (-2,4%), a Brotli 5 oszczędzało w medianie 10%, a Brotli 11 z kolei 20%. Atutem zstd jest szybkość: w naszym teście zstd 3 kompresowało 568,1 MB/s, Brotli 5 106,3 MB/s.
Które przeglądarki obsługują kompresję zstd?
Chrome od wersji 123 i Firefox od wersji 126, obie wydane w 2024 roku, przyjmują kodowanie zstd. Serwer musi zachować Brotli lub gzip dla pozostałych klientów, bo zstd może wysłać tylko wtedy, gdy żądanie je wymienia.
Jak sprawdzić, czy strona używa Brotli lub HTTP/3?
Pobierz stronę z nagłówkiem Accept-Encoding i przeczytaj nagłówki odpowiedzi: curl -sI -H 'Accept-Encoding: br, gzip' https://example.pl/ pokaże content-encoding: br, gdy Brotli jest włączone, i linię alt-svc z h3, gdy serwer ogłasza HTTP/3. W Chrome DevTools kolumna Protocol w panelu Network pokazuje h3 przy żądaniach, które go użyły.
Czy HTTP/3 jest szybsze niż HTTP/2?
Nasze dane tego nie rozstrzygają: pokazują, kto HTTP/3 ogłasza, a nie, co robi ono z wizytą. W Chrome UX Report strony za Cloudflare ogłaszające HTTP/3 miały niższą medianę TTFB na telefonach (717 ms) niż strony za Cloudflare bez niego (819 ms). Bez CDN wyniki stron z HTTP/3 i bez niego były takie same: 763 ms i 759 ms, więc różnicę lepiej tłumaczy konfiguracja niż sam protokół.