When a website feels fast, caching is often part of the reason. When a site stays online during a traffic spike, a content delivery network, or CDN, may be doing quiet work in the background. Both terms come up in conversations with developers and hosting providers, yet they are rarely explained in plain English.

This guide explains what caching and CDNs do, how they affect speed, costs and resilience, and what business owners should ask about them. You do not need to configure anything yourself, but understanding the basics will help you make better decisions about your website.

What caching means

Caching means keeping a copy of something so it can be reused instead of fetched or rebuilt every time. On the web, that something is usually a response from a server: a page, an image, a stylesheet or a script.

The Internet Engineering Task Force’s standard on HTTP caching, RFC 9111, published in June 2022, states the purpose simply: the goal of HTTP caching is significantly improving performance by reusing a prior response message to satisfy a current request.

Think of a coffee shop that brews a big batch of house coffee in the morning. Most customers get a cup poured from the batch in seconds. Only unusual orders require making something from scratch. Caching gives websites the same advantage.

Two kinds of caches

RFC 9111 distinguishes between two types of cache, and the difference matters for business owners.

Private caches are dedicated to a single user, and they are often part of a browser. When you visit a site and your browser saves its logo and stylesheet, the next page loads faster because those files are already on your device.

Shared caches store responses for reuse by more than one user. They usually sit between visitors and your server, as part of a hosting setup, a reverse proxy or a CDN. When one visitor requests your homepage, a shared cache can save a copy and serve it to the next hundred visitors without asking your server again.

Shared caches deliver big benefits, but they also require care, because anything stored there could be shown to other people.

Fresh, stale and checking again

A cached copy does not last forever. RFC 9111 describes cached responses as fresh or stale. A fresh response can be reused without contacting the server, which, the standard notes, reduces both latency and network overhead. Once a response becomes stale, a cache generally needs to check with the server before using it again.

That check is called validation. The cache asks the server, in effect, “Has this changed since I saved it?” If nothing has changed, the server can reply with a short “not modified” message instead of sending the whole file again.

The headers that control caching

Servers tell caches what to do through HTTP headers, small pieces of information attached to each response. Your developer or hosting provider sets these, but knowing the main ones helps you follow the conversation:

  • max-age says how many seconds a response stays fresh.
  • no-cache means a cache may store the response but must check with the server before reusing it.
  • no-store means a cache must not store any part of the request or response.
  • private means a shared cache must not store the response, though a user’s browser may.

RFC 9111 defines each of these directives. Their names can mislead: “no-cache” does not actually mean “do not cache,” which is why it is worth having someone experienced review your settings.

Hands in orange sleeves plug a green network cable into a switch with blue status lights.

How caching helps search crawlers, too

Caching is not only for human visitors. In December 2024, Google’s Search Central team published a post on crawling and HTTP caching encouraging site owners to support it.

The post explains that caching allows pages to load lightning fast on revisits, saves computing resources and saves a tremendous amount of expensive bandwidth for both clients and servers. It also notes that the share of Google’s fetches that could be returned from cache had fallen, from about 0.026 percent of total fetches ten years earlier to about 0.017 percent at the time.

Google’s crawlers support two validation methods: ETag with If-None-Match, and Last-Modified with If-Modified-Since. The post strongly recommends ETag because it is less prone to errors. When the content has not changed, the server should return a 304 Not Modified status with no body.

Two practical tips from the post stand out:

  • Require a cache refresh only on significant changes. Updating the copyright date at the bottom of a page is probably not significant.
  • Consider setting max-age to the expected number of seconds the content will stay unchanged.

Balancing freshness and speed

Choosing how long content stays fresh is a business decision as much as a technical one. Longer freshness times mean fewer requests to your server and faster repeat visits, but changes take longer to reach everyone unless you purge. Shorter times keep content current but send more traffic back to your server.

A practical approach is to match freshness to how often content really changes. A logo or font file may stay the same for months. A blog post may change rarely after publication. A page listing daily specials, event availability or limited stock may change several times a day and needs a much shorter window, or validation on every request.

Write down which pages change often and who updates them. That simple list helps your developer choose sensible settings and helps your team know when a purge is needed after an update.

What a CDN does

A content delivery network is a group of servers in many locations that store copies of your site’s files closer to visitors. Instead of every request traveling to a single server in one city, visitors are served from a nearby location.

