CDN na polskich stronach: Cloudflare, cache i TTFB

Polski internet ma jeden główny CDN: Cloudflare. Jego nagłówki widać na 33% stron głównych 7785 witryn .pl z listy popularnych domen Tranco (otwiera się w nowej karcie), czyli na 87% wszystkich stron, za którymi widać jakikolwiek CDN. Daleko za nim, blisko siebie, są Amazon CloudFront (110 stron) i CDN polskiego hostingu nazwa.pl (97). Akamai i Fastly, wielkie sieci na świecie, stoją razem przed kilkudziesięcioma stronami głównymi .pl.

Pierwszy bajt za Cloudflare nie przychodzi średnio szybciej. Na telefonach prawdziwi użytkownicy Chrome czekali na niego w medianie 756 ms na stronach za Cloudflare (75. percentyl każdej strony) i 760 ms na stronach bez CDN. Powód widać we własnym nagłówku Cloudflare. 88% jego stron głównych szło dalej, do serwera strony, a szybszy pierwszy bajt miało tylko 10% podanych z cache. To ten sam spis, z którego zrobiliśmy badanie HTTP/3 i Brotli na polskich stronach, tym razem czytany pod kątem tego, kto odpowiada i skąd.

przeczytanych stron głównych

7785

za Cloudflare

33%

z nich przekazuje HTML do serwera

88%

mediana TTFB na telefonach za Cloudflare

756 ms

Co to jest CDN i jak działa

CDN (content delivery network, sieć dostarczania treści) to zbiór serwerów, zwanych węzłami brzegowymi, rozstawionych w wielu miastach. Przeglądarka łączy się z najbliższym z nich zamiast z serwerem strony. Węzeł może odpowiedzieć ze swojego cache, gdy ma świeżą kopię pliku, albo przekazać żądanie dalej do serwera strony i przekazać odpowiedź z powrotem. Tak czy inaczej kończy połączenie odwiedzającego blisko niego, może filtrować ataki i mówić w imieniu strony nowszymi protokołami.

CDN a hosting: jaka różnica?

CDN nie zastępuje hostingu. Wszystko, czego węzeł nie poda z cache, nadal musi przygotować serwer strony, a na większości stron dotyczy to samego dokumentu HTML. Pliki statyczne (obrazy, skrypty, fonty) CDN zapisuje w cache bez proszenia.

Udziały CDN w Polsce: które CDN obsługują polskie strony?

38% stron głównych wskazywało CDN w nagłówkach. Znaleźliśmy 14 sieci, a jedna z nich obsługuje blisko dziewięć na dziesięć tych stron.

• Cloudflare
• Amazon CloudFront
• CDN nazwa.pl
• Inne CDN
• Bez CDN w nagłówkach

Wszystkie stronyn = 778533%62%

Top 100n = 10022%59%

Miejsca 101–1000n = 90034%58%

Poniżej 1000n = 678533%63%

Źródło: Spis Outofplace, 24 wrz 2026; lista Tranco Y8YYGPobierz CSVPobierz PNG

Pokaż dane

Pozycja	Cloudflare	Amazon CloudFront	CDN nazwa.pl	Inne CDN	Bez CDN w nagłówkach	n
Wszystkie strony	33%	1,4%	1,2%	2,4%	62%	7785
Top 100	22%	10%	0%	9%	59%	100
Miejsca 101–1000	34%	3,3%	0,4%	4,3%	58%	900
Poniżej 1000	33%	1%	1,4%	2%	63%	6785

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.

Na samym szczycie udział Cloudflare jest niższy: 22% w top 100 wobec 34% w kolejnych 900 i 33% niżej; 95% przedziały dla top 100 i reszty się nie pokrywają. Top 100 opiera się zamiast tego na innych sieciach. Amazon CloudFront obsługuje 10% top 100, mniejsze CDN razem 9%, a CDN nazwa.pl nie ma tam wcale. Jego 97 stron leży prawie w całości poniżej pierwszego tysiąca.

Cloudflare czy Akamai: który jest większy?

Na polskich stronach głównych Cloudflare, o dwa rzędy wielkości: 2563 strony wobec 24 dla Akamai i 25 dla Fastly. To liczba stron, nie ruchu ani przychodów, a nasz spis widzi tylko, kto odpowiada HTML-em strony głównej. Strona, która wysyła obrazy przez Akamai, a strony ze swojego serwera, liczy się tu jako „bez CDN”.

