Caching - Complete Guide for Web Developers

What is Caching?

Caching is storing a copy of data closer to where it's needed, so you don't fetch it from the slow source every time.

The Impact of Caching

WITHOUT CACHE:
User ──────► Server ──────► Database    Every. Single. Time.
      100ms         50ms                 Total: 150ms

WITH CACHE:
User ──────► Cache    HIT! Return instantly
       5ms            Total: 5ms (30x faster!)

Metric	Without Cache	With Cache	Improvement
Response Time	150-500ms	5-50ms	10-30x faster
Server Load	100%	10-20%	80% reduction
Database Queries	Every request	Cache misses only	90% reduction

The Caching Layers

There are multiple layers where caching happens. The closer to the user, the faster!

All Caching Layers

┌─────────────────────────────────────────────────────────────────┐
│                      USER'S DEVICE                              │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐           │
│  │   Memory     │  │   Browser    │  │   Service    │           │
│  │   Cache      │  │   HTTP       │  │   Worker     │           │
│  │  (fastest)   │  │   Cache      │  │   Cache      │           │
│  └──────────────┘  └──────────────┘  └──────────────┘           │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                           CDN                                   │
│            (Edge servers distributed globally)                  │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    APPLICATION SERVER                           │
│  ┌──────────────┐  ┌──────────────┐                             │
│  │  In-Memory   │  │   Redis/     │                             │
│  │   Cache      │  │  Memcached   │                             │
│  └──────────────┘  └──────────────┘                             │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                        DATABASE                                 │
│              (Query cache, Buffer pool)                         │
└─────────────────────────────────────────────────────────────────┘

💡 Golden Rule

Cache as close to the user as possible! Browser > CDN > Server > Database

HTTP Cache Headers

The server tells the browser HOW to cache using HTTP response headers:

Header	Purpose
`Cache-Control`	Main header - controls all caching behavior
`ETag`	Unique version ID for the resource
`Last-Modified`	When the resource was last changed
`Expires`	Absolute expiry date (legacy, use max-age)
`Vary`	Cache different versions based on request headers

Cache-Control Deep Dive

Cache-Control Anatomy

Cache-Control: max-age=3600, public
               │              │
               │              └── WHO can cache
               └── HOW LONG to cache (seconds)

Freshness Directives

HTTP

# Cache for 1 hour
Cache-Control: max-age=3600

# Cache for 1 year (static assets with hash)
Cache-Control: max-age=31536000

# CDN caches longer than browser
Cache-Control: max-age=60, s-maxage=3600
# Browser: 60 seconds, CDN: 1 hour
                

Cacheability Directives

HTTP

# Anyone can cache (browser, CDN, proxies)
Cache-Control: public, max-age=3600

# Only browser can cache (not CDN) - for user-specific content
Cache-Control: private, max-age=3600

# Don't cache anywhere - sensitive data!
Cache-Control: no-store

# Cache but always revalidate with server first
Cache-Control: no-cache
                

Advanced Directives

HTTP

# Serve stale while fetching fresh in background (amazing for UX!)
Cache-Control: max-age=60, stale-while-revalidate=3600

# Content NEVER changes (versioned files like app.abc123.js)
Cache-Control: max-age=31536000, immutable

# Serve stale if origin server is down
Cache-Control: max-age=60, stale-if-error=86400
                

Cache-Control by Content Type

Content	Cache-Control	Why
Hashed assets (`app.abc123.js`)	`public, max-age=31536000, immutable`	Never changes
Static assets (`favicon.ico`)	`public, max-age=86400`	Changes rarely
HTML pages	`no-cache`	Always check for updates
Public API	`public, max-age=300, s-maxage=600`	Fresh enough
Private API	`private, max-age=60`	User-specific
Sensitive data	`no-store`	Never cache!

ETag & Validation

When cache expires, the browser asks: "Is my copy still good?" This is called revalidation.

ETag Validation Flow

FIRST REQUEST (no cache yet):
Browser ──────────────────────────────────────► Server
         GET /style.css

Browser ◄────────────────────────────────────── Server
         200 OK
         ETag: "abc123"
         Cache-Control: max-age=3600
         [CSS content...]

AFTER CACHE EXPIRES (revalidating):
Browser ──────────────────────────────────────► Server
         GET /style.css
         If-None-Match: "abc123"  ← "Is abc123 still valid?"

Server checks: Is "abc123" still current?

IF NOT MODIFIED:
Browser ◄────────────────────────────────────── Server
         304 Not Modified
         (no body - saves bandwidth!)

IF MODIFIED:
Browser ◄────────────────────────────────────── Server
         200 OK
         ETag: "xyz789"
         [New CSS content...]

✅ 304 Not Modified

The 304 response contains no body - just headers. This saves bandwidth while still ensuring fresh content!

Service Workers

Service Workers give you full programmatic control over caching. They sit between your app and the network, intercepting every request.

Service Worker Architecture

