Website Caching Explained: Browser, Server, and CDN Layers

Caching is the most powerful performance optimization available. A site that caches aggressively can be 5-10 times faster than a site that doesn't cache. But caching is also the most common source of confusion for site owners and developers because there are three completely different caching layers, each with its own purpose.

Understanding these three layers—browser cache, server-side cache, and CDN cache—is essential for diagnosing performance problems and setting up a fast site.

The Three Caching Layers

Browser cache. The user's browser stores copies of images, scripts, and stylesheets on their computer. The next time they visit, the browser loads from local disk instead of downloading again.

Server-side cache. Your web server stores intermediate results (database query results, rendered HTML, etc.) so it doesn't have to recalculate them on every request.

CDN cache. A content delivery network keeps copies of your content on distributed servers around the world. Visitors download from the server nearest them.

Each layer caches different things and solves a different problem.

Browser Cache: The User's Local Copy

When you visit a website, your browser downloads HTML, images, CSS, and JavaScript. These files take up space and time to download. The browser's solution is to store copies locally.

How browser cache works:

1. First visit: browser downloads all files and stores them on disk
2. You leave the site
3. Second visit: browser checks timestamps and expiration dates
4. If files haven't expired, browser loads from disk (instant)
5. If files have expired, browser downloads fresh versions

The server tells the browser how long to cache via HTTP headers:

Cache-Control: public, max-age=31536000

This means "cache this file for one year." After one year, the browser throws it away and downloads fresh.

What should be cached in browser?

• Images (they rarely change)
• CSS and JavaScript files (they change infrequently)
• Fonts (they never change)
• Static assets (logos, icons, etc.)

What shouldn't be cached?

• HTML (changes frequently)
• API responses (different per user or context)
• User-specific content (account pages, dashboards)

Browser cache best practices:

Set long expiration times (1 year or more) for files that rarely change. Use version numbers in filenames so you can update files immediately if needed:

Instead of: style.css Use: style-v2.5.3.css

When you update the stylesheet, change the filename to style-v2.5.4.css. The browser treats it as a new file and downloads it immediately, while old versions remain cached.

Browser cache is usually the lowest-hanging fruit for performance. Many sites don't set cache headers correctly, so enabling it provides immediate improvement.

Server-Side Cache: The Application Cache

Server-side caching is about avoiding redundant work on the server. If the database query to fetch "top 10 products" takes 500ms, you don't want to run it every time someone visits that page.

How server-side cache works:

1. User requests a page
2. Server checks if it has cached the result
3. If cached, serve the cached version (instant)
4. If not cached, run the database query, generate the HTML, cache the result, and serve it

Common server-side caching strategies:

Database query caching. The server caches frequent database queries. The next request gets the cached result instead of querying the database.

Page caching. The entire rendered HTML page is cached. For WordPress blogs, caching plugins store the rendered HTML so the server doesn't have to rebuild it from the database on every request.

Object caching. The server caches individual objects (product details, user profiles, etc.) so future requests retrieve them instantly.

Query result caching. API responses are cached so identical requests don't repeat the same calculation.

Setting up server-side cache:

• Use a caching plugin if you're on WordPress or another platform with plugins
• Use Redis or Memcached if you're running your own server
• Configure cache invalidation so old cache is removed when content updates

Cache invalidation is the hard part. If you cache "homepage content" for one hour but update the homepage after 10 minutes, visitors see outdated content until the cache expires. Proper cache invalidation clears specific cache items when updates happen.

CDN Cache: The Geographic Cache

A CDN keeps copies of your content on servers around the world. A visitor in Singapore gets served from a Singapore server. A visitor in Brazil gets served from a Brazil server. This reduces latency (time for data to travel from server to user) significantly.

How CDN cache works:

1. Visitor in London requests your site
2. CDN checks if it has a cached copy on its London server
3. If cached, serve from London (very fast)
4. If not cached, fetch from your origin server and cache the result

CDN cache is similar to browser cache, but it's on the server side. The benefit is that all users in a region benefit from the same cache instead of each user caching on their own machine.

What CDNs cache:

• HTML pages
• Images
• CSS and JavaScript
• Media files
• Any static content

Cache configuration on a CDN:

