---
title: "HTTP/3 i kompresja Brotli na polskich stronach"
description: "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."
canonical_url: "https://www.outofplace.space/pl/blog/http3-i-kompresja-brotli-na-polskich-stronach"
language: "pl"
last_updated: "2026-10-14"
alternates:
  en: "https://www.outofplace.space/blog/http3-compression-polish-web.md"
---

# 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.

Opublikowano 2026-10-14 · Kategoria: Wydajność · Tagi: HTTP/3, Kompresja, Polska

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](https://tranco-list.eu/list/Y8YYG/full): 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](https://www.outofplace.space/pl/blog/skrypty-zewnetrzne-na-polskich-stronach), tym razem odczytany pod kątem transportu, a nie treści.

- 39% z 7785 polskich stron głównych ogłasza HTTP/3; za Cloudflare 79%, bez CDN 19%.
- Zstandard dociera do 18% stron, z czego 99% stoi za Cloudflare, którego darmowy plan domyślnie kompresuje zstd.
- Bez CDN 74% stron głównych przychodzi z gzipem, a 8,1% bez kompresji.
- Po ponownej kompresji medianowa strona główna jest o 10% mniejsza z Brotli 5 niż z gzipem 6.

## Czym są HTTP/3 i kodowanie treści

HTTP/3 ([RFC 9114](https://www.rfc-editor.org/rfc/rfc9114.html), 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](https://www.rfc-editor.org/rfc/rfc7932.html), 2016) ściska tekst mocniej; Zstandard ([RFC 8878](https://www.rfc-editor.org/rfc/rfc8878.html)) trafił do Chrome 123, którego [notatki z wersji beta wymieniają kodowanie zstd](https://developer.chrome.com/blog/chrome-123-beta), i do [Firefoksa 126](https://www.firefox.com/en-US/firefox/126.0/releasenotes/), oba w 2024 roku.

`Alt-Svc` mówi, co serwer oferuje. Nie mówi, czy przeglądarka odwiedzającego użyła HTTP/3: nasz crawler rozmawiał po HTTP/1.1 i tylko odczytał nagłówek. Poniższe udziały liczą strony, które HTTP/3 oferują, a nie żądania nim wysłane.

## 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%)

| 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 |

Source: Spis Outofplace, 24 wrz 2026; lista Tranco Y8YYG. Chart: https://www.outofplace.space/data/blog/http3-compression-polish-web/charts/pl/chart-http-3-w-polskim-internecie-niosa-cloudflare-i-litespeed.png Data: https://www.outofplace.space/data/blog/http3-compression-polish-web/2026-09-24/stacks.csv

Dwie grupy się wyróżniają. Za Cloudflare HTTP/3 ogłasza 79% stron, na LiteSpeedzie bez CDN 96%. [Dokumentacja LiteSpeeda](https://docs.litespeedtech.com/lsws/cp/cpanel/quic-http3/) (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](https://nginx.org/en/docs/http/ngx_http_v3_module.html), 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)

| 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 |

Source: Spis Outofplace, 24 wrz 2026; lista Tranco Y8YYG. Chart: https://www.outofplace.space/data/blog/http3-compression-polish-web/charts/pl/chart-za-cloudflare-strony-przychodza-z-zstd-lub-brotli-bez-cdn-zwykle.png Data: https://www.outofplace.space/data/blog/http3-compression-polish-web/2026-09-24/encodings.csv

Za Cloudflare 55% stron głównych przyszło z Zstandardem, a 40% z Brotli. To zgadza się z [dokumentacją kompresji Cloudflare](https://developers.cloudflare.com/speed/optimization/content/compression/) (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](https://nginx.org/en/docs/http/ngx_http_gzip_module.html) jest wyłączony, dopóki ktoś go nie włączy, a Brotli nie ma w rdzeniu nginx; Apache ma [mod_brotli](https://httpd.apache.org/docs/2.4/mod/mod_brotli.html) 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%)

| 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 |

Source: Test Outofplace na spisie z 24 wrz 2026. Chart: https://www.outofplace.space/data/blog/http3-compression-polish-web/charts/pl/chart-brotli-zmniejsza-polskie-strony-glowne-bardziej-niz-gzip-i-zstd.png Data: https://www.outofplace.space/data/blog/http3-compression-polish-web/2026-09-24/codecs.csv

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).

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%)

| 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 |

Source: Chrome UX Report (Google, CC BY 4.0); spis Outofplace, 24 wrz 2026. Chart: https://www.outofplace.space/data/blog/http3-compression-polish-web/charts/pl/chart-za-cloudflare-strony-z-http-3-maja-nizszy-ttfb-na-telefonach-bez.png Data: https://www.outofplace.space/data/blog/http3-compression-polish-web/2026-09-24/ttfb.csv

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](https://www.outofplace.space/pl/blog/core-web-vitals-sklepow-internetowych). Najwyraźniej widać to na platformach hostowanych, które działają na własnych serwerach.

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

**1. Sprawdź, co wysyła twoja strona.**
Pobierz stronę tak, jak robi to przeglądarka, i przeczytaj nagłówki:

```sh
curl -sI -H 'Accept-Encoding: zstd, br, gzip' https://www.example.pl/ | grep -iE '^(content-encoding|alt-svc|server|cf-ray):'
```

`content-encoding: br` lub `zstd` oznacza nowoczesną kompresję; linia `alt-svc` z `h3` oznacza ogłaszane HTTP/3. W Chrome DevTools kolumna Protocol w panelu Network pokazuje `h3` przy żądaniach, które go użyły.

**2. 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](https://developers.cloudflare.com/speed/optimization/protocol/http3/). Kompresja idzie za ustawieniem domyślnym planu; regułą kompresji można je zmienić.

**3. 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.

**4. Na nginx wbuduj HTTP/3 i dodaj Brotli.**
Zbuduj nginx 1.25 lub nowszy z `--with-http_v3_module`, dodaj `listen 443 quic reuseport;` obok nasłuchu TLS i wysyłaj `Alt-Svc: h3=":443"; ma=86400`. Brotli wymaga modułu spoza rdzenia. Jeśli zostajesz przy gzipie, podnieś `gzip_comp_level` z domyślnego 1 do 5 lub 6 i wymień typy tekstowe w `gzip_types`.

**5. Na Apache włącz mod_brotli, a dla HTTP/3 postaw CDN.**
`AddOutputFilterByType BROTLI_COMPRESS text/html text/css text/javascript application/javascript` włącza Brotli dla tekstu. Apache nie ma HTTP/3, więc żeby je zaoferować, potrzebny jest CDN lub proxy, które je obsługuje.

**6. 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.

## Jak mierzyliśmy

Strony pochodzą z naszego spisu z 24 września 2026, wykonanego przez `OutofplaceResearchBot` (zobacz, [co pobiera nasz crawler i jak go zablokować](https://www.outofplace.space/pl/bot)), który najpierw czyta robots.txt i pobiera tylko stronę główną: 8023 z 9208 domen .pl z listy Tranco odpowiedziało HTML-em, a po złączeniu domen przekierowujących pod ten sam adres zostało 7785 różnych stron. Dla każdej odczytaliśmy nagłówki ostatniej odpowiedzi: `Alt-Svc`, parsowany tak, jak zapisuje go RFC 7838, liczony jako HTTP/3, gdy wymienia token `h3`; `Content-Encoding`, po żądaniu z `Accept-Encoding: zstd, br, gzip`; CDN, z nagłówków takich jak `cf-ray`; i rodzinę serwera WWW z `Server`. Platformę sklepu rozpoznaje klasyfikator z naszego badania Core Web Vitals.

W teście HTML każdej strony głównej, w postaci, w jakiej przyszedł, skompresowaliśmy wbudowaną w Node.js biblioteką zlib (gzip 1, 6, 9; Brotli 1, 5, 9, 11 w trybie tekstowym; Zstandard 1, 3, 9, 19). Strona liczy się jako wysłana „co najmniej tak duża jak gzip 1”, gdy jest od tego rozmiaru większa albo mniejsza najwyżej o 0,5%. Rozmiary są deterministyczne; szybkości pochodzą z losowej próby stron (ze stałym ziarnem) kompresowanych po jednej, gdy skrypt nie robił nic innego. TTFB na telefonach to 75. percentyl każdego originu w Chrome UX Report; wykres pokazuje medianę tych wartości w każdej grupie.

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.

## Warto przeczytać

- [RFC 9114: HTTP/3](https://www.rfc-editor.org/rfc/rfc9114.html): Standard HTTP/3, w tym to, jak serwer ogłasza go nagłówkiem Alt-Svc i kiedy klient wraca do TCP.

- [Cloudflare: Content compression](https://developers.cloudflare.com/speed/optimization/content/compression/): Jakie kodowanie Cloudflare wysyła odwiedzającym w każdym planie: zstd w Free, Brotli w Pro i Business, gzip w Enterprise.

- [LiteSpeed: QUIC and HTTP/3 support](https://docs.litespeedtech.com/lsws/cp/cpanel/quic-http3/): Dlaczego HTTP/3 jest domyślnie włączone w LiteSpeed Web Server i jakiego otwartego portu UDP potrzebuje.

- [nginx: Module ngx_http_v3_module](https://nginx.org/en/docs/http/ngx_http_v3_module.html): Eksperymentalny moduł HTTP/3 w nginx, jak go wbudować i jakiego nagłówka Alt-Svc wymaga.

- [Core Web Vitals sklepów: która platforma jest najszybsza?](https://www.outofplace.space/pl/blog/core-web-vitals-sklepow-internetowych): Core Web Vitals polskich sklepów internetowych według platformy, z Chrome UX Report.