A CDN is a network of servers that keeps copies of your files close to your visitors. Useful, and widely misunderstood: it is not a substitute for decent hosting, and it is not a fix for a slow site.
A CDN shortens the distance a response travels. It does not shorten the time your server spends producing that response. If the bottleneck is a slow query, a plugin firing 400 queries per page load, or a shared plan with two PHP workers, the CDN will deliver your slowness to a wider audience, faster.
Here is what falls on each side of that line.
What a CDN actually does
Three things, in order of how much they matter:
- Caches copies of your files at the edge. A visitor in São Paulo gets your logo from a nearby data centre instead of from your server in Frankfurt.
- Terminates the connection close to the user. DNS lookup, TCP handshake and TLS negotiation happen against a nearby node — worth hundreds of milliseconds on a high-latency mobile link, even for content that is not cached.
- Absorbs traffic your origin should never see. Cloudflare reported 6.2 % of global traffic mitigated as potentially malicious or by customer rules in 2025, with 3.3 % stopped specifically by DDoS or WAF rules (Radar 2025 Year in Review).
Image resizing, HTTP/3 and bot management ride on top. Useful, but secondary.
Static vs dynamic: what gets cached by default
A CDN does not cache your website. Out of the box, it caches your assets.
Cloudflare's default cache behaviour is a fair reference point:
- Cached by default: roughly 60 file extensions — images, CSS, JavaScript, fonts, video, PDFs, archives.
- Not cached by default: HTML and JSON. The pages themselves, and the API responses behind them.
- Never cached, whatever the extension: responses with
Cache-Control: private,no-store,no-cacheormax-age=0; any response carrying aSet-Cookieheader; anything requested with a method other thanGET.
That last rule is what quietly disables caching on real websites. A session cookie on the response is enough for the edge to step aside — correct behaviour, and the reason "I turned on the CDN and nothing changed" is such a common report.
You can cache HTML deliberately through cache rules. But it is an opt-in decision with consequences, not a default.
CDN and TTFB: where the milliseconds go
Time to First Byte is a sum, not a number. web.dev breaks it down into redirect time, service worker startup, DNS lookup, connection and TLS negotiation, and the request itself up to the first byte. The target: 0.8 seconds or less, with anything above 1.8 seconds considered poor.
A CDN attacks specific components of that sum:
| TTFB component | Does a CDN help? |
|---|---|
| DNS lookup | Yes — anycast resolves at a nearby node |
| TCP + TLS handshake | Yes, substantially — it terminates at the edge |
| Redirects | Only if you move them to the edge |
| Server processing (cache HIT) | Yes — the origin is never contacted |
| Server processing (cache MISS) | No — origin think-time is unchanged |
| Origin ↔ edge hop | Partly — smart routing trims transit, not compute |
On a cache HIT, a CDN can take TTFB from 600 ms to 30 ms. On a cache MISS for dynamic HTML, it takes 600 ms to roughly 620 ms — you have added a hop. The edge still saves the handshake latency, so total page load usually improves, but server thinking time is untouched.
If your uncached TTFB is 1.5 seconds, a CDN will not fix that. Your origin will.
WordPress and WooCommerce: the cache bypass problem
Content sites cache well. Shops and membership sites are where theory meets the cookie jar.
WordPress sets wordpress_logged_in_* cookies for authenticated users. WooCommerce adds woocommerce_items_in_cart, woocommerce_cart_hash and wp_woocommerce_session_* once a visitor has a session. Any of these means the edge must not serve that page from cache — and a correct setup bypasses /cart/, /checkout/ and /my-account/ outright. Caching those pages would serve one customer's cart to another, which is a privacy incident, not a performance win.
So a shop's traffic splits three ways: anonymous catalogue browsing, which caches beautifully; cart, checkout and account, which always hit the origin at full PHP and database cost; and logged-in staff, who bypass everything — which is why "the site feels fast to visitors but wp-admin is glacial" is such a familiar complaint.
The moment your conversion rate depends on checkout speed, you are buying origin capacity, not edge capacity. The WordPress hosting checklist covers what that origin needs, and the WordPress hosting comparison lets you filter plans on it.
What a CDN cannot fix
| Symptom | Root cause | Does a CDN help? |
|---|---|---|
| High TTFB on uncached pages | Slow PHP, slow queries, undersized plan | No |
| Checkout takes 4 seconds | Dynamic path, no cache possible | No |
| wp-admin is slow | Logged-in traffic bypasses cache | No |
| Site falls over during a campaign | PHP workers exhausted at origin | Partly — cacheable traffic only |
| Database CPU pegged at 100 % | Query load, missing indexes, no object cache | No |
| Origin is down | No content to serve | Only with an explicit always-online mode |
| Images are 4 MB each | Unoptimised assets | Yes, with edge image optimisation |
| Bandwidth bill is enormous | Repeated asset delivery from origin | Yes |
| Visitors abroad wait 2 s for first byte | Network distance | Yes |
| Scraper traffic floods the server | Automated traffic | Yes |
Read that twice before buying an upgrade. Roughly half the complaints people bring to a CDN are origin problems.
When the answer is a better origin
Look at your hosting instead when:
- Uncached TTFB is above ~0.8 s on a warm server. The application or the plan is the constraint.
- Traffic is mostly logged in — dashboards, forums, membership sites, LMS platforms.
- The database is the bottleneck. No edge network has ever made a full table scan faster.
- PHP workers queue under load. Two workers will time out under 200 concurrent checkouts, CDN or no CDN.
- You already cache HTML at the edge and the uncacheable paths are still slow.
At that point it is a capacity decision: a larger shared plan, a VPS, or managed cloud. Shared hosting vs VPS vs cloud vs managed WordPress lays out where each tier stops being enough; the cloud hosting comparison and VPS comparison cover the options with room to scale.
The healthy mental model: the CDN is the delivery network, the host is the factory. Faster trucks do not help if the factory takes an hour per unit.
Where a CDN is clearly worth the money
The wins are real, and often cheap:
- Global audiences. If a meaningful share of traffic sits outside your server's region, the handshake savings alone justify it.
- Media-heavy sites. Images, video and downloads are what edge caching is built for.
- Bandwidth costs. Offloading static assets frequently pays for the CDN outright.
- DDoS and bot pressure. Absorbing this at the edge protects an origin that could never survive it.
- Mobile visitors. 43 % of requests came from mobile devices globally in 2025, up from 41 % in 2024 (Cloudflare Radar) — and high-latency links are where nearby termination helps most.
- Protocol modernisation. HTTP/3 accounted for 21 % of requests in 2025; an edge network is the easiest way to get it.
One footnote: once a CDN fronts your site, tools that detect "who hosts this" report the CDN, not your provider. This guide explains how to see past the proxy.
FAQ
Can a CDN replace hosting?
No. A CDN has no application, no database and, by default, no copy of your HTML. Static-site hosting on an edge platform can look like it does — but there is still an origin, it is just a build artefact rather than a running server.
Will a free CDN plan actually make my site faster?
For static assets and distant visitors, yes, measurably. For a slow database-driven page, no. Treat free tiers as a delivery improvement, not a performance fix.
Does a CDN improve Core Web Vitals?
It helps LCP when the largest element is a cacheable image, and everything that depends on connection setup. It does nothing for INP, which is dominated by JavaScript on the visitor's device, and nothing for CLS.
Should I cache HTML at the edge?
For a blog with anonymous readers, yes — it is the biggest single win available. For anything with logins or carts, only with correct bypass rules for session cookies and account paths.
Is a CDN worth it if all my visitors are in one country?
Less so for latency, still useful for bandwidth offload, DDoS protection and TLS termination. The performance case weakens the more concentrated your audience is around your server.
What to do next
Measure before you buy. Load an uncached page — a logged-in view, or a URL with a random query string — and look at TTFB. Comfortably under 0.8 seconds means a CDN will make the site meaningfully faster for distant visitors. Well over, and the CDN is treating a symptom.
If that is where you landed, start with the web hosting comparison and filter on what actually changes uncached response time: PHP version, worker counts, object cache and database resources.
