Web Caching Explained: Browser, CDN and Server Cache

Caching means storing a copy of something so it can be delivered faster next time. It is one of the most effective ways to speed up websites and reduce server load. It is also behind many puzzling bugs: a price change that customers cannot see, a logged-in page shown to the wrong user or a fix that "does not work" because an old version is cached.

This guide explains the main layers of web caching in plain language, for junior developers and curious business owners.

Browser Caching

Browsers store files such as images, CSS and JavaScript locally, controlled by HTTP headers like Cache-Control. When a visitor returns or moves to another page, the browser can reuse those files instead of downloading them again.

• Static assets with versioned filenames can be cached for a long time
• HTML pages usually need shorter caching or revalidation so content updates appear
• Changing a file's name or adding a version hash when it changes forces browsers to fetch the new version

Most build tools add content hashes to filenames automatically, which makes long caching safe.

Database query caching and application-level caching sit behind the scenes too, but browser, CDN and server page caches are the layers most people interact with.

CDN Caching

A content delivery network stores copies of your files on servers around the world or region, closer to visitors. This reduces latency and protects your origin server from traffic spikes. Many CDNs can cache entire HTML pages for anonymous visitors.

CDN caching needs clear rules: what to cache, for how long and when to purge. Pages that change per user, such as carts and account pages, must not be cached publicly. Our guide on whether you need a CDN for a Malaysian website goes deeper.

Look for CDN features like "stale while revalidate", which serve a slightly older copy instantly while fetching a fresh one in the background. This keeps pages fast without showing outdated content for long.

Server-Side Page and Object Caching

On the server, page caching stores fully generated pages so the application does not rebuild them for every visitor. WordPress caching plugins and framework response caches work this way. Object caching stores results of expensive operations, such as database queries or API calls, in memory using tools like Redis or Memcached.

1. Cache pages that are the same for everyone, such as blog posts and product pages for guests.
2. Exclude carts, checkout, account pages and admin areas.
3. Cache expensive queries with sensible expiry times.
4. Clear related caches automatically when content changes.

Key takeaway: caching is easy to add and hard to get exactly right. Decide what must always be fresh before deciding what can be cached.

Common Caching Mistakes

• Stale prices or stock: product pages cached too long after updates. Purge on change, or cache stock separately with short expiry.
• Personal data leaks: a logged-in page cached and shown to other users. Never publicly cache personalised responses.
• "My fix is not showing": old CSS or JavaScript cached without versioning.
• Cache stampedes: many requests rebuilding the same expired item at once, overloading the server.

During festive sales, caching misconfigurations can cause both overloads and wrong prices at the worst moment. Test caching behaviour on staging before big campaigns.

Another common mistake is caching error pages. If a temporary error is cached, visitors may keep seeing it after the problem is fixed. Configure caches to store only successful responses, or to keep errors for a very short time.

Testing and Documenting Your Cache

Use browser developer tools to inspect response headers and see whether files come from cache. Many CDNs add headers showing cache hits or misses. Test as a guest and as a logged-in user to confirm personalised pages bypass caches.

Document caching rules: which layers exist, what each caches, expiry times and how to purge. When something looks wrong, this saves hours. Include caching checks in your pre-launch QA checklist and performance reviews.

Done well, caching makes sites fast, resilient and cheaper to host. Done carelessly, it creates confusing bugs. A little planning makes the difference.

Finally, monitor cache hit rates over time. A sudden drop may mean a configuration change broke caching, which often shows up as slower pages and higher server load.

FAQ

Why do I need to clear my cache to see changes?

The browser or CDN is serving an older copy. Proper versioning and purging avoid this for visitors.

Is caching safe for ecommerce?

Yes, if carts, checkout and account pages are excluded and product data is purged on changes.

Does caching help with traffic spikes?

Very much. Cached pages can be served to many visitors without overloading the application.

Web caching works in layers: browser, CDN, page and object caches. Cache what is the same for everyone, never cache personal pages publicly, version static files, purge on content changes and document the rules.