---
title: "CDN market share in Poland, and what it does to TTFB"
description: "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."
canonical_url: "https://www.outofplace.space/blog/cdn-polish-web"
language: "en"
last_updated: "2026-10-15"
alternates:
  pl: "https://www.outofplace.space/pl/blog/cdn-na-polskich-stronach.md"
---

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

Published 2026-10-15 · Category: Performance · Tags: CDN, Cloudflare, Core Web Vitals, Poland

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](https://tranco-list.eu/list/Y8YYG/full), 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](https://www.outofplace.space/blog/http3-compression-polish-web), read here for who answers and from where.

- Cloudflare answers 33% of .pl homepages, but only 22% of the top 100.
- Cloudflare, CloudFront and nazwa.pl answered our client in Poland almost always from Warsaw; Fastly from Vienna, Berlin or Marseille.
- 85% of homepages behind Cloudflare came back `cf-cache-status: DYNAMIC`: the HTML went to the origin.
- Phone TTFB was the same with Cloudflare as without a CDN; with the HTML from Cloudflare's cache it was a median 117ms lower than with it passed on.

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

Each site's homepage, as our crawler received it on 24 September 2026 from one machine in Poland. The CDN comes from the response headers it leaves (`cf-ray` for Cloudflare, `x-amz-cf-id` for CloudFront, `X-CDN-nazwa.pl-location` for nazwa.pl and so on). A CDN that hides its headers, or one that serves only a site's images and scripts, isn't counted.

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

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

Source: Outofplace census, 24 Sept 2026; Tranco list Y8YYG. Chart: https://www.outofplace.space/data/blog/cdn-polish-web/charts/en/chart-cloudflare-fronts-a-third-of-polish-homepages-below-the-top-100.png Data: https://www.outofplace.space/data/blog/cdn-polish-web/2026-09-24/bands.csv

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

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

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

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

Source: Outofplace census, 24 Sept 2026; Tranco list Y8YYG. Chart: https://www.outofplace.space/data/blog/cdn-polish-web/charts/en/chart-most-cdns-pass-a-polish-homepage-s-html-on-to-the-origin.png Data: https://www.outofplace.space/data/blog/cdn-polish-web/2026-09-24/cache.csv

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

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

Source: Outofplace census, 24 Sept 2026; Tranco list Y8YYG. Chart: https://www.outofplace.space/data/blog/cdn-polish-web/charts/en/chart-from-poland-a-cached-homepage-waits-a-third-as-long-for-its-firs.png Data: https://www.outofplace.space/data/blog/cdn-polish-web/2026-09-24/timings.csv

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)

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

Source: Chrome UX Report (Google, CC BY 4.0); Outofplace census, 24 Sept 2026. Chart: https://www.outofplace.space/data/blog/cdn-polish-web/charts/en/chart-behind-cloudflare-only-a-cached-homepage-has-a-lower-phone-ttfb.png Data: https://www.outofplace.space/data/blog/cdn-polish-web/2026-09-24/vitals.csv

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.

Sites choose a CDN, and whether to cache their HTML, for reasons that also shape their speed: what the page is, what it runs on, what the host is like. Sites that cache their HTML differ from those that don't: among Cloudflare's shops 6.4% came from cache, among its other sites 13%. These are correlations across sites, not the effect of switching a CDN or a cache rule on.

### What is a good TTFB?

[web.dev's guide to TTFB](https://web.dev/articles/ttfb) 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](https://www.outofplace.space/blog/law-firm-websites-poland#how-fast-are-law-firm-websites).

## 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](https://www.outofplace.space/blog/core-web-vitals-polish-ecommerce).

## 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](https://www.outofplace.space/blog/http3-compression-polish-web#brotli-vs-gzip-vs-zstd-what-polish-homepages-come-with).

## How to check whether your CDN caches your HTML

**1. Read the cache header.**
Ask for your homepage the way a browser does and look at the CDN's own headers:

```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` means Cloudflare answered from its cache, `DYNAMIC` that it passed the request on. CloudFront writes `Hit from cloudfront` or `Miss from cloudfront` in `x-cache`, nazwa.pl `HIT` or `MISS` in `X-CDN-nazwa.pl-cache`. Ask twice: the first request after a change may be a miss.

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

**3. 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](https://developers.cloudflare.com/cache/how-to/cache-rules/settings/)). [Cache Rules are available on the Free plan](https://developers.cloudflare.com/cache/how-to/cache-rules/), 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.

**4. On other CDNs, send Cache-Control.**
CloudFront takes `max-age` or `s-maxage` from the origin's `Cache-Control`, within the minimum and maximum TTL of its cache policy, as [AWS's page on cache expiration](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) explains; nazwa.pl's help page says the same header steers its cache. `Cache-Control: public, max-age=0, s-maxage=300` lets shared caches keep the page for five minutes while browsers ask again each time.

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

The sites come from our census of 24 September 2026 by `OutofplaceResearchBot` (see [what our crawler fetches and how to block it](https://www.outofplace.space/bot)), which reads robots.txt first and fetches only the homepage: 8,023 of the 9,208 .pl domains in the Tranco list answered with HTML, and 7,785 distinct sites remained after merging domains that redirect to the same address. For each, we read the headers of the final response. The CDN comes from the signatures our earlier studies use (Cloudflare, CloudFront, Fastly, Akamai, Google Cloud's load balancer, Azure Front Door, Bunny, Imperva, Vercel and others), plus two networks identified by headers their operators document: nazwa.pl's CDN and Hostinger CDN. A site behind two CDNs counts under the first.

The cache status comes from the CDN's own header only: `cf-cache-status` for Cloudflare, `X-Cache` for CloudFront, `X-CDN-nazwa.pl-cache` for nazwa.pl; a homepage without it counts as having no cache header. For the smaller CDNs we read the generic `X-Cache` or `X-Cache-Status`, which a cache at the origin can also send. The census timings are those of the final request on a fresh connection: the connection set-up (DNS, TCP and TLS), and the wait from sending the request to the first byte of the response. The phone TTFB and LCP are each origin's 75th percentile in the Chrome UX Report, fetched for [our study of third-party scripts](https://www.outofplace.space/blog/third-party-scripts-polish-web) for the same origins. The charts show the median of those values per group, with 10,000 bootstrap resamples. A CDN stands on its own when at least 30 of its sites have a CrUX record; the rest are "Other CDNs".

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.

## Further reading

- [Cloudflare: Default cache behavior](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/): Which file extensions Cloudflare caches by default, and why HTML isn't among them.

- [Cloudflare: Cloudflare cache responses](https://developers.cloudflare.com/cache/concepts/cache-responses/): What each cf-cache-status value means, from HIT to DYNAMIC and BYPASS.

- [nazwa.pl: Nagłówki CDN nazwa.pl](https://www.nazwa.pl/pomoc/baza-wiedzy/naglowki-cdn-nazwa-pl/): The headers nazwa.pl's CDN adds, the edge codes it reports and how Cache-Control steers its cache (in Polish).

- [web.dev: Time to First Byte (TTFB)](https://web.dev/articles/ttfb): What TTFB measures, the 0.8 and 1.8 second guides, and how it relates to the Core Web Vitals.

- [HTTP/3 adoption and Brotli vs gzip on Polish sites](https://www.outofplace.space/blog/http3-compression-polish-web): Which Polish sites advertise HTTP/3 and send Brotli or zstd, and who switched them on.