Do You Need a CDN? Caching and CDNs for Business Sites

Where the waiting comes from

Before a browser can show anything, it has to receive the first part of the page from your server. web.dev calls this Time to First Byte (TTFB): the time from starting the navigation to the first byte of the response. It adds up redirects, DNS lookup, connecting and the secure (TLS) handshake, and the time your server takes to produce the page. As a rough guide, web.dev suggests most sites aim for a TTFB of 0.8 seconds or less, and treats more than 1.8 seconds as poor.

TTFB is not one of the Core Web Vitals, but it comes before all of them: a slow first byte delays everything that follows, including Largest Contentful Paint (LCP). Our guide to Core Web Vitals covers the metrics Google uses, and caching and CDNs mainly work on this first stage and on delivering files.

Browser caching and Cache-Control

The cheapest request is one the browser does not have to make. Your server tells browsers (and CDNs) what they may keep and for how long with the Cache-Control header. The values you will meet most often, as MDN defines them:

• max-age=N: the response stays fresh for N seconds and can be reused without asking the server.
• no-cache: may be stored, but must be checked with the server before each reuse. MDN stresses that it does not mean "don't cache".
• no-store: no cache of any kind should store the response.
• private: only the visitor's own browser may store it, not a shared cache such as a CDN. MDN says to use it for personalised content, especially after login, because otherwise one person's page can be stored in a shared cache and shown to others.
• immutable: the file will not change while it is fresh, so the browser need not check it again.

The usual pattern is to give each file a version in its name. web.dev's HTTP cache guide explains why: once a browser has cached a file for a year, you cannot make it fetch your fix unless the URL changes. So files such as style.x234dff.css, with a fingerprint or version that changes whenever the content does, can be served with Cache-Control: max-age=31536000 (one year). HTML pages rarely carry versions, so they get short lifetimes or no-cache, and the browser checks for a newer copy each time. MDN's HTTP caching guide covers the details.

What a CDN does

A CDN is a network of servers spread across many locations. In web.dev's CDN guide, the benefits come from three things: CDN servers are closer to visitors than your own server (the origin), so each round trip is shorter; the CDN's own network carries traffic back to the origin over optimised, already-open connections; and files cached at the CDN do not need a trip to the origin at all, which also takes load off your server.

Most CDNs fill their caches by "origin pull": the first request for a file goes to your server, and the CDN keeps the response for the next visitors. You can also "purge" files to remove them before they expire, which matters when you fix a typo or a price. web.dev notes that a CDN may treat a response as cacheable if it is not marked no-store or private, and that you normally need max-age, s-maxage (a lifetime for shared caches only) or an Expires header for it to be cached. Many CDNs also offer extras such as image optimisation, load balancing and security features.

What a CDN fixes and what it does not

A CDN helps most with distance, traffic and delivery:

• Visitors far from your server. web.dev's TTFB optimisation guide says that even a well-optimised backend can give a high TTFB to people far from the origin, and that a CDN addresses this.
• Connection setup. The same guide says CDNs usually offer fast DNS, modern protocols such as HTTP/2 and HTTP/3, modern TLS versions and good compression.
• Traffic spikes. Because cached files are served by the CDN, your server handles fewer requests.
• LCP. web.dev says CDNs are particularly effective at improving LCP, because they can speed up both the page itself and the files needed to show its main element.

It does not fix problems inside the page:

• A slow backend on uncached pages. A page that cannot be cached, such as a basket or account page, still waits for your server. web.dev warns that caching can mask a slow backend, so test with the cache bypassed too.
• Heavy images and scripts. A CDN delivers a 3 MB image faster, but it is still 3 MB. Resizing, modern formats and compression are covered in our image optimisation guide, unless you use a CDN's image service to do it.
• Slow reactions to clicks and layout shifts. These come from the page's code and layout, not from where files are served.
• Redirect chains. web.dev lists multiple redirects as a common cause of high TTFB; fix them at the source.

Does your site need one?

web.dev's TTFB guide puts hosting first: make sure your host can handle your traffic before trying other optimisations. It says shared hosting is generally slower, which is probably fine for a small site serving mostly static files, while a larger application with many users, personalisation and database work needs hosting chosen with care. Our guide to web hosting explains the types.

To decide about a CDN, look at real-user data first. web.dev recommends field data for TTFB, for example from PageSpeed Insights, which shows real Chrome users' experience for public sites included in the Chrome User Experience Report. A CDN is most likely to be worth it when:

• visitors come from far away from your server, such as other countries or continents;
• TTFB in the field is poor while your server is not under strain;
• you get traffic spikes from campaigns, press or seasonal sales;
• the site serves many images, downloads or video.

web.dev's view is that adopting a CDN should be a high priority for TTFB if a site does not use one. Many hosting platforms and online shop systems include one already, so check what you have before adding another.

Setting one up

web.dev describes the usual setup: sign up with a provider and point your site's DNS at it, for example a CNAME record for www.example.com pointing to a hostname the CDN gives you. Ideally the CDN serves the whole site. If not, you can serve only static files from a separate hostname such as static.example.com and change the file URLs to match. Our domain names and DNS guide explains records like these.

After that, check the cache hit ratio, the share of requests served from the CDN's cache, in the provider's reports. web.dev suggests first checking that every cacheable file is cached for the right length of time, which you can see in the Cache-Control headers in Lighthouse, WebPageTest or the browser's developer tools.

Common pitfalls

• Caching private pages. Anything personal, such as account pages, baskets or pages after login, should be marked private or no-store so a shared cache never shows it to someone else.
• Long lifetimes on unversioned files. If a file name never changes, a one-year cache means visitors keep the old version.
• Query strings that split the cache. web.dev notes that unique tracking parameters can make the same page look like different content to a CDN, so the cached copy is not used.
• Forgetting to purge. After an urgent fix to a cached page, purge it or wait for it to expire.
• Testing only cached pages. Less visited pages may not be in the cache, so they can be slower than your homepage test suggests.

Checklist

• Field TTFB and LCP checked, for example in PageSpeed Insights.
• Hosting can handle the traffic before anything else is added.
• Versioned CSS, JavaScript and images cached for a long time; HTML short or revalidated.
• Personal pages marked private or no-store.
• A CDN added if visitors are far away, traffic spikes or files are heavy; DNS pointed at it.
• Cache hit ratio and headers checked; purging known; uncached pages tested.
• Images and scripts slimmed down as well, since a CDN does not shrink them.

Frequently asked questions

What is the difference between caching and a CDN?

Caching means keeping a copy of a file so it does not have to be fetched or built again; browsers, servers and CDNs can all cache. A CDN is a network of servers in many places that delivers your site from close to each visitor, and caches files there.

Does a CDN make every page faster?

No. It shortens the distance and connection time and serves cached files quickly, but pages that cannot be cached still wait for your server, and heavy images or scripts stay heavy.

What is a good TTFB?

web.dev gives 0.8 seconds or less as a rough guide for most sites and treats more than 1.8 seconds as poor. TTFB is not a Core Web Vitals metric, but a slow first byte delays everything after it.

Will a CDN show one visitor's account page to another?

It should not if the page is marked correctly. MDN says to mark personalised responses private, so only the visitor's own browser can store them, or no-store so nothing stores them.

Want a site that is quick for visitors wherever they are? See how we handle website development and website maintenance, see all our services, or email info@creahive.com.