Skąd odpowiada CDN: głównie z Warszawy

Cztery z tych sieci zapisują w nagłówku, który węzeł odpowiedział: Cloudflare w cf-ray (kod w rodzaju -WAW), CloudFront w X-Amz-Cf-Pop, nazwa.pl w X-CDN-nazwa.pl-location, a Fastly w X-Served-By. Naszemu klientowi w Polsce prawie każda odpowiedź przyszła z Warszawy.

Cloudflare odpowiedział z Warszawy dla 2561 z 2563 swoich stron głównych. Fastly ani razu nie odpowiedział nam z Polski: jego 25 stron przyszło z Wiednia, Berlina i Marsylii. Tak każda sieć pokierowała jedną maszynę jednego dnia; odwiedzający z innego miejsca w Polsce albo z innej sieci może trafić na inny węzeł.

Czy Cloudflare cache'uje HTML?

Nie, dopóki się mu tego nie każe. Dokumentacja Cloudflare o domyślnym zachowaniu cache (otwiera się w nowej karcie) (aktualizacja z 14 września 2026) mówi, że „the Cloudflare CDN does not cache HTML or JSON by default”; zapisuje pliki według rozszerzenia: obrazy, skrypty, fonty i podobne. Cloudflare oznacza swoje odpowiedzi nagłówkiem cf-cache-status, a strona Cloudflare o odpowiedziach cache (otwiera się w nowej karcie) wyjaśnia, co znaczy każda wartość. DYNAMIC znaczy, że Cloudflare „determined at request time that the asset is not eligible for cache”, a BYPASS, że odpowiedź serwera ostatecznie nie nadawała się do cache.

• Z cache węzła
• Do cache, tym razem z serwera
• Przekazane do serwera
• Bez nagłówka cache

Cloudflaren = 256388%

Amazon CloudFrontn = 11040%60%

CDN nazwa.pln = 9730%24%46%

Inne CDNn = 18317%13%60%

Źródło: Spis Outofplace, 24 wrz 2026; lista Tranco Y8YYGPobierz CSVPobierz PNG

Pokaż dane

Pozycja	Z cache węzła	Do cache, tym razem z serwera	Przekazane do serwera	Bez nagłówka cache	n
Cloudflare	10%	0,8%	88%	1%	2563
Amazon CloudFront	40%	60%	0%	0%	110
CDN nazwa.pl	30%	24%	0%	46%	97
Inne CDN	17%	9,8%	13%	60%	183

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 85% stron głównych wróciło z DYNAMIC, a 2,6% z BYPASS. Większość stron używa więc Cloudflare jako przekaźnika HTML-a i pozwala mu cache'ować tylko te pliki, które cache'uje i tak. CloudFront podał z cache 40% swoich stron głównych, nazwa.pl 30%. Kolejne 46% stron głównych nazwa.pl przyszło bez jego nagłówka cache, więc tego nie wiemy. Strona pomocy nazwa.pl o nagłówkach CDN (otwiera się w nowej karcie) mówi, że decyduje o tym nagłówek Cache-Control strony.

Czy Cloudflare przyspiesza stronę?

TTFB (time to first byte) to czas, jaki przeglądarka czeka od poproszenia o stronę do pierwszego bajtu odpowiedzi. Mieści się w nim zestawienie połączenia, a za CDN także droga węzła do serwera strony, gdy nie może odpowiedzieć z cache. Spojrzeliśmy na to dwojako: na czasy samego spisu, jedno żądanie na stronę z Polski, i na TTFB, jaki na telefonach widzieli prawdziwi użytkownicy Chrome.

Bez CDN208 ms

Cloudflare, HTML przekazany dalej229 ms

Cloudflare, HTML z cache63 ms

CloudFront, miss260 ms

CloudFront, hit64 ms

CDN nazwa.pl202 ms

Inne CDN173 ms

0 ms100 ms200 ms300 ms400 ms

Źródło: Spis Outofplace, 24 wrz 2026; lista Tranco Y8YYGPobierz CSVPobierz PNG

Pokaż dane

Pozycja	Wartość	Zakres	n
Bez CDN	208 ms	201 ms–218 ms	4832
Cloudflare, HTML przekazany dalej	229 ms	215 ms–242 ms	2251
Cloudflare, HTML z cache	63 ms	59 ms–70 ms	266
CloudFront, miss	260 ms	172 ms–320 ms	66
CloudFront, hit	64 ms	52 ms–90 ms	44
CDN nazwa.pl	202 ms	121 ms–318 ms	97
Inne CDN	173 ms	137 ms–217 ms	183

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.

