What is a CDN and does your website need one?

A CDN (content delivery network) is a network of servers in many locations that keeps copies of your website's files and serves them to visitors from a server near them, instead of sending every request to your own hosting. Most public websites with visitors in more than one region, or with traffic spikes, benefit from one. A CDN does not fix slow code or heavy pages on its own, though, so it helps to know what it actually does before you add one.

How a CDN works

Without a CDN, every visitor talks directly to your origin server, the machine at your hosting provider where your site lives. If that server is in Frankfurt and the visitor is in Sydney, each request travels around the world and back. If a thousand people arrive at once, the origin has to answer all of them.

With a CDN, visitors are routed to an edge server instead. The edge sits between the visitor and your origin and works roughly like this:

1. A visitor requests a page or file.
2. DNS sends them to a nearby edge server.
3. If the edge already has a fresh copy, it answers immediately. This is a cache hit.
4. If not, the edge fetches the file from your origin, delivers it and keeps a copy for the next visitor. This is a cache miss.

The first request for a file is no faster than before. Every following request for the same file, from anyone near that edge, can be served without touching your origin at all. That is where both the speed and the relief for your server come from.

What a CDN caches (and what it shouldn't)

A CDN decides what to store based on response headers from your origin, mainly Cache-Control, plus any rules you configure. The MDN reference for Cache-Control is the best place to look up directives like max-age, s-maxage, private and no-store.

Safe to cache

• Images, CSS, JavaScript and web fonts
• Public HTML pages that look the same for every visitor: blog posts, landing pages, category and product pages in most shops
• Downloads such as PDFs

Must bypass the cache

• Shopping carts, checkout and payment pages
• Account areas and anything shown to logged-in users
• Pages that contain personal data, form tokens or per-user prices
• Admin areas such as /wp-admin

Getting this split right matters more than any other CDN setting. A CDN that caches a logged-in page can show one customer's data to another. Well-built CMS and shop systems mark these responses as private or set cookies that a CDN treats as a signal to bypass. If you run a shop, the guide on speeding up WooCommerce walks through which pages belong in which group.

What a CDN improves

Time to first byte

When a page is served from an edge cache, the visitor gets the first byte without waiting for PHP, a database query or a slow host. That is visible in TTFB, where web.dev recommends 0.8 seconds or less as a rough guide. Our guide on reducing TTFB covers the server-side fixes that complement a CDN.

Distance and latency

Every round trip between browser and server costs time, and physical distance adds to it. Serving from a nearby edge shortens each round trip, which adds up across the DNS lookup, TLS handshake and the many requests a page makes.

Load on your origin

Cache hits never reach your server. During a newsletter send, a sale or a mention on social media, your hosting only has to answer cache misses and dynamic requests, so it is far less likely to slow down in peak times.

Security and availability

Because all traffic passes through the edge, many CDNs also filter attacks there, terminate TLS, and keep serving cached pages while the origin is briefly unreachable. How much of this you get depends on the provider and plan.

What a CDN cannot fix

A CDN is a delivery layer. It makes good pages arrive faster, but it cannot make a heavy page light.

• Slow dynamic pages. Checkout, search and logged-in pages are generated fresh every time. If they are slow, the cause is your application, database or hosting.
• Heavy front-ends. A 4 MB hero image or a stack of third-party scripts is still 4 MB and still has to run in the browser. This shows up in LCP and INP, not in TTFB.
• Layout shift. CLS comes from how the page is built, for example images without dimensions or late-loading banners.
• A misconfigured cache. If your origin sends no-store on everything, or every page sets a session cookie, the CDN will bypass and you gain little.

If your problem is one of these, the fix belongs in the page or the application. A CDN is still useful alongside it, but it is not a substitute. The guide on Core Web Vitals explains which metric points to which cause.

Does your website need a CDN?

A CDN is usually worth it if one or more of these applies:

• Your visitors come from more than one country or continent.
• Your TTFB is high for public pages, especially far away from your host.
• Your server struggles or slows down during traffic spikes.
• You run a CMS or shop where most visits land on pages that are the same for everyone.
• You want DDoS protection and HTTPS handled in front of your hosting.

It matters less if your site is purely local, very small, already served from a fast static host close to your audience, or almost entirely personalized (an internal tool behind a login, for example). In those cases, better hosting or application tuning may bring more than a CDN.

How to test whether it's working

Before you switch anything on, measure. Run a few public pages through corewebvitals.page and note LCP and the other metrics, plus your real-user data if Google has enough of it. The guide on measuring website speed explains how to set up a fair before-and-after comparison.

After the CDN is live, check the response headers of a page you expect to be cached. Request it twice:

curl -sI https://www.example.com/ | grep -i -E 'cache|age'

The first request is often a miss. The second should show a hit in the provider's cache header, and an age that increases. If every request stays a miss or a bypass, look at Cache-Control and Set-Cookie in the origin response. Then repeat your measurements from several locations and compare.

How fast.site helps

fast.site sits in front of your existing hosting, so you keep your host and your CMS. You add your domain in the dashboard, switch your nameservers to fast.site and verify. Propagation is checked automatically, and fast.site takes over DNS for the domain.

Caching is handled by Fast Edge Cache™. On a miss, the edge fetches the page from your origin and stores a copy; on a hit, it answers without contacting your server. Expiry follows your origin's Cache-Control headers or your own rules, and carts, checkout and logged-in sessions bypass the cache. The fs-cache response header shows HIT, MISS or BYPASS, so you can check every page yourself. You can purge by URL in the dashboard or via API, and a cache warmer keeps important pages primed.

Visitors are routed by GeoDNS to the nearest healthy edge in North America, Europe, Asia-Pacific or South America, depending on your plan. Every domain also gets automatic Layer 7 DDoS detection and free, auto-renewed SSL certificates. Details are in the caching docs and on the features page.

Measure your own site before and after. You can start with a free 7-day trial, no credit card needed, and compare plans on the pricing page.

FAQ

Does a CDN replace my web hosting?

No. Your site still lives on your hosting, which remains the origin. The CDN sits in front of it and serves cached copies, but anything dynamic, like a checkout, is still generated by your server.

Is a CDN good for SEO?

Indirectly, it can be. Google uses page experience signals such as Core Web Vitals, and a CDN can improve loading times, especially TTFB and, as a result, often LCP. It does not guarantee better rankings, since content and relevance matter far more.

Can a CDN make my site slower?

It can if it is set up badly. If the CDN bypasses nearly every request, each one takes an extra hop through the edge to your origin. Check the cache headers after setup and make sure public pages actually produce hits.

Do I need a CDN if my visitors are all in one country?

Not necessarily for distance, but often still for load and protection. If your host is close to your audience and handles peaks well, the gain is smaller. If traffic spikes slow your server down, edge caching still helps.

Will a CDN break my shop or login pages?

Not if dynamic pages bypass the cache. Carts, checkout and accounts must never be cached for everyone. Test these flows after setup, logged in and logged out, and confirm the cache header shows a bypass on them.