CDN vs Application Cache — Where to Cache What

Caching is the cheapest way to make a site faster, but each cache layer suits different content. This guide maps what to cache where, from the visitor's browser to your database, with examples for Cloudflare, nginx and Redis, and notes on which layers you control on Domain India hosting.

The 5 caching layers

Each layer catches different things. Use them together.

Decision matrix — what goes where

Layer 1 — Browser cache

The cheapest cache: the browser serves the file without any network request.

Set HTTP headers. On your own nginx server:

location ~* \.(jpg|jpeg|png|gif|webp|svg|css|js|woff2|ttf)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    add_header Vary "Accept-Encoding";
}

location /api/ {
    expires -1;   # no cache for API
    add_header Cache-Control "no-store";
}

location / {
    expires 1h;
    add_header Cache-Control "public, must-revalidate";
}

On Domain India shared hosting (Apache), set the same headers in .htaccess; mod_expires and mod_headers are loaded on our cPanel and DirectAdmin servers:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType application/javascript "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
</IfModule>

Compression is already handled on our shared servers (gzip through nginx on cPanel, mod_deflate on DirectAdmin), so you don't need to add it yourself.

Fingerprinting your static files breaks the cache automatically:

bundle.abc123.js — when the content changes, the hash changes and the browser fetches the new file. Set TTL = forever.

Layer 2 — CDN edge (Cloudflare)

Cloudflare caches what you tell it to. By default: static files yes, HTML no.

Cache HTML with a Cache Rule

Cloudflare has replaced Page Rules with Cache Rules for caching settings. In the Cloudflare dashboard, open Caching → Cache Rules and create a rule:

When: Hostname equals yourcompany.com
Then:
  Cache eligibility: Eligible for cache
  Edge TTL: 2 hours
  Browser TTL: 30 minutes

Now public HTML pages are cached at the edge too.

Bypass cache for dynamic paths and logged-in users

Add a second rule, placed after the first so it wins:

When: URI Path starts with /admin/
   OR Cookie contains "wp_logged_in"
   OR Cookie contains "sessionid"
Then:
  Cache eligibility: Bypass cache

When a login cookie is set, Cloudflare skips the cache and goes to your server. Logged-out users get the cached page; logged-in users get fresh pages.

Cloudflare's own analytics

See the hit ratio in Cloudflare → Analytics → Cache.

Target: >70% hit ratio for content sites. Dashboard apps will be lower but still benefit from static-asset caching.

Purge cache after deploy

curl -X POST "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/purge_cache" \
    -H "Authorization: Bearer YOUR_API_TOKEN" \
    -H "Content-Type: application/json" \
    --data '{"purge_everything":true}'

Or purge specific URLs:

--data '{"files":["https://yourcompany.com/api/users","https://yourcompany.com/"]}'

Add this to your deploy pipeline.

Layer 3 — Reverse proxy (nginx / Varnish)

A reverse proxy caches responses after your app generates them, before they go out to Cloudflare or the visitor.

On Domain India cPanel hosting this layer already exists: nginx runs in front of Apache and can keep 200, 301 and 302 responses for up to 120 minutes (measured 22 September 2026). You can't configure it from your account. If a change doesn't show, add ?t= with a new value to the URL to check. Domain India DirectAdmin hosting has no proxy cache, so use browser headers and Cloudflare there.

On your own VPS, configure nginx yourself:

proxy_cache_path /var/cache/nginx keys_zone=STATIC:10m max_size=1g inactive=60m;

location /api/ {
    proxy_cache STATIC;
    proxy_cache_valid 200 5m;
    proxy_cache_valid 404 1m;
    proxy_cache_key "$scheme$request_method$host$request_uri";
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    add_header X-Cache-Status $upstream_cache_status;

    proxy_pass http://app;
}

The X-Cache-Status: HIT / MISS header shows the cache state.

Varnish (alternative, more powerful, VPS only):

sub vcl_backend_response {
    set beresp.ttl = 5m;
    set beresp.grace = 1h;    # serve stale during outages
}

See our Server-Side Caching article.

Layer 4 — Application cache (Redis)

The most flexible layer: your code decides what to cache. Redis is not available on Domain India shared hosting or the App Platform, so this layer runs on your own VPS; on shared hosting, use your framework's database or file cache instead.

See full patterns in our Redis Beyond Caching article.

Classic cache-aside:

async function getUser(id: string) {
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);
  const user = await db.user.findUnique({ where: { id } });
  await redis.setEx(`user:${id}`, 300, JSON.stringify(user));
  return user;
}

Cache tags (Laravel, Rails) — invalidate related keys together:

// Laravel
Cache::tags(['users', "user:{$id}"])->put("user.{$id}.profile", $data, 300);
// Later invalidate just this user:
Cache::tags(["user:{$id}"])->flush();

Layer 5 — Database-level

• Postgres materialized views for expensive aggregations:

  CREATE MATERIALIZED VIEW daily_stats AS
    SELECT date(created_at), count(*), sum(amount)
    FROM orders GROUP BY 1;
  REFRESH MATERIALIZED VIEW daily_stats;   -- schedule hourly

• Postgres pg_prewarm — load hot tables into shared_buffers on startup
• MySQL query cache (removed in 8.0; cache in your app instead)
• Read replicas — not caching exactly, but they spread the load

Invalidation strategies

Three approaches:

TTL-only (easy, eventual consistency)

Cache: 300s TTL
Updates: ignored
Result: users see stale up to 5 min

Works for: product catalogues, articles, rankings.

Explicit invalidation

async function updateUser(id, data) {
  await db.user.update({ where: { id }, data });
  await redis.del(`user:${id}`);
}

Works for: user profiles, settings, anything with a clear "owner".

Write-through

async function updateUser(id, data) {
  const user = await db.user.update({ where: { id }, data });
  await redis.setEx(`user:${id}`, 300, JSON.stringify(user));
}

The cache always matches the database. Best consistency, most code.

Cache stampede prevention

When a popular key expires, 1,000 concurrent requests can all hit the database. Prevent it with:

Lock (SET NX):

async function withLock(key, callback, lockTtl = 10) {
  const lockKey = `lock:${key}`;
  const acquired = await redis.set(lockKey, '1', { NX: true, EX: lockTtl });
  if (acquired) {
    try { return await callback(); } finally { await redis.del(lockKey); }
  }
  // Someone else is computing — wait briefly and try the cache again
  await new Promise(r => setTimeout(r, 100));
  const cached = await redis.get(key);
  return cached ? JSON.parse(cached) : callback();
}

Stale-while-revalidate / early refresh: see our Laravel + Redis cache article.

Hit ratio targets

Measure. Without data, you're guessing:

Monitor via:

• redis-cli INFO stats → keyspace_hits / (keyspace_hits + keyspace_misses)
• Cloudflare Analytics → Cache
• PostgreSQL: blks_hit / (blks_hit + blks_read) from pg_stat_database
• X-Cache-Status nginx header aggregated in logs

Common pitfalls

FAQ

Ready to build a fast cache stack? Put Cloudflare in front of cPanel hosting, or choose a VPS to run Redis and your own proxy cache.