Hosting, caching and CDN costs: what small organisations actually pay for

What you are actually paying for

Hosting, caching and a content delivery network (CDN) solve related but different problems. Hosting is where your site or application ultimately runs. Caching reuses a previously generated response instead of rebuilding or downloading it every time. A CDN places delivery infrastructure closer to users and can cache eligible content at its edge locations.

For a small organisation, the most expensive mistake is often not choosing the “wrong” brand. It is paying for a new layer before identifying which layer is slow. A site with an overloaded database will not be fixed merely by putting static images behind a CDN. A well-hosted brochure site serving visitors on several continents may still benefit from edge delivery. And a site can have a CDN enabled while most HTML continues to go back to the origin because the cache rules make it ineligible.

Current provider models illustrate why comparing only the headline monthly fee is misleading. AWS CloudFront documents flat-rate plans with usage allowances as well as pay-as-you-go billing, while Google Cloud CDN separates cache data transfer, cache fill and cache lookups. Prices and allowances change, so compare the billing model you will actually use rather than copying an old price table. See the current CloudFront flat-rate plan documentation, Google Cloud CDN pricing model and, where relevant, your own provider's current terms.

Treat this as four decisions, not one upgrade

Before buying anything, separate four questions:

1. Is the origin slow? The server may be taking too long to generate the initial HTML because of limited resources, slow application code, database work or an overloaded hosting environment.
2. Are repeat requests doing unnecessary work? Browser caching, application caching or server-side page/object caching may reduce repeated computation and downloads.
3. Are users far from the origin? A CDN can reduce network distance and can often serve cached resources closer to visitors.
4. Is the cache configured safely? Personalised, authenticated or rapidly changing responses may need different rules from versioned images, CSS and JavaScript.

A CDN can improve delivery without fixing a slow backend. Conversely, upgrading the host may not help much if the main delay is geographic network latency or large static files. Google's web performance guidance describes Time to First Byte (TTFB) as a useful diagnostic metric and notes that CDNs can improve TTFB by serving content closer to users. TTFB is not itself a Core Web Vital, but slow TTFB adds delay before later rendering milestones. See web.dev's TTFB guidance.

Diagnose the bottleneck before changing the bill

Start with evidence from the current site. The useful comparison is not “cheap host versus premium host”; it is “what happens on a cache hit, what happens on a cache miss, and how long does the origin itself take?”

Check origin response and cache behaviour separately

Measure at least one representative page in both cached and uncached conditions. If a cached response is fast but an origin response is slow, the CDN may be masking an origin problem. That can still be a valid architecture, but it means dynamic pages, cold-cache requests and cache misses remain exposed to the slow backend.

If both cached and uncached responses are slow, look beyond the cache: hosting capacity, database queries, application work, redirects, TLS/network setup and large response generation may all contribute. If the origin is reasonably fast but distant users are slower, edge delivery may have more value.

Do not treat a low cache hit ratio as proof that “the caching is bad”. A low ratio can be caused by short freshness lifetimes, many unique query strings or cookies, fragmented cache keys, infrequently requested content, deliberate bypass rules, personalised responses, or simply a cold cache. AWS defines cache hit ratio as the proportion of cacheable requests served from cache and documents that cache-key design and cache duration affect it. Review CloudFront's cache-hit guidance for a concrete example of these mechanics.

Read the cache policy before changing it

HTTP caching is controlled by response headers as well as CDN-specific rules. The important distinction is between freshness and storage. A fresh cached response can normally be reused without contacting the origin; a stale response may require revalidation.

• max-age defines how long a response is considered fresh for caches that use it.
• s-maxage sets freshness for shared caches such as CDNs and overrides max-age for those shared caches.
• no-cache does not mean “do not store”; it means the stored response must be validated before reuse.
• no-store tells caches not to store the response.
• private is important for responses intended for a single user because it prevents shared caches from storing them.
• Validators such as ETag or Last-Modified allow a stale cached response to be checked without necessarily transferring the whole resource again.

These behaviours are defined by HTTP caching standards and summarised clearly in RFC 9111 and MDN's Cache-Control reference.

There is no universal “72-hour” rule. Cache duration should reflect how content changes and how it is versioned. A fingerprinted asset such as app.8f31c2.js can usually be cached far longer than an HTML page whose contents can change at the same URL.

For example, a versioned static asset may use a long-lived policy:

Cache-Control: public, max-age=31536000, immutable

A frequently updated HTML document may instead be stored but revalidated before reuse:

Cache-Control: no-cache

For shared caching of HTML, the right policy is application-specific. Do not copy a generic public or s-maxage example onto logged-in, account-specific or otherwise personalised pages without confirming that the response is safe to share between users.

When a CDN is worth paying for

