CDNs, Caching and the Edge: Where Your Site Should Be Served From

Put a CDN in front of your site, cache your images, CSS and JavaScript at the edge for a year, and leave your HTML on a short cache with a purge hook. That configuration costs between nothing and about fifty dollars a month for most business sites, takes an afternoon, and removes the single most common cause of a slow page for visitors who are not sitting near your server. Everything else in this article is detail and trade-offs.

What a CDN actually changes

A content delivery network keeps copies of your files on servers spread around the world, then answers each visitor from whichever of those servers is closest. That is the entire idea. The benefit is physics rather than cleverness: a request from Nairobi to a server in Frankfurt has to cross roughly 6,000 kilometres and back before a single byte of your page arrives, and no amount of PHP tuning shortens that trip.

There is a second benefit people notice later. The edge absorbs load. If a product launch or a news mention sends ten thousand people to one page in an hour, a cached page is served ten thousand times by the CDN and once by your origin. Your hosting plan never finds out it was busy. For small sites on shared hosting with a fixed number of PHP workers, that is often the difference between a good day and a 503 error.

The third benefit is protocol support you do not have to install. The Web Almanac’s 2024 CDN chapter measured 98% of CDN-served HTML requests on HTTP/2 or better, against 71% of requests served straight from origin servers. Brotli compression showed the same gap: 55.89% of CDN-served content used Brotli, compared with 41.83% from origins, where gzip is still the majority. Putting a CDN in front of an older stack is often the quickest path to modern transport without touching the stack itself.

Caching is the whole trick

Everything good about a CDN comes from the cache, so start by being honest about what can be cached. Images, fonts, stylesheets and compiled JavaScript never change under a given filename if you fingerprint them properly, which means they can sit at the edge for a year. That part is easy and nearly everybody gets it right.

HTML is where it gets interesting, and where most sites quietly give up. A marketing page that changes twice a month is being re-generated by your server on every single visit because the default configuration sends it with no cache headers at all. Give that page a short edge cache, one minute or ten, and add a purge call to whatever publishes your content. Now the CDN answers almost every visitor directly and your origin handles a trickle.

The number to watch is the cache hit ratio: the share of requests the edge answered without asking your server. Under 80% on a content site means something is wrong, usually a cookie, a query string or a Cache-Control: private header leaking from an application framework. A CDN that forwards six requests in ten to your origin has not made your site faster; it has added a hop.

Fix those four and the hit ratio usually climbs above 90% without any further work. If you want the wider picture on why this shows up in revenue rather than just in graphs, our piece on why website speed matters walks through the field data.

What the crawl data says about who uses one

CDN adoption is lopsided in a way worth knowing, because it tells you where the easy wins still are. In the 2024 Web Almanac crawl, 33% of mobile HTML requests came through a CDN and 67% came straight from an origin server. Content loaded from subdomains was at 48%, and third-party content such as analytics and ad scripts was at 75%. In other words, the scripts other companies put on your site are more likely to be served from a nearby edge than your own pages are.

Adoption also tracks popularity closely. The same chapter put CDN usage at 70% for the top 1,000 sites by Chrome UX Report ranking, 69% for the top 10,000 and 60% for the top 100,000, with the figures for smaller sites lower again. The gap has been closing mainly because free tiers and bundled hosting CDNs have made the decision cheaper than the meeting about it.

The provider picture is concentrated. For base HTML requests the Almanac measured Cloudflare at 55%, Google at 23%, Amazon CloudFront at 6%, Fastly at 6% and Akamai at 2%, with Automattic and Vercel each on 1%. That concentration is why a single Cloudflare incident makes the news, and it is a reason to know how to turn your CDN off in a hurry as well as on.

What it costs, in real numbers

Bandwidth is priced per gigabyte delivered, and the spread between vendors is wider than most people expect. These are list prices from each vendor’s own pricing page, read in October 2026. Note the regional multipliers: serving Africa or India costs more than twice what serving Europe costs on Fastly, and the same pattern shows up everywhere.

Run a realistic number through that. A busy small-business site with a lot of imagery might deliver five terabytes a month, almost all of it to Europe and North America. On bunny.net’s standard network that is about $50. On Fastly’s pay-as-you-go rates, after the free 100 GB, it is about $588. Both are real products from serious companies; they are priced for different customers.

Those last two rows need a caveat, because flat plans hide their limits in request counts rather than gigabytes. AWS documents its CloudFront flat-rate plans as Free at $0 for one million requests and 100 GB, Pro at $15 for ten million requests and 50 TB, Business at $200 for 125 million requests, and Premium from $1,000 for 500 million requests. If your site serves a lot of small files, the request ceiling will bite long before the transfer allowance does.