For business owners, CDNs typically offer:

Speed for distant visitors. A customer across the country, or overseas, gets files from a nearby server rather than one far away.

Less load on your server. When the CDN serves cached files, your server handles fewer requests, which can reduce hosting strain and costs.

Better handling of traffic spikes. A promotion, news mention or seasonal rush is spread across many servers.

Help against attacks. In March 2024, CISA, the FBI and MS-ISAC published a guide to understanding and responding to distributed denial-of-service attacks. Among its recommendations is to enable a CDN, noting that CDNs can help mitigate DDoS attacks by absorbing and distributing traffic across multiple servers and data centers. A CDN is not a complete defense on its own, but it adds a useful layer.

What should and should not be cached

The biggest risk with caching is storing the wrong thing in a shared cache. Here is a general guide.

Usually safe to cache for a long time: images, fonts, stylesheets and scripts, especially when file names change whenever the content changes.

Often safe to cache for shorter periods: public pages that change occasionally, such as service pages, blog posts and the homepage.

Should not be stored in shared caches: anything personal or account-specific, including shopping carts, checkout pages, account dashboards, order histories, and pages showing a logged-in user’s name or details. Directives such as private or no-store exist for exactly these cases.

Misconfiguring this can cause one visitor to see another visitor’s information, which is a serious privacy and trust problem. Any caching setup for an online store, membership site or customer portal deserves careful testing. Test while logged in and logged out, using two accounts.

A shop owner in a blue shirt types on a laptop at a wooden counter while two customers browse on their phones.

Purging: updating what is cached

When you change a page, cached copies may continue to show the old version until they expire. Most CDNs and caching tools offer a purge or clear function that removes cached copies so the next request gets the latest version.

Good practice includes:

  • Knowing who on your team or at your provider can purge the cache.
  • Purging specific pages or files rather than everything, when possible, to avoid a sudden load on your server.
  • Using versioned file names for stylesheets and scripts so updates appear immediately.
  • Testing important updates, such as price changes or announcements, in a private browser window after publishing.

A fictional example

Consider an invented independent home goods shop with a small online store. During a holiday promotion, its pages slowed to a crawl, and the checkout occasionally failed.

After a review, its developer enabled a CDN for images, stylesheets and scripts, set public pages to stay fresh for a short period, and excluded the cart, checkout and account pages from shared caching entirely. The team also learned how to purge individual pages after updating prices.

In this fictional scenario, the next promotion ran smoothly. Product pages loaded quickly for visitors far from the shop, the server handled the rush comfortably, and every customer saw only their own cart.

Questions to ask your developer or host

  • Is a CDN in place, and which content does it serve?
  • What caching headers do our main pages and files use?
  • Are carts, checkout, account and other personal pages excluded from shared caches?
  • How do we purge the cache after an update, and who can do it?
  • Does the server support ETag or Last-Modified validation?
  • How does our setup help with traffic spikes and denial-of-service attacks?
  • How do we test that caching works correctly on phones as well as desktops?

The last question matters because many visitors arrive on mobile connections, where every saved request helps. Fast, cache-friendly pages pair naturally with responsive designs that adapt to each screen.

Where hosting and development fit in

Caching and CDNs work best as part of a well-planned setup rather than as add-ons. Reliable web hosting provides the foundation, including server performance, security and the tools to manage caching. Careful web development makes sure pages, files and headers are built so they can be cached safely, with personal content kept out of shared caches.

Common misunderstandings

“A CDN makes everything fast.” It speeds up delivery of cached content, but slow database queries, heavy scripts and oversized images still need attention.

“Caching means visitors see old content.” Only if it is configured poorly. With sensible freshness times, validation and purging, visitors see current content quickly.

“Small sites do not need this.” Even small sites benefit from browser caching and sensible headers, and many hosting plans include CDN options.

The bottom line

Caching saves copies of web content so it can be reused, and CDNs place those copies closer to visitors. Together they can make sites faster, reduce server load and bandwidth, help crawlers revisit efficiently, and add resilience during spikes and attacks. The key is configuring them carefully: cache public content generously, keep personal content out of shared caches, and know how to purge when things change. A short conversation with your developer or host using the questions above is a practical place to start.