What is a CDN? What it fixes for speed, and what it does not

CDN stands for content delivery network. A CDN is a set of servers spread around the world that keep copies of your website's files and answer each visitor from the nearest one, instead of making every request travel to your own server. It makes images, CSS, scripts and, with the right rules, whole pages arrive from 20 ms away instead of 150 ms away. It does not make your PHP faster, your database smaller or your JavaScript lighter. For how distance and server time add up to the first byte, see the pillar guide, TTFB: what it is and how to fix a slow server.

This guide is for site owners deciding whether a CDN will fix their speed problem. It separates what a CDN fixes from what it cannot, shows how to tell from a report whether one is in front of a site and doing its job, and covers the settings, including for WordPress, that decide whether it helps or breaks things.

Quick answer

A CDN fixes:

• Distance: static files come from an edge server near the visitor, cutting each round trip from 100-300 ms to 10-40 ms.
• Connection setup: TLS 1.3, HTTP/2 and HTTP/3 at the edge, whatever the origin supports.
• Load and spikes: cached requests never reach your server.
• TTFB of the HTML, but only when you cache pages at the edge: from seconds to tens of milliseconds.
• On most CDNs, compression and image resizing on the fly.

A CDN does not fix:

• An uncached dynamic page (PHP, a database query, a slow API). The edge asks your server and waits like the visitor would.
• Render-blocking CSS and JavaScript, a 2 MB hero image or a slow third-party script. The bytes arrive sooner and still cost the same.
• Layout shifts, long tasks and anything else that happens in the browser.

CDN meaning: the network and its servers

What does CDN stand for? Content delivery network; older texts sometimes say content distribution network, which means the same thing. In web performance, "CDN" always means this, not the currency code for the Canadian dollar.

The CDN network is the whole system: data centres in many cities, called points of presence (PoPs), each linked to the internet's main exchange points. Large CDNs run PoPs in hundreds of cities, and DNS or anycast routing sends each visitor to a nearby one, so a CDN's network map shows where your site can answer from.

A CDN server is one machine in a PoP, also called an edge server. It handles the visitor's connection, holds cached copies of files and pages, and fetches from your server, the origin, when it has no fresh copy. Your own server stays the source of truth; the CDN servers hold copies close to the visitor.

How does a CDN work?

When a site is behind a CDN, its hostname resolves to the CDN's network instead of your server. A visitor in Zagreb connects to an edge server in or near Zagreb; a visitor in Chicago to one near Chicago. The edge checks whether it has a fresh copy of what was asked for. If it has (a cache hit), it answers straight away. If not (a miss), it fetches the file from your server, the origin, relays it and keeps a copy for the next visitor, for as long as the cache headers allow.

Distance matters because every request pays for it. A round trip from Zagreb to Frankfurt takes about 30 ms; to Virginia, 120-150 ms. A first visit needs a DNS lookup, a TCP handshake, a TLS handshake and the request itself before the first byte arrives: three or four round trips, before the server has done any work. Then the page references dozens of files, each needing more round trips. A CDN moves the far end of all of those trips to a city near the visitor.

What the edge cannot do is invent content it does not have. For a WordPress page without caching, the edge asks your server, your server runs PHP for 900 ms, and the edge relays the answer 900 ms later. That is why the same CDN gives two very different results: for a static site or a cached CMS, the whole page comes from the edge and TTFB drops to 20-50 ms almost everywhere; for an uncached page only the images and scripts benefit, and TTFB and LCP barely move.

CDN vs web hosting vs page cache

The three are different layers and you usually want all of them:

A CDN does not replace hosting: your site still needs a server behind it. And it does not replace the server's page cache, because every edge location that has not seen a page yet still asks the origin.

How getReport checks it