Per gigabyte or per plan: pick the shape that matches your traffic

There are two pricing shapes in this market and the choice between them matters more than the choice of vendor. Metered per-gigabyte pricing is honest and scary: a viral week costs real money, and a misconfigured cache that re-fetches a video file costs more. Flat plans are predictable and sometimes wasteful, and they are the right answer for anybody who would rather not think about it.

One more cost nobody quotes: the egress charge between your origin and the CDN. If your server is on a cloud provider, every cache miss pulls data out of that provider and onto the CDN, and that leg is billed separately unless the two are related. CloudFront pulling from S3 is free. Fastly pulling from the same bucket is not. On a site with a poor hit ratio, that line can outgrow the CDN bill itself.

A cache policy you can live with

A policy that works for the overwhelming majority of business sites fits in four lines. Fingerprinted assets get a one-year immutable cache. HTML gets a short edge cache with an explicit purge on publish. Anything behind a login bypasses the cache entirely, matched on the session cookie rather than the URL. Everything else inherits the HTML rule.

1. Assets: Cache-Control: public, max-age=31536000, immutable for files whose names contain a content hash. Never for files named style.css.
2. HTML: a short edge cache, one to ten minutes, plus a purge webhook from your CMS. Visitors see fresh content; your origin sees one request per interval.
3. Logged-in traffic: bypass on the presence of your session cookie. Match the cookie name explicitly so anonymous visitors keep getting cached pages.
4. Query strings: strip campaign parameters from the cache key. They change nothing about the response and they fragment your cache.

Then measure. The 2025 Web Almanac put 55% of desktop sites and 44% of mobile sites in the good band for time to first byte, meaning under 0.8 seconds. The same chapter found secondary pages pass Core Web Vitals far more often than home pages, 61% against 47% on desktop, which it attributes largely to cached resources being available by then. A good cache policy moves your home page closer to how your second page already behaves.

When the edge earns its complexity

Edge compute runs small pieces of your code in the CDN’s locations rather than at your origin. It is genuinely useful for a narrow set of jobs: redirects and rewrites, geolocation, A/B test assignment, authentication checks on cached content, and stitching a personalised fragment into an otherwise cached page. It is a poor place to put your business logic, because debugging a distributed function is harder than debugging a server.

The pricing is approachable enough to be a trap. Cloudflare’s Workers free plan allows 100,000 requests a day with 10 milliseconds of CPU per invocation. The paid plan has a $5 monthly minimum, includes 10 million requests and 30 million CPU milliseconds, then charges $0.30 per additional million requests and $0.02 per additional million CPU milliseconds. Cloudflare’s own worked example puts a Worker serving 15 million requests at an average 7 milliseconds of CPU at $8.00 a month. Requests to static assets are free and unlimited.

Eight dollars is not the cost. The cost is that a year later part of your routing lives in a dashboard, nobody remembers writing it, and a deployment to your main application stops working for reasons that are not visible in your repository. Use the edge for things that genuinely must happen before the cache, and keep a comment in your codebase saying what is deployed there.

The short version for a small business site

If you run a brochure site, a blog or a small shop and you are not already behind a CDN, turn one on this week. Start with a free or flat plan so the bill cannot surprise you, fingerprint your assets, put a short cache on your HTML, and check your hit ratio a week later. If your audience is spread across continents, that single change will do more for perceived speed than any amount of theme optimisation.

If you deliver a lot of media, price the per-gigabyte options properly before you commit to a flat plan, because the gap between $0.01 and $0.12 per gigabyte compounds fast. And if you are choosing hosting at the same time, read the two decisions together: our guide to web hosting types covers which hosting tiers include a CDN and which expect you to bring your own. Design matters here too, because the heaviest thing on most pages is an image that was never sized for a phone, which is the subject of our mobile-first design guide.

Eudora Technology configures CDNs, cache rules and edge redirects remotely for clients in Europe, the Middle East, Asia, Africa and the Americas, including the part where somebody has to work out which plugin is setting a cookie on every page. Our web development and hosting page explains how that normally runs, and what we hand over at the end so you are not dependent on us to change a cache rule.

If your site is slow for visitors on the other side of the world and you are not sure whether the cache is doing anything, we can audit the headers and the hit ratio and tell you plainly what to change. Get in touch with Eudora Technology to talk about your project.