┌──────────────┐         ┌──────────────────────┐         ┌──────────────┐
│   Your App   │ ──────► │    Service Worker    │ ──────► │   Network    │
│              │         │                      │         │              │
└──────────────┘         │  "I intercept ALL    │         └──────────────┘
                         │   requests and       │
                         │   decide what to     │
                         │   return!"           │
                         │                      │
                         │   ┌──────────────┐   │
                         │   │  Cache API   │   │
                         │   │  (Storage)   │   │
                         │   └──────────────┘   │
                         └──────────────────────┘

Key Capabilities

Offline Support - Serve cached content when network is unavailable
Custom Caching Strategies - You decide: cache-first, network-first, or hybrid
Background Sync - Queue failed requests and retry when online
Push Notifications - Receive messages even when app is closed

Service Worker Lifecycle

Lifecycle Stages

1. REGISTER
   └── navigator.serviceWorker.register('/sw.js')
         │
         ▼
2. INSTALL (first time or when updated)
   └── Pre-cache static assets
   └── self.skipWaiting() to activate immediately
         │
         ▼
3. ACTIVATE
   └── Clean up old caches
   └── self.clients.claim() to control pages immediately
         │
         ▼
4. RUNNING
   └── Intercepts ALL fetch requests
   └── You decide: cache, network, or both!

Registration Code

JavaScript

// In your main app JavaScript
if ('serviceWorker' in navigator) {
  window.addEventListener('load', async () => {
    try {
      // Register the service worker file
      const registration = await navigator.serviceWorker.register('/sw.js');
      console.log('SW registered! Scope:', registration.scope);
    } catch (error) {
      console.error('SW registration failed:', error);
    }
  });
}
                

Service Worker File (sw.js)

JavaScript

const CACHE_NAME = 'my-app-v1';

// Files to cache immediately on install
const PRECACHE_ASSETS = [
  '/',
  '/index.html',
  '/styles/main.css',
  '/scripts/app.js',
  '/offline.html'
];

// INSTALL - Pre-cache static assets
self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => cache.addAll(PRECACHE_ASSETS))
      .then(() => self.skipWaiting())
  );
});

// ACTIVATE - Clean up old caches
self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames
          .filter(name => name !== CACHE_NAME)
          .map(name => caches.delete(name))
      );
    }).then(() => self.clients.claim())
  );
});

// FETCH - Intercept requests (implement strategy here)
self.addEventListener('fetch', (event) => {
  event.respondWith(handleRequest(event.request));
});
                

Caching Strategies

1. Cache First

Check cache → Return if found → Otherwise fetch network

Best for: CSS, JS, images, fonts

2. Network First

Try network → If fails, return from cache

Best for: API data, dynamic content

3. Stale While Revalidate

Return cached immediately → Update cache in background

Best for: Balance speed & freshness

4. Network Only

Always fetch from network, no caching

Best for: Real-time data, analytics

Cache First Implementation

JavaScript

// Best for: Static assets that rarely change
async function cacheFirst(request) {
  // 1. Check cache first
  const cached = await caches.match(request);
  if (cached) {
    console.log('Cache HIT:', request.url);
    return cached;
  }
  
  // 2. Not in cache - fetch from network
  console.log('Cache MISS, fetching:', request.url);
  const response = await fetch(request);
  
  // 3. Cache for next time
  const cache = await caches.open(CACHE_NAME);
  cache.put(request, response.clone()); // Clone because response is one-time use
  
  return response;
}
                

Stale While Revalidate Implementation

JavaScript

// Best for: Content where speed matters but freshness is nice
async function staleWhileRevalidate(request) {
  const cache = await caches.open(CACHE_NAME);
  const cached = await caches.match(request);
  
  // Fetch fresh version in background (don't await!)
  const fetchPromise = fetch(request).then(response => {
    cache.put(request, response.clone());
    return response;
  });
  
  // Return cached immediately OR wait for network
  return cached || fetchPromise;
}
                

Strategy Selection Guide

Content Type	Strategy	Why
App Shell (HTML)	Stale While Revalidate	Fast + stays fresh
CSS/JS bundles	Cache First	Rarely change (use versioned URLs)
Images, Fonts	Cache First	Large files, rarely change
API - User data	Network First	Must be fresh
API - Static data	Stale While Revalidate	Speed + eventual freshness
Real-time data	Network Only	Can't be stale

Offline Support

Show a custom offline page when the network is unavailable:

JavaScript

async function handleRequest(request) {
  try {
    return await fetch(request);
  } catch (error) {
    // Network failed! Return appropriate fallback
    
    // For HTML pages - show offline page
    if (request.headers.get('Accept').includes('text/html')) {
      return caches.match('/offline.html');
    }
    
    // For images - show placeholder
    if (request.url.match(/\.(png|jpg|jpeg|gif|svg)$/)) {
      return caches.match('/images/offline-placeholder.png');
    }
    
    // For API - return error JSON
    if (request.url.includes('/api/')) {
      return new Response(
        JSON.stringify({ error: 'You are offline' }),
        { 
          status: 503, 
          headers: { 'Content-Type': 'application/json' }
        }
      );
    }
  }
}
                