Spis rozdziela obie połowy. Zestawienie połączenia (DNS, TCP i TLS) z warszawskim węzłem Cloudflare trwało w medianie 90 ms, z serwerami bez CDN 141 ms. Czekanie po wysłaniu żądania zależy od cache. Gdy Cloudflare odpowiadał z cache, pierwszy bajt przychodził po medianie 63 ms. Gdy przekazywał stronę dalej, po 229 ms, czyli nie szybciej niż 208 ms serwera bez CDN. CloudFront dzieli się tak samo na trafienia i chybienia.

Prawdziwi użytkownicy pokazują ten sam wzór, z mniejszą różnicą. Chrome UX Report ma rekord dla telefonów dla 6076 stron, z 28 dni do 22 września 2026.

Bez CDN0,76 s

Cloudflare, HTML przekazany dalej0,77 s

Cloudflare, HTML z cache0,65 s

CloudFront, miss0,71 s

CloudFront, hit0,7 s

CDN nazwa.pl0,66 s

Inne CDN0,76 s

0 s0,25 s0,5 s0,75 s1 s

Źródło: Chrome UX Report (Google, CC BY 4.0); spis Outofplace, 24 wrz 2026Pobierz CSVPobierz PNG

Pokaż dane

Pozycja	Wartość	Zakres	n
Bez CDN	0,76 s	0,74 s–0,78 s	3552
Cloudflare, HTML przekazany dalej	0,77 s	0,74 s–0,8 s	1896
Cloudflare, HTML z cache	0,65 s	0,57 s–0,69 s	243
CloudFront, miss	0,71 s	0,62 s–0,86 s	63
CloudFront, hit	0,7 s	0,53 s–0,78 s	43
CDN nazwa.pl	0,66 s	0,55 s–0,84 s	69
Inne CDN	0,76 s	0,71 s–0,83 s	174

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.

W całości strony za Cloudflare i strony bez CDN wychodzą na remis. Różnica median wynosi -4 ms, z 95% przedziałem od -40 ms do 28 ms. Podzielone według cache już nie. Strony za Cloudflare, których stronę główną podał z cache, miały medianę 654 ms, przekazane dalej 771 ms, czyli różnicę -117 ms (przedział od -219 ms do -66 ms). Różnica jest mniejsza niż w spisie, prawdopodobnie dlatego, że TTFB telefonu obejmuje też przekierowania, DNS i sieć komórkową, których żaden cache nie skraca.

Jaki TTFB jest dobry?

Przewodnik web.dev po TTFB (otwiera się w nowej karcie) uznaje za dobry wynik do 0,8 sekundy, a za słaby ponad 1,8 sekundy, jako „rough guide”, i dodaje, że TTFB nie jest jednym z Core Web Vitals. Według tej granicy dobry TTFB na telefonach w 75. percentylu miało 53% polskich stron bez CDN, 52% stron za Cloudflare przekazujących HTML dalej i 64% tych, których HTML przyszedł z cache Cloudflare. Pierwszy bajt to początek LCP, czyli ładowania, na którym polskie strony kancelarii odpadają najczęściej.

Pierwszy bajt to nie cała strona: LCP za CDN

Largest Contentful Paint, wskaźnik ładowania z Core Web Vitals, zaczyna się po pierwszym bajcie i dodaje wszystko, co strona potem pobiera. Szybszy pierwszy bajt nie przenosi się tu na LCP. Strony za Cloudflare miały medianę LCP p75 o 86 ms wyższą niż strony bez CDN (przedział od 40 ms do 142 ms). Cache'owanie HTML-a nie dało różnicy, którą umielibyśmy zmierzyć: przedział tej różnicy biegnie od -172 ms do 62 ms.

Ta różnica nie uwzględnia tego, co stoi za Cloudflare: 36% jego stron głównych to sklepy internetowe, w tym wszystkie 127 sklepów na Shopify w próbie, a typów stron między grupami nie porównywaliśmy. Jak wypadają platformy sklepowe w LCP, pokazujemy w badaniu Core Web Vitals polskich sklepów internetowych.

CDN dla strony: czy jest potrzebny, gdy odwiedzający są w Polsce?