The test does a TLS handshake with the site to see which protocol it negotiates, reads the Alt-Svc header for HTTP/3, then loads the page in Chromium and records every response: its protocol, headers and origin. A CDN is recognised from the fingerprints CDNs leave, such as Cloudflare's cf-ray header, CloudFront's x-amz-cf-id, Fastly's x-served-by or Bunny's server: BunnyCDN. A CDN that leaves none (some small ones, or a host's own CDN behind a plain hostname) can read as "no CDN" even though it works; the protocol table still shows its effect.

The TTFB test is the other half: it measures the first byte from Frankfurt with a fresh connection. A site whose origin is in Frankfurt scores well there with or without a CDN; the CDN's value shows for visitors elsewhere, which is why the field TTFB from real Chrome users is the better judge of whether the edge helps.

Setting up a CDN, step by step

1. Decide what you need it for

1. Static files only. Images, CSS, JS and fonts from the edge; HTML still from the origin. Every CDN does this out of the box. It helps LCP and everything after the first byte, but not TTFB.
2. Whole site with edge page caching. The HTML is cached too, for anonymous visitors, and TTFB drops to the edge's response time. It needs rules that exclude pages that differ per visitor.
3. Extras: image optimisation, a web application firewall, bot rules, Early Hints. Useful, but secondary.

If cached pages have a TTFB over 800 ms for far-away visitors, job 2 is the one that matters. If TTFB is fine and LCP is not, job 1 plus image optimisation is enough.

2. Put the site behind it

• Cloudflare (free plan): add the site, switch the domain's nameservers to the two Cloudflare gives you, and set SSL/TLS to "Full (strict)" so the connection to your origin stays encrypted with a valid certificate. Static files are cached by file extension by default; HTML is not.
• Pull CDNs such as Bunny or KeyCDN: create a pull zone pointing at your origin, get a hostname like cdn.example-shop.hr, and serve static files from it. On WordPress, the CDN's own plugin or the CDN tab in a caching plugin rewrites the URLs. HTML stays on the origin, so this is job 1 only.
• Built-in CDNs (Shopify, Netlify, Vercel, most managed WordPress hosts): already in front of everything. Check the headers to confirm.

3. Cache the HTML at the edge, with bypass rules

Edge page caching is the step that moves TTFB, and the one that goes wrong. The rule: cache pages that are the same for everyone, bypass pages that are not. On Cloudflare, create two Cache Rules. The bypass rule goes first in the list:

Rule 1: Bypass
  When:  URI Path starts with "/wp-admin"
     or  URI Path starts with "/cart"
     or  URI Path starts with "/checkout"
     or  URI Path starts with "/my-account"
     or  Cookie contains "wordpress_logged_in"
     or  Cookie contains "woocommerce_items_in_cart"
     or  Cookie contains "wp-postpass"
  Then:  Cache eligibility: Bypass cache

Rule 2: Cache everything
  When:  Hostname equals "example-shop.hr"
  Then:  Cache eligibility: Eligible for cache
         Edge TTL: use cache-control header if present, else 2 hours

The cookie conditions matter most: a logged-in editor or a shopper with something in the cart must always reach the origin, or they get a page cached for anonymous visitors. Cloudflare's Automatic Platform Optimization (APO) for WordPress, a paid add-on on the free plan, sets this up automatically and purges on publish.

Your origin's Cache-Control header is the cleanest way to say how long the edge may keep things: s-maxage applies to shared caches such as a CDN, max-age to browsers.

# nginx: HTML cached at the edge for an hour, not in browsers;
# static files for a year everywhere
location / {
    add_header Cache-Control "public, max-age=0, s-maxage=3600" always;
    # … proxy_pass or fastcgi_pass
}
location ~* \.(css|js|woff2|png|jpg|jpeg|webp|avif|svg|ico)$ {
    add_header Cache-Control "public, max-age=31536000, immutable" always;
}

Browser caching and Cache-Control explains every directive.

4. Purge on publish and on deploy

An edge that keeps HTML for two hours shows the old article for two hours after you publish, unless something tells it to forget. The Cloudflare, LiteSpeed Cache and WP Rocket plugins purge changed URLs when a post is saved. For a static site, purge after each deploy; on Cloudflare that is one API call from CI:

curl -s -X POST "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":true}'

Versioned file names (app.3f9a1c.css) make purging static files unnecessary: new HTML references a URL that was never cached.

5. Let the edge handle TLS and protocols