CDN Caching

CDNs cache your content at edge servers worldwide, serving users from the nearest location.

CDN Impact

WITHOUT CDN:
User in Tokyo ────────────────────────────► Server in New York
                   ~200ms latency           

WITH CDN:
User in Tokyo ───► Edge in Tokyo
                    ~10ms
                    
                   Cache HIT! → Return immediately
                   Cache MISS → Fetch from origin, cache it

Major CDN Providers

Provider	Edge Locations	Best For
Cloudflare	300+	Free tier, Workers, DDoS protection
AWS CloudFront	400+	AWS integration, Lambda@Edge
Fastly	70+	Real-time purging, edge compute
Vercel Edge	100+	Next.js apps, serverless

Cache Invalidation Strategies

Versioned URLs

/app.js → /app.abc123.js

Best for static assets. Cache forever!

Purge API

Call CDN API to invalidate specific URLs

When content updates, purge the cache

Short TTL + SWR

max-age=60, stale-while-revalidate=3600

Auto-updates within 60 seconds

Server-Side Caching (Architecture)

Understanding how backend caching works helps you collaborate with backend teams.

Server Caching Layers

┌─────────────────────────────────────────────────────────────────┐
│                    APPLICATION SERVER                           │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. IN-PROCESS CACHE                                            │
│     └── Stored in server's RAM (~0.01ms)                        │
│     └── NOT shared between servers                              │
│     └── Lost when server restarts                               │
│                                                                 │
│  2. DISTRIBUTED CACHE (Redis/Memcached)                         │
│     └── Separate cache server (~1ms)                            │
│     └── Shared between all app servers                          │
│     └── Survives server restarts                                │
│                                                                 │
│  3. DATABASE                                                    │
│     └── Source of truth (~10-50ms)                              │
│     └── Query cache, buffer pool                                │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Redis vs Memcached

Feature	Redis	Memcached
Data types	Rich (hash, list, set, sorted set)	String only
Persistence	Yes (optional disk backup)	No (memory only)
Replication	Built-in master-slave	No built-in
Use case	General purpose, sessions, queues	Simple caching

💡 Industry Standard

Most companies use Redis - it has more features and is still blazing fast (100k+ operations/second).

Caching Patterns

Cache-Aside (Lazy Loading)

App checks cache → Miss → Fetch DB → Store in cache

Most common pattern. Simple but first request is slow.

Read-Through

App always asks cache → Cache handles DB fetch

Cache library manages everything.

Write-Through

Write to cache → Cache writes to DB → Confirm

Cache always fresh. Slower writes.

Write-Behind

Write to cache → Confirm immediately → Async DB write

Super fast writes. Risk of data loss.

⚠️ Cache Stampede Problem

When a popular cache key expires, thousands of requests hit the database simultaneously! Solutions: locking, early expiration, or stale-while-revalidate.

How Big Companies Cache

🎬 YouTube / Netflix

VIDEO STREAMING STRATEGY:

1. Videos cached at 1000s of edge locations globally
2. Popular videos pushed to edges BEFORE users request
3. Servers placed INSIDE ISP data centers
4. Multiple quality versions cached (360p, 720p, 1080p, 4K)

RESULT: 95%+ of traffic served from edge, <10ms latency

🛒 Amazon / Flipkart

E-COMMERCE CACHING:

├── Product catalog: Long TTL, invalidate on update
├── Prices: Short TTL (can't show stale prices!)
├── Inventory: Real-time or very short TTL
├── Static assets: Infinite cache with versioned URLs
├── Search results: Cache by query + location
└── Recommendations: Pre-computed, cached per user segment

CHALLENGE: Personalization makes caching harder

🐦 Twitter / X

SOCIAL MEDIA CACHING:

TIMELINE:
└── Fan-out on write: Pre-compute timelines for users
└── Celebrity exception: Fan-out on read (too many followers)

TWEETS:
└── Immutable! Cache forever
└── Only engagement counts update

TRENDS:
└── Computed periodically, cached per region

Best Practices Checklist

Frontend Caching

Use versioned URLs for static assets (app.abc123.js)
Set Cache-Control: immutable for versioned assets
Use stale-while-revalidate for HTML pages
Implement Service Worker for offline support
Pre-cache critical assets on SW install
Use appropriate strategy per content type
Monitor cache hit rates in DevTools

HTTP Headers

Always set Cache-Control (not just Expires)
Use max-age for browser, s-maxage for CDN
Set ETag or Last-Modified for validation
Use Vary header correctly (avoid Vary: *)
Set no-store for sensitive data

Golden Rules

🏆 Remember These

Cache as close to user as possible - Browser > CDN > Server
Static = aggressive, Dynamic = careful
Have invalidation strategy BEFORE caching
When in doubt, shorter TTL is safer
Monitor! If cache isn't hit, remove it