Dla HTML-a nasze dane pokazują szybszy pierwszy bajt tylko tam, gdzie CDN go cache'uje. Z naszych danych wynika, że węzeł w Warszawie zestawia połączenie szybciej niż przeciętny polski serwer, a potem czeka na ten sam serwer za każdym razem, gdy przekazuje stronę dalej. W naszych danych strony, których CDN przekazuje HTML dalej, miały taki sam pierwszy bajt jak strony bez CDN, a szybszy tylko te z HTML-em z cache. To różne strony, więc nie jest to efekt włączenia cache, ale trafienie w cache to jedyny przypadek, w którym droga do serwera odpada.

Pozostałe powody, by mieć CDN, nie zależą od HTML-a: obrazy i skrypty podawane z węzła, ochrona przed atakami, nowe protokoły i kompresja. Za Cloudflare większość polskich stron głównych przychodzi z HTTP/3 i Brotli albo zstd, co pokazuje nasze badanie HTTP/3.

Jak sprawdzić, czy CDN cache'uje HTML strony

1. Przeczytaj nagłówek cache

   Poproś o stronę główną tak jak przeglądarka i sprawdź własne nagłówki CDN:

   curl -sI https://www.example.pl/ | grep -iE '^(cf-cache-status|cf-ray|x-cache|x-amz-cf-pop|x-cdn-nazwa\.pl-[a-z]+|age|cache-control):'

   cf-cache-status: HIT znaczy, że Cloudflare odpowiedział z cache, DYNAMIC, że przekazał żądanie dalej. CloudFront pisze w x-cache Hit from cloudfront albo Miss from cloudfront, nazwa.pl w X-CDN-nazwa.pl-cache HIT albo MISS. Zapytaj dwa razy: pierwsze żądanie po zmianie może być chybieniem.

2. Zdecyduj, czy HTML może trafić do cache

   Stronę można cache'ować na węźle, gdy każdy odwiedzający dostaje ten sam HTML: bez imienia w nagłówku, bez liczby produktów w koszyku wpisanej w stronę, bez cen zależnych od tego, kto pyta. Sklep albo strefa po zalogowaniu zwykle musi trzymać odwiedzających z ciasteczkiem sesji poza cache albo doładowywać te części JavaScriptem po stronie.

3. W Cloudflare dodaj regułę cache

   Reguła Cache Rule ustawiona na „Eligible for cache” dla ścieżek HTML, z Edge TTL, sprawia, że Cloudflare zatrzymuje stronę (ustawienia reguły (otwiera się w nowej karcie)). Reguły cache są dostępne w planie Free (otwiera się w nowej karcie), do 10 sztuk (stan na 15 października 2026). Dodaj drugą regułę z „Bypass cache” dla żądań z ciasteczkiem sesji i czyść cache po publikacji.

4. W innych CDN wyślij Cache-Control

   CloudFront bierze max-age albo s-maxage z nagłówka Cache-Control serwera, w granicach minimalnego i maksymalnego TTL swojej polityki cache, jak wyjaśnia strona AWS o wygasaniu cache (otwiera się w nowej karcie); strona pomocy nazwa.pl mówi, że ten sam nagłówek steruje jej cache. Cache-Control: public, max-age=0, s-maxage=300 pozwala współdzielonym cache trzymać stronę pięć minut, a przeglądarki pytają za każdym razem.

5. Zmierz ponownie po czterech tygodniach

   CrUX podaje 28 dni wizyt, więc efekt zmiany widać w pełni po około miesiącu. Porównaj TTFB p75 na telefonach w PageSpeed Insights albo w CrUX API przed zmianą i po niej.

Jak mierzyliśmy

Czego te dane nie powiedzą

Jedna odpowiedź na stronę: strona główna, 24 września 2026, z jednej maszyny w Polsce, w trakcie spisu z kilkoma stronami naraz. Obrazy, skrypty i inne podstrony mogą przychodzić z innych hostów i innych CDN, więc „bez CDN” znaczy, że żadnego nie widać w nagłówkach strony głównej. Via: 1.1 google w Google Cloud oznacza load balancer, który może, ale nie musi cache'ować. Węzły to miejsca, do których każda sieć skierowała naszą maszynę, a nie każdego odwiedzającego z Polski. CrUX liczy użytkowników Chrome, gdziekolwiek są, nie tylko w Polsce. Nie widzimy planu strony, jej ustawień cache ani tego, gdzie stoi jej serwer, więc porównania grup to korelacje, a nie efekty dostawcy.

Dalsza lektura