CDN market share in Poland, and what it does to TTFB
Cloudflare answers a third of 7,785 .pl homepages, yet most pass HTML to the origin, and their phone TTFB matches sites without a CDN. Cached ones are faster.
Cloudflare is the CDN of the Polish web: its headers show on 33% of the homepages of 7,785 .pl sites in the Tranco list of popular domains (opens in a new tab), which is 87% of every site showing any CDN. Far behind and close to each other come Amazon CloudFront (110 sites) and the CDN of nazwa.pl, a Polish host (97). Akamai and Fastly, large CDNs worldwide, sit in front of a few dozen .pl homepages between them.
The first byte behind Cloudflare is no faster on average. On phones, real Chrome users waited a median 756ms for it on Cloudflare sites (the 75th percentile of each site) and 760ms on sites without a CDN. The reason shows in Cloudflare's own header. 88% of its homepages were passed on to the origin server, and only the 10% served from its cache had a faster first byte. This is the same census we used for HTTP/3 and Brotli on Polish sites, read here for who answers and from where.
- 7,785
- 33%
- 88%
- 756ms
What a CDN is and how it works
A CDN (content delivery network) is a set of servers, called edges, spread across cities. A visitor's browser connects to the nearest one instead of the site's own server, the origin. The edge can answer from its cache, when it holds a fresh copy of the file, or pass the request on to the origin and relay the answer. Either way it ends the visitor's connection close by, and can filter attacks and speak newer protocols on the site's behalf.
CDN vs hosting: what's the difference?
A CDN doesn't replace hosting. Whatever the edge can't answer from its cache, the origin still has to produce, and for most sites that includes the HTML page itself. Static files (images, scripts, fonts) are what a CDN caches without being told to.
CDN market share in Poland: which CDNs serve Polish sites?
38% of the homepages named a CDN in their headers. We found 14 networks, and one of them carries nearly nine in ten of those sites.
Cloudflare fronts a third of Polish homepages below the top 100
CDN named in the homepage's response headers, .pl sites by place in the Tranco list · n per row in the table · CDNs with fewer than 30 sites in CrUX folded into Other CDNs
- Cloudflare
- Amazon CloudFront
- nazwa.pl CDN
- Other CDNs
- No CDN in the headers
Show the data
| Item | Cloudflare | Amazon CloudFront | nazwa.pl CDN | Other CDNs | No CDN in the headers | n |
|---|---|---|---|---|---|---|
| All sites | 33% | 1.4% | 1.2% | 2.4% | 62% | 7,785 |
| Top 100 | 22% | 10% | 0% | 9% | 59% | 100 |
| Ranks 101–1,000 | 34% | 3.3% | 0.4% | 4.3% | 58% | 900 |
| Below 1,000 | 33% | 1% | 1.4% | 2% | 63% | 6,785 |
The chart as an image, free to reuse under CC BY 4.0 with credit to Outofplace and a link to this page.
Cloudflare's share is lower at the very top: 22% of the top 100, against 34% of the next 900 and 33% below them; the 95% intervals of the top 100 and the rest don't overlap. The top 100 lean on other networks instead. Amazon CloudFront answers 10% of the top 100 and the smaller CDNs together 9%, while nazwa.pl's CDN is absent there. Its 97 sites are almost all below the top 1,000.
Is Cloudflare or Akamai bigger?
On Polish homepages, Cloudflare by two orders of magnitude: 2,563 sites against 24 for Akamai and 25 for Fastly. That is a count of sites, not of traffic or revenue, and our census sees only who answers the HTML of a homepage. A site that sends its images through Akamai and its pages from its own server counts here as "no CDN".
| CDN | Sites | Share of all | In the top 100 | Ranks 101–1,000 |
|---|---|---|---|---|
| No CDN in the headers | 4,832 | 62% | 59 | 522 |
| Cloudflare | 2,563 | 33% | 22 | 305 |
| Amazon CloudFront | 110 | 1.4% | 10 | 30 |
| nazwa.pl CDN | 97 | 1.3% | 0 | 4 |
| Google Cloud load balancer | 30 | 0.4% | 0 | 6 |
| Bunny CDN | 27 | 0.4% | 4 | 7 |
| Fastly | 25 | 0.3% | 0 | 4 |
| Akamai | 24 | 0.3% | 3 | 5 |
| Azure Front Door | 24 | 0.3% | 1 | 4 |
| Imperva | 22 | 0.3% | 0 | 9 |
| Vercel | 14 | 0.2% | 1 | 1 |
| Hostinger CDN | 9 | 0.1% | 0 | 0 |
| Sucuri | 5 | 0.1% | 0 | 3 |
| Netlify | 2 | 0% | 0 | 0 |
| DDoS-Guard | 1 | 0% | 0 | 0 |
Where the CDN answers from: Warsaw, mostly
Four of the CDNs write the edge location that answered into a header: Cloudflare in cf-ray (a code such as -WAW), CloudFront in X-Amz-Cf-Pop, nazwa.pl in X-CDN-nazwa.pl-location, and Fastly in X-Served-By. For our client in Poland, almost every answer came from Warsaw.
| CDN | Edge that answered | Sites | Share of the CDN's sites |
|---|---|---|---|
| Cloudflare | Warsaw (WAW) | 2,561 | 100% |
| Cloudflare | Frankfurt (FRA) | 1 | 0% |
| Cloudflare | London (LHR) | 1 | 0% |
| Amazon CloudFront | Warsaw (WAW) | 107 | 97% |
| Amazon CloudFront | Frankfurt (FRA) | 3 | 2.7% |
| nazwa.pl CDN | Warsaw (WAW) | 97 | 100% |
| Fastly | Vienna (VIE) | 14 | 56% |
| Fastly | Berlin (BER) | 9 | 36% |
| Fastly | Marseille (MRS) | 2 | 8% |
Cloudflare answered 2,561 of its 2,563 homepages from Warsaw. Fastly never answered us from Poland: its 25 sites came from Vienna, Berlin and Marseille. This is where each network sent one machine on one day; a visitor elsewhere in Poland, or on another network, may reach another edge.
Does Cloudflare cache HTML?
Not unless it is told to. Cloudflare's documentation on default cache behaviour (opens in a new tab) (updated 14 September 2026) says "the Cloudflare CDN does not cache HTML or JSON by default"; it caches by file extension, images, scripts, fonts and the like. Cloudflare marks its answers with a cf-cache-status header, and Cloudflare's page on cache responses (opens in a new tab) says what each value means. DYNAMIC means Cloudflare "determined at request time that the asset is not eligible for cache", and BYPASS that the origin's response turned out not to be cacheable.
Most CDNs pass a Polish homepage's HTML on to the origin
Cache status of the homepage HTML in each CDN's own header (cf-cache-status, X-Cache, X-CDN-nazwa.pl-cache) · n per row in the table
- From the edge's cache
- Cacheable, fetched this time
- Passed to the origin
- No cache header
Show the data
| Item | From the edge's cache | Cacheable, fetched this time | Passed to the origin | No cache header | n |
|---|---|---|---|---|---|
| Cloudflare | 10% | 0.8% | 88% | 1% | 2,563 |
| Amazon CloudFront | 40% | 60% | 0% | 0% | 110 |
| nazwa.pl CDN | 30% | 24% | 0% | 46% | 97 |
| Other CDNs | 17% | 9.8% | 13% | 60% | 183 |
The chart as an image, free to reuse under CC BY 4.0 with credit to Outofplace and a link to this page.
Behind Cloudflare, 85% of homepages came back DYNAMIC and 2.6% BYPASS. Most sites, in other words, use Cloudflare as a relay for their HTML and let it cache only the files it caches anyway. CloudFront served 40% of its homepages from cache, and nazwa.pl 30%. Another 46% of nazwa.pl's homepages came without its cache header, so we can't tell. nazwa.pl's help page on its CDN headers (opens in a new tab) says the site's Cache-Control header decides.
Does Cloudflare improve TTFB?
TTFB (time to first byte) is how long a browser waits from asking for a page until the first byte of the answer arrives. It includes setting up the connection and, behind a CDN, the edge's own trip to the origin when it can't answer from cache. We looked at it two ways: the census's own timings, one request per site from Poland, and the phone TTFB that real Chrome users saw.
From Poland, a cached homepage waits a third as long for its first byte
Median wait from sending the request to the first byte, in ms, after the connection was set up · census client in Poland, one request per homepage · 95% bootstrap intervals
Show the data
| Item | Value | Range | n |
|---|---|---|---|
| No CDN | 208ms | 201ms–218ms | 4,832 |
| Cloudflare, HTML passed on | 229ms | 215ms–242ms | 2,251 |
| Cloudflare, HTML from cache | 63ms | 59ms–70ms | 266 |
| CloudFront, miss | 260ms | 172ms–320ms | 66 |
| CloudFront, hit | 64ms | 52ms–90ms | 44 |
| nazwa.pl CDN | 202ms | 121ms–318ms | 97 |
| Other CDNs | 173ms | 137ms–217ms | 183 |
The chart as an image, free to reuse under CC BY 4.0 with credit to Outofplace and a link to this page.
The census separates the two halves. Setting up the connection (DNS, TCP and TLS) took a median 90ms to Cloudflare's Warsaw edge, against 141ms to servers without a CDN. The wait after the request depends on the cache. When Cloudflare answered from its cache, the first byte came after a median 63ms. When it passed the page on, after 229ms, no shorter than the 208ms of a server without a CDN. CloudFront shows the same split between hits and misses.
Real users show the same pattern, with less of a gap. The Chrome UX Report has a phone record for 6,076 of the sites, from the 28 days to 22 September 2026.
Behind Cloudflare, only a cached homepage has a lower phone TTFB
Median of the origins' TTFB p75 on phones, in seconds · CrUX, 26 Aug to 22 Sept 2026 · 95% bootstrap intervals · n per row in the data
Show the data
| Item | Value | Range | n |
|---|---|---|---|
| No CDN | 0.76s | 0.74s–0.78s | 3,552 |
| Cloudflare, HTML passed on | 0.77s | 0.74s–0.8s | 1,896 |
| Cloudflare, HTML from cache | 0.65s | 0.57s–0.69s | 243 |
| CloudFront, miss | 0.71s | 0.62s–0.86s | 63 |
| CloudFront, hit | 0.7s | 0.53s–0.78s | 43 |
| nazwa.pl CDN | 0.66s | 0.55s–0.84s | 69 |
| Other CDNs | 0.76s | 0.71s–0.83s | 174 |
The chart as an image, free to reuse under CC BY 4.0 with credit to Outofplace and a link to this page.
Taken whole, Cloudflare sites and sites without a CDN are level. The difference of the medians is -4ms, with a 95% interval from -40ms to 28ms. Split by the cache, they aren't. Cloudflare sites whose homepage came from its cache had a median of 654ms, those passed on 771ms, a difference of -117ms (interval -219ms to -66ms). The gap is smaller than in the census, probably because a phone's TTFB also holds redirects, DNS and the mobile network, which no cache shortens.
What is a good TTFB?
web.dev's guide to TTFB (opens in a new tab) calls 0.8 seconds or less good and anything over 1.8 seconds poor, as "a rough guide", and adds that TTFB isn't a Core Web Vital. By that line, 53% of Polish sites without a CDN had a good phone TTFB at the 75th percentile, 52% of Cloudflare sites passing their HTML on, and 64% of those serving it from Cloudflare's cache. The first byte is the start of Largest Contentful Paint, the loading metric Polish law firm websites fall short on most often.
The first byte isn't the page: LCP behind a CDN
Largest Contentful Paint, the Core Web Vital for loading, starts after the first byte and adds everything the page then fetches. A faster first byte doesn't carry over to it here. Cloudflare sites had a median LCP p75 86ms higher than sites without a CDN (interval 40ms to 142ms). Caching the HTML made no difference we could measure: the interval of that difference runs from -172ms to 62ms.
This gap is not adjusted for what sits behind Cloudflare: 36% of its homepages are online shops, including all 127 Shopify shops in the sample, and we didn't compare page types across the groups. For how shop platforms compare on LCP, see Core Web Vitals of Polish online shops.
| Group | Origins in CrUX | Median TTFB p75 | Good TTFB | Median LCP p75 | Good LCP | Connection set-up | Wait for the first byte |
|---|---|---|---|---|---|---|---|
| No CDN | 3,552 | 760ms | 53% | 1,691ms | 85% | 141ms | 208ms |
| Cloudflare, HTML passed on | 1,896 | 771ms | 52% | 1,785ms | 80% | 90ms | 229ms |
| Cloudflare, HTML from cache | 243 | 654ms | 64% | 1,725ms | 83% | 92ms | 63ms |
| Cloudflare, miss or no status | 36 | 771ms | 56% | 1,863ms | 86% | 75ms | 131ms |
| CloudFront, miss | 63 | 705ms | 57% | 1,693ms | 78% | 109ms | 260ms |
| CloudFront, hit | 43 | 696ms | 65% | 1,948ms | 81% | 130ms | 64ms |
| nazwa.pl CDN | 69 | 660ms | 59% | 1,549ms | 86% | 88ms | 202ms |
| Other CDNs | 174 | 757ms | 55% | 1,883ms | 73% | 142ms | 173ms |
Do I need a CDN if my visitors are in Poland?
For the HTML, our data shows a faster first byte only where the CDN caches it. Our numbers say an edge in Warsaw sets up the connection faster than the average Polish server, and then waits for that same server whenever it passes the page on. In our data, sites whose CDN relays the HTML had the same first byte as sites without one, and only sites served from the CDN's cache had a faster one. Those are different sites, so this isn't the effect of switching caching on, but a cache hit is the one case where the trip to the origin is skipped.
The other reasons for a CDN don't depend on the HTML: images and scripts served from the edge, protection against attacks, and modern protocols and compression. Behind Cloudflare, most Polish homepages come with HTTP/3 and Brotli or zstd.
How to check whether your CDN caches your HTML
Read the cache header
Ask for your homepage the way a browser does and look at the CDN's own headers:
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: HITmeans Cloudflare answered from its cache,DYNAMICthat it passed the request on. CloudFront writesHit from cloudfrontorMiss from cloudfrontinx-cache, nazwa.plHITorMISSinX-CDN-nazwa.pl-cache. Ask twice: the first request after a change may be a miss.Decide whether your HTML can be cached
A page can be cached at the edge when every visitor gets the same HTML: no name in the header, no basket count printed into the page, no prices that depend on who asks. A shop or a logged-in area usually needs to keep visitors with a session cookie out of the cache, or load those parts with JavaScript after the page.
On Cloudflare, add a Cache Rule
A Cache Rule set to "Eligible for cache" for your HTML paths, with an Edge TTL, makes Cloudflare keep the page (the rule's settings (opens in a new tab)). Cache Rules are available on the Free plan (opens in a new tab), up to 10 of them (read 15 October 2026). Add a second rule with "Bypass cache" for requests that carry your session cookie, and purge the cache when you publish.
On other CDNs, send Cache-Control
CloudFront takes
max-ageors-maxagefrom the origin'sCache-Control, within the minimum and maximum TTL of its cache policy, as AWS's page on cache expiration (opens in a new tab) explains; nazwa.pl's help page says the same header steers its cache.Cache-Control: public, max-age=0, s-maxage=300lets shared caches keep the page for five minutes while browsers ask again each time.Measure again after four weeks
CrUX reports 28 days of visits, so the effect of a change shows fully about a month later. Compare the phone TTFB p75 in PageSpeed Insights or the CrUX API before and after.
How we measured
What this data can't tell you
One response per site: the homepage, on 24 September 2026, from one machine in Poland, during a crawl with several sites in flight. Images, scripts and other pages may come from other hosts and other CDNs, so "no CDN" means none showed in the homepage's headers. Google Cloud's Via: 1.1 google names a load balancer that may or may not cache. The edges are where each network sent our machine, not every Polish visitor. CrUX counts Chrome users wherever they are, not only in Poland. We can't see a site's plan, its cache settings or where its origin server stands, so the comparisons between groups are correlations, not effects of a provider.
Which CDN has the largest market share in Poland?
Cloudflare, by far. On 24 September 2026 its headers showed on 33% of the 7,785 .pl homepages we read, 87% of all those showing any CDN. Amazon CloudFront came second with 110 sites and the Polish host nazwa.pl's own CDN third with 97.
What percentage of websites use Cloudflare?
Of the .pl sites in the Tranco list of popular domains, 33% answered their homepage through Cloudflare in our census of 24 September 2026. The share is lower at the very top: 22% of the top 100, against 33% of the sites below the top 1,000.
Does Cloudflare cache HTML?
Cloudflare is a CDN, but it doesn't cache HTML by default. Its documentation says its CDN "does not cache HTML or JSON by default", and on the Polish web 88% of the homepages behind Cloudflare were passed to the origin. Only 10% came from its cache. A Cache Rule, available on every plan, can make HTML eligible for caching.
What does cf-cache-status DYNAMIC mean?
It means Cloudflare decided the response was not eligible for its cache and fetched it from the origin server. HTML gets it unless a Cache Rule says otherwise. 85% of the Polish homepages behind Cloudflare came back with DYNAMIC in our census.
Does Cloudflare improve TTFB?
In our data, only Cloudflare sites served from its cache had a lower TTFB. On phones, the median TTFB of Polish sites behind Cloudflare was 756ms against 760ms for sites without a CDN. Cloudflare sites whose homepage came from its cache had a median of 654ms, against 771ms for those passed to the origin.
What is a good TTFB?
TTFB (time to first byte) is the time from sending the request to the first byte of the answer. web.dev's rough guide is 0.8 seconds or less, and over 1.8 seconds is poor; TTFB is not a Core Web Vital itself. Among Polish sites without a CDN, 53% had a phone TTFB p75 within 0.8 seconds; among Cloudflare sites served from its cache, 64%.
Do I need a CDN if my visitors are in Poland?
For the HTML, our data shows a faster first byte only where the CDN caches it. Cloudflare answered our client in Poland from Warsaw and set up connections faster than servers without a CDN, but when the HTML went on to the origin the wait for it was no shorter than without a CDN. The other reasons for a CDN, such as static files, attack protection and modern protocols, still hold.