---
title: "CDN na polskich stronach: Cloudflare, cache i TTFB"
description: "Cloudflare obsługuje co trzecią z 7785 stron .pl, ale większość przekazuje HTML do serwera, a TTFB na telefonach jest jak bez CDN. Szybsze są strony z cache."
canonical_url: "https://www.outofplace.space/pl/blog/cdn-na-polskich-stronach"
language: "pl"
last_updated: "2026-10-15"
alternates:
  en: "https://www.outofplace.space/blog/cdn-polish-web.md"
---

# CDN na polskich stronach: Cloudflare, cache i TTFB

> Cloudflare obsługuje co trzecią z 7785 stron .pl, ale większość przekazuje HTML do serwera, a TTFB na telefonach jest jak bez CDN. Szybsze są strony z cache.

Opublikowano 2026-10-15 · Kategoria: Wydajność · Tagi: CDN, Cloudflare, Core Web Vitals, Polska

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](https://tranco-list.eu/list/Y8YYG/full), 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](https://www.outofplace.space/pl/blog/http3-i-kompresja-brotli-na-polskich-stronach), tym razem czytany pod kątem tego, kto odpowiada i skąd.

- Cloudflare obsługuje 33% stron głównych .pl, ale tylko 22% stron z top 100.
- Cloudflare, CloudFront i nazwa.pl odpowiadały naszemu klientowi w Polsce prawie zawsze z Warszawy; Fastly z Wiednia, Berlina albo Marsylii.
- 85% stron głównych za Cloudflare wróciło z `cf-cache-status: DYNAMIC`: HTML poszedł do serwera strony.
- TTFB na telefonach był z Cloudflare taki sam jak bez CDN; z HTML-em z cache Cloudflare mediana była o 117 ms niższa niż z HTML-em przekazanym dalej.

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

Stronę główną każdej witryny, tak jak dostał ją nasz crawler 24 września 2026 z jednej maszyny w Polsce. CDN rozpoznajemy po nagłówkach odpowiedzi (`cf-ray` dla Cloudflare, `x-amz-cf-id` dla CloudFront, `X-CDN-nazwa.pl-location` dla nazwa.pl i tak dalej). CDN, który ukrywa nagłówki, albo taki, który podaje tylko obrazy i skrypty strony, się nie liczy.

## 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 obsługuje co trzecią polską stronę główną poniżej top 100** (CDN wskazany w nagłówkach odpowiedzi strony głównej, strony .pl według miejsca na liście Tranco · n dla każdego wiersza w tabeli · CDN z mniej niż 30 stronami w CrUX złożone w Inne CDN)

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

Source: Spis Outofplace, 24 wrz 2026; lista Tranco Y8YYG. Chart: https://www.outofplace.space/data/blog/cdn-polish-web/charts/pl/chart-cloudflare-obsluguje-co-trzecia-polska-strone-glowna-ponizej-top.png Data: https://www.outofplace.space/data/blog/cdn-polish-web/2026-09-24/bands.csv

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](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/) (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](https://developers.cloudflare.com/cache/concepts/cache-responses/) 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.

**Większość CDN przekazuje HTML polskiej strony głównej do serwera** (Status cache HTML-a strony głównej we własnym nagłówku każdego CDN (cf-cache-status, X-Cache, X-CDN-nazwa.pl-cache) · n dla każdego wiersza w tabeli)

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

Source: Spis Outofplace, 24 wrz 2026; lista Tranco Y8YYG. Chart: https://www.outofplace.space/data/blog/cdn-polish-web/charts/pl/chart-wiekszosc-cdn-przekazuje-html-polskiej-strony-glownej-do-serwera.png Data: https://www.outofplace.space/data/blog/cdn-polish-web/2026-09-24/cache.csv

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](https://www.nazwa.pl/pomoc/baza-wiedzy/naglowki-cdn-nazwa-pl/) 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.

**Z Polski strona główna z cache czeka na pierwszy bajt trzy razy krócej** (Mediana czekania od wysłania żądania do pierwszego bajtu, w ms, po zestawieniu połączenia · klient spisu w Polsce, jedno żądanie na stronę główną · 95% przedziały bootstrap)

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

Source: Spis Outofplace, 24 wrz 2026; lista Tranco Y8YYG. Chart: https://www.outofplace.space/data/blog/cdn-polish-web/charts/pl/chart-z-polski-strona-glowna-z-cache-czeka-na-pierwszy-bajt-trzy-razy.png Data: https://www.outofplace.space/data/blog/cdn-polish-web/2026-09-24/timings.csv

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.

**Za Cloudflare niższy TTFB na telefonach ma tylko strona główna z cache** (Mediana TTFB p75 originów na telefonach, w sekundach · CrUX, 26 sie – 22 wrz 2026 · 95% przedziały bootstrap · n dla każdego wiersza w danych)

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

Source: Chrome UX Report (Google, CC BY 4.0); spis Outofplace, 24 wrz 2026. Chart: https://www.outofplace.space/data/blog/cdn-polish-web/charts/pl/chart-za-cloudflare-nizszy-ttfb-na-telefonach-ma-tylko-strona-glowna-z.png Data: https://www.outofplace.space/data/blog/cdn-polish-web/2026-09-24/vitals.csv

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.

Strony wybierają CDN, i to, czy cache'ować HTML, z powodów, które wpływają też na ich szybkość: czym jest strona, na czym działa, jaki ma hosting. Strony z HTML-em w cache różnią się od pozostałych: wśród sklepów za Cloudflare z cache przyszło 6,4%, wśród jego pozostałych stron 13%. To korelacje między stronami, a nie skutek włączenia CDN czy reguły cache.

### Jaki TTFB jest dobry?

[Przewodnik web.dev po TTFB](https://web.dev/articles/ttfb) 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](https://www.outofplace.space/pl/blog/strony-kancelarii-prawnych#jak-szybkie-sa-strony-kancelarii).

## 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](https://www.outofplace.space/pl/blog/core-web-vitals-sklepow-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](https://www.outofplace.space/pl/blog/http3-i-kompresja-brotli-na-polskich-stronach#brotli-czy-gzip-czy-zstd-z-czym-przychodza-polskie-strony-glowne).

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

```sh
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](https://developers.cloudflare.com/cache/how-to/cache-rules/settings/)). [Reguły cache są dostępne w planie Free](https://developers.cloudflare.com/cache/how-to/cache-rules/), 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](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html); 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

Strony pochodzą z naszego spisu z 24 września 2026, zrobionego przez `OutofplaceResearchBot` (zob. [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 połączeniu domen przekierowujących pod ten sam adres zostało 7785 różnych stron. Dla każdej czytamy nagłówki ostatniej odpowiedzi. CDN rozpoznajemy po sygnaturach z naszych wcześniejszych badań (Cloudflare, CloudFront, Fastly, Akamai, load balancer Google Cloud, Azure Front Door, Bunny, Imperva, Vercel i inne) oraz po nagłówkach dwóch sieci, które opisują ich operatorzy: CDN nazwa.pl i Hostinger CDN. Strona za dwoma CDN liczy się pod pierwszym.

Status cache bierzemy tylko z własnego nagłówka CDN: `cf-cache-status` dla Cloudflare, `X-Cache` dla CloudFront, `X-CDN-nazwa.pl-cache` dla nazwa.pl; strona główna bez niego liczy się jako bez nagłówka cache. Dla mniejszych CDN czytamy ogólny `X-Cache` albo `X-Cache-Status`, który może wysłać też cache na serwerze strony. Czasy spisu to czasy ostatniego żądania na nowym połączeniu: zestawienie połączenia (DNS, TCP i TLS) i czekanie od wysłania żądania do pierwszego bajtu odpowiedzi. TTFB i LCP na telefonach to 75. percentyl każdego originu w Chrome UX Report, pobrany dla [naszego badania skryptów zewnętrznych](https://www.outofplace.space/pl/blog/skrypty-zewnetrzne-na-polskich-stronach) dla tych samych originów. Wykresy pokazują medianę tych wartości w grupie, z 10 000 losowań bootstrap. CDN ma własną grupę, gdy co najmniej 30 jego stron ma rekord w CrUX; reszta to „Inne CDN”.

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

- [Cloudflare: Default cache behavior](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/): Które rozszerzenia plików Cloudflare cache'uje domyślnie i dlaczego nie ma wśród nich HTML-a (po angielsku).

- [Cloudflare: Cloudflare cache responses](https://developers.cloudflare.com/cache/concepts/cache-responses/): Co znaczy każda wartość cf-cache-status, od HIT po DYNAMIC i BYPASS (po angielsku).

- [nazwa.pl: Nagłówki CDN nazwa.pl](https://www.nazwa.pl/pomoc/baza-wiedzy/naglowki-cdn-nazwa-pl/): Nagłówki, które dodaje CDN nazwa.pl, kody węzłów, które podaje, i jak Cache-Control steruje jego cache.

- [web.dev: Time to First Byte (TTFB)](https://web.dev/articles/ttfb): Co mierzy TTFB, progi 0,8 i 1,8 sekundy i jak ma się do Core Web Vitals (po angielsku).

- [HTTP/3 i kompresja Brotli na polskich stronach](https://www.outofplace.space/pl/blog/http3-i-kompresja-brotli-na-polskich-stronach): Które polskie strony ogłaszają HTTP/3 i wysyłają Brotli lub zstd, i kto to włączył.