Like browser cache, CDNs respect HTTP headers. You tell the CDN what to cache and for how long:

Cache-Control: public, max-age=86400

This tells the CDN to cache the content for one day.

When to use a CDN:

• You have international visitors
• Your origin server is in one location
• You need to reduce latency globally
• You want to distribute load away from your origin server

How the Three Caches Work Together

A typical request flow with all three caches:

1. Browser cache: User has visited before. Browser checks if it has a cached copy. If yes and not expired, load from disk (no network request).

2. CDN cache: Browser cache expired or doesn't exist. Browser requests from CDN. CDN checks if it has a cached copy. If yes and not expired, serve from CDN.

3. Server cache: CDN cache expired or doesn't exist. CDN requests from origin server. Origin server checks server-side cache. If cached and valid, serve immediately.

4. Database: Server-side cache doesn't exist or expired. Server queries the database, gets the result, caches it, and serves it.

Each layer avoids work if something upstream is cached. If nothing is cached, you hit the database every single time.

Measuring Cache Effectiveness

To see if caching is working:

Use browser DevTools. Open your site in Chrome or Firefox, go to DevTools, and look at the Network tab. Cached resources show "from cache" or have zero download size. If most resources are downloading, your cache headers are wrong.

Check response headers. Look at the Cache-Control header on responses. It should specify max-age. If it's missing or says no-cache or no-store, caching is disabled.

Compare Time to First Byte (TTFB). TTFB is how long until your server responds. With effective server-side caching, TTFB should be 100-500ms. Without caching, TTFB can be 1-5 seconds.

Monitor cache hit rates. If you have a caching layer like Redis, it reports how many requests were served from cache vs. going to the database. Higher hit rate means more efficiency.

Common Caching Mistakes

Browser cache with no expiration. HTML files cached forever become outdated immediately. Set short expiration times for HTML (0-1 hour) and long times for images/scripts/CSS (1 year).

Caching user-specific content. If you cache a user's account dashboard, all users see the same dashboard (wrong). Only cache content that's identical for all users.

Cache too long. If you cache your homepage for 30 days and update the homepage, users see outdated content for a month. Set reasonable expiration times based on how often content updates.

Cache without invalidation. When you update content, old cache isn't removed automatically. Users see outdated content until cache expires naturally. Implement cache invalidation (purge specific cached items when updates happen).

Ignoring cache on third-party assets. External scripts and images usually have long cache times set by the provider. You can't change these, but they still benefit users by reducing downloads.

Debugging Cache Problems

If your site seems slow or shows outdated content:

1. Check if content is being cached. Use browser DevTools or curl to inspect response headers.

2. Clear all cache layers. Clear browser cache, restart your server, and purge CDN cache. If the site is instantly faster after clearing, cache was the issue.

3. Check cache control headers. Are they correct? Should content be cached?

4. Monitor database queries. Is the server-side cache working? Are queries still hitting the database every time?

5. Check cache invalidation. When you update content, is the cache being cleared?

FAQ

Should I cache everything?

No. Cache static content and frequently-accessed dynamic content. Don't cache user-specific content or content that changes frequently.

How long should I cache different types of content?

• HTML/pages: 1-24 hours
• Images: 30 days to 1 year
• CSS/JavaScript: 1 year (if versioned in filename)
• API responses: seconds to hours depending on data freshness requirements
• User-specific content: don't cache

What if I need to update content urgently?

Most caching systems support manual cache purging. With CDNs, you can purge specific URLs immediately. With server-side cache, you can clear the cache manually or programmatically.

Does caching affect SEO?

No, if configured correctly. Search engines understand caching. If you cache user-specific content incorrectly, different users might see different versions of pages, which can confuse search engines.

Is Redis required for caching?

No. Redis is a popular choice for server-side caching, but built-in caching systems work fine for many sites. Start with built-in cache, then upgrade to Redis if needed.

The Compounding Effect of Caching

Most performance problems trace back to misconfigured or missing caching. A site with browser cache, server-side cache, and CDN cache properly configured is typically 5-10 times faster than a site with no caching.

The key is understanding what each layer does and configuring it appropriately. Browser cache handles the user's local experience. Server-side cache reduces database load. CDN cache handles geographic latency. Together, they make websites fast.