With the CDN terminating connections, visitors get TLS 1.3, HTTP/2 and HTTP/3 even if the origin only speaks HTTP/1.1. Keep the origin connection encrypted with a valid certificate (Let's Encrypt or the CDN's origin certificate). Any http/1.1 responses left in the http2 finding are then third-party hosts outside your CDN. HTTP/2 and HTTP/3 covers the protocols.

CDN for WordPress

Page caching on the server (LiteSpeed Cache, WP Rocket or the host's cache) and page caching at the edge are two layers, and you want both: the edge serves most visitors, the server cache keeps the misses fast. Keep one plugin in charge of purging both. If you rewrite static file URLs to a CDN hostname, exclude wp-admin and wp-login.php. And turn on edge image optimisation if the CDN has it: a 1.4 MB JPEG hero served as a 90 KB WebP is faster from anywhere. Without it, resize at the source; see the best image size for a website.

On Shopify, Wix and Squarespace the CDN is built in and there is nothing to install. For a custom app, Cache-Control: s-maxage=60, stale-while-revalidate=600 on pages that may be a minute old lets the edge answer instantly and refresh in the background.

How to verify

• The cdn-detected finding names the provider, or the http2 finding shows h2 or h3 for the document.
• A second request shows a cache hit: run curl -sI https://example-shop.hr/ | grep -i -E "cf-cache-status|x-cache|age:" twice; the second should say HIT or show an age above zero.
• Logged in, or with an item in the cart, the same header reads BYPASS or DYNAMIC and the page shows your own content.
• The field TTFB in the speed panel moves under 800 ms over the next month.

Common mistakes

• Caching personalised HTML. A customer sees someone else's name or cart. Put bypass rules for login, cart and session cookies before any cache-everything rule.
• Expecting the CDN to fix an uncached page. TTFB is unchanged after "adding Cloudflare" because HTML is not cached until you add a rule, and an uncacheable page stays as slow as the origin.
• Double optimisation. Two minifiers or two compressors rewriting the same files cause broken pages. Let one layer do it.
• Forgetting to purge. The old price shows for hours. Purge on publish, or keep HTML edge lifetimes short.
• "Flexible" SSL. The padlock shows, but the edge talks to the origin over plain HTTP. Use Full (strict).
• Judging the CDN from one location. A Frankfurt test of a Frankfurt origin shows no gain; the field TTFB shows what visitors elsewhere get.

Questions people ask

How does a CDN work?

A CDN answers visitors from the edge server nearest to them. When a request arrives, the edge checks whether it holds a fresh copy of the file or page. If it does, it answers immediately; if not, it fetches it from your server, passes it on and keeps a copy for the next visitor for as long as your cache headers allow. Your own server only sees the misses.

Does a CDN help SEO?

Indirectly. Google does not rank a site higher for using a CDN, but a CDN can improve Core Web Vitals, especially LCP and TTFB for visitors far from your server, and page experience is part of how Google evaluates pages. It also keeps the site up under traffic spikes, so Googlebot gets fewer errors. A misconfigured CDN that blocks crawlers or serves stale pages can hurt, so check both.

Is Cloudflare's free plan enough as a CDN?

For most small and medium sites, yes. The free plan caches static files at the edge, serves HTTP/2 and HTTP/3 with TLS 1.3, compresses text and lets you cache HTML with Cache Rules. What it lacks are extras such as automatic image optimisation, which needs a paid plan or add-on. Set SSL/TLS to Full (strict) and add bypass rules before caching any HTML.

What is the difference between a CDN and web hosting?

Web hosting runs your site: it stores the files and database and builds the pages. A CDN sits in front of the host and keeps copies of what the host produces, answering visitors from nearby. You still need hosting with a CDN, and a CDN cannot build pages. Many managed hosts include a CDN in the plan, so you may already have both.

Can a CDN show visitors an outdated page?

Yes, for as long as the cached copy's lifetime allows. If the edge may keep HTML for two hours and nothing purges it, visitors see the old version for up to two hours after an update. Use a plugin or deploy step that purges changed URLs automatically, keep edge lifetimes for HTML short, and use versioned file names for CSS and JavaScript.