A CDN's value also depends on what it serves. Platform-agnostic guidance from web.dev notes that CDNs can reduce server load, handle traffic spikes and improve delivery by using servers closer to users, but the best configuration depends on the site and audience. See the web.dev CDN overview.

A cost-aware implementation roadmap

The safest order is to measure first, make the cheapest reversible change that targets the measured problem, then verify both performance and cost.

Step 1: capture the baseline and map what can be cached

1. Record your current monthly hosting/CDN spend, bandwidth or transfer usage, request volume and any overage charges you can see.
2. Check representative page types: homepage, key service/category page, article/product page and any logged-in or personalised area.
3. Compare real-user data where available with lab tests. PageSpeed Insights and Chrome User Experience Report data can show whether the problem affects real visitors rather than only one synthetic test.
4. Identify static versioned files, frequently changing HTML, API responses and personalised content. They should not all share one caching rule.
5. Record the current response headers and provider cache status for a few URLs before changing them.

If the wider problem is slow server response, oversized assets or other page-speed bottlenecks, use ScanMySEO's guide to diagnosing slow load times and TTFB rather than assuming infrastructure is the only cause.

Step 2: fix cache policy before buying more capacity

Correct obvious cache-control mistakes, unnecessary cache-key variation and accidental bypass rules before upgrading the host. For static versioned assets, long freshness can reduce repeat downloads. For HTML and APIs, choose a policy based on how quickly the content changes and whether it is safe for a shared cache.

If you already use a CDN, verify that the resources you expected to cache actually return hits after the first request. Provider-specific headers such as Cloudflare's CF-Cache-Status can distinguish a hit, miss, bypass or dynamic response; the exact header varies by provider. Cloudflare's cache-status documentation is one example of how to interpret those states.

Step 3: upgrade hosting only when the origin evidence supports it

Move to a higher hosting tier when the data points to origin-side constraints: repeated resource saturation, consistently slow uncached server response, database bottlenecks, concurrency limits or traffic that the current environment cannot handle reliably. A plan upgrade is easier to justify when you can state what resource is constrained and how you will verify that the new tier removed that constraint.

After each change, compare the same URLs and conditions you measured before. If the change improves a synthetic score but not real-user performance, origin load, error rate or business outcomes, do not assume the spend is justified. ScanMySEO's performance verification decision guide covers how to validate a fix without relying on a single before/after test.

Step 4: measure total cost, not just the subscription

For a small organisation, a practical monthly total-cost view is:

Total infrastructure cost =
hosting + CDN/edge delivery + storage/backups + monitoring/security +
paid optimisation features + developer/admin time + expected overage risk

Do not estimate return on investment by applying a generic “conversion lift” benchmark to a faster site. That creates false precision. Use your own data where possible: performance before and after, hosting/CDN bill before and after, error rates, support incidents, capacity headroom, and conversions or revenue only where you can measure them credibly.

A £20 monthly saving that creates fragile cache invalidation may not be a saving. Equally, a premium CDN plan is difficult to justify if an included host-level CDN already serves the same audience well. Operational simplicity has value, especially when the website is maintained by one person or a small external agency.

Questions to ask before paying for an upgrade

• What specific problem am I solving? Slow origin processing, distant users, traffic spikes, heavy static files, reliability or security?
• Is a CDN already included? Check the hosting plan before buying an overlapping service.
• What counts as billable usage? Requests, data transfer, cache fill, image transformations, logs, firewall requests and overages can be priced separately.
• What happens on a cache miss? The origin still needs enough capacity for uncached and dynamic traffic.
• How do I purge or invalidate content? Long cache lifetimes are only useful if updates can be released safely.
• Which pages must never be shared-cached? Account, checkout, personalised, session-specific and other sensitive responses require careful treatment.
• Can I see cache and origin metrics? Without them, it is hard to tell whether the new layer is helping.
• What is the rollback plan? DNS, proxy and cache changes should be reversible if they introduce errors or stale content.

What to fix first

For most small-organisation websites, use this order:

1. Confirm the problem with real-user and representative lab data.
2. Measure the origin separately from the CDN/cache.
3. Correct unsafe or ineffective cache rules.
4. Reduce obviously heavy assets and unnecessary application work.
5. Use or tune an included CDN if it solves the measured delivery problem.
6. Upgrade hosting when origin resource or processing evidence justifies it.
7. Pay for a more advanced CDN tier only when its additional capacity, geography, security, logging or optimisation features solve a requirement you can name.
8. Re-measure performance, reliability and monthly cost after the change.

This approach keeps the decision tied to evidence. Caching and CDNs can reduce latency and origin load, but they are not substitutes for a healthy backend, and higher infrastructure spend is not a ranking strategy by itself.