Edge Caching vs Origin Caching: Speed Up Site Response Times for SEO
Moderate 13 min 2026-03-20

Edge Caching vs Origin Caching: Speed Up Site Response Times for SEO

Quick Summary

  • What this covers: Compare edge caching (CDN) vs origin caching (Varnish, Redis) for improving TTFB. Choose the right caching strategy for Core Web Vitals optimization.
  • Who it's for: site owners and SEO practitioners
  • Key takeaway: Read the first section for the core framework, then use the specific tactics that match your situation.

Caching strategies reduce server processing time and improve Time to First Byte (TTFB), directly affecting Core Web Vitals and Googlebot crawl efficiency — edge caching serves content from geographically distributed CDN nodes (Cloudflare, Fastly, Akamai) with <50ms latency, while origin caching stores rendered pages or database query results at the application server layer (Varnish, Redis, Nginx FastCGI) with 100-300ms response times but no geographic distribution. Sites with global audiences benefit from edge caching's proximity advantages, but dynamic content (personalized product recommendations, user-specific data, real-time inventory) often bypasses CDN cache, requiring origin caching to avoid database hits on every request. Incorrect cache configurations — setting edge TTL too high and serving stale product prices, caching user-specific pages at edge (privacy violation), or missing cache-control headers that disable caching entirely — leave performance gains unrealized or create serious data exposure risks. This guide compares edge vs. origin caching architectures, implements hybrid strategies for dynamic e-commerce sites, and configures cache purging for content updates.

Edge Caching: How CDNs Cache Content

Content Delivery Networks (CDNs) cache content at edge locations worldwide.

How Edge Caching Works

1. Request flow:

User (London) → Cloudflare London Edge → Origin Server (US)

2. First request (cache miss):

3. Subsequent requests (cache hit):

Edge Caching Providers

Major CDN providers:

Cloudflare:

Fastly:

Amazon CloudFront:

Akamai:

Edge Caching Benefits

1. Geographic latency reduction:

2. Origin server protection:

3. Bandwidth cost savings:

Origin Caching: Server-Side Caching Layers

Origin caching stores content at the application server before it reaches CDN.

Origin Caching Types

1. Full-page caching (Varnish, Nginx FastCGI): Stores entire rendered HTML pages.

2. Object caching (Redis, Memcached): Stores database query results, API responses, fragments.

3. Opcode caching (OPcache for PHP): Stores compiled PHP bytecode (not content, but speeds execution).

Varnish Full-Page Cache

Varnish sits in front of web server, serves cached pages without hitting PHP/database.

Request flow:

User → CDN Edge → Varnish → Nginx/Apache → PHP/Database
         ↑                      ↑
    Cache hit (10ms)       Cache miss (200ms)

Varnish configuration:

vcl 4.0;

backend default {
  .host = "127.0.0.1";
  .port = "8080";
}

sub vcl_recv {
  # Remove cookies for static assets
  if (req.url ~ "\.(jpg|jpeg|gif|png|css|js|webp)$") {
    unset req.http.Cookie;
  }

  # Don't cache logged-in users
  if (req.http.Cookie ~ "wordpress_logged_in") {
    return (pass);
  }
}

sub vcl_backend_response {
  # Cache successful responses for 1 hour
  if (beresp.status == 200) {
    set beresp.ttl = 1h;
  }
}

Benefits:

Redis Object Caching

Redis caches database query results and expensive computations.

WordPress example:

// Check Redis cache
$cache_key = 'product_data_' . $product_id;
$product = $redis->get($cache_key);

if (!$product) {
  // Cache miss: query database
  $product = $wpdb->get_row("SELECT * FROM products WHERE id = $product_id");

  // Store in Redis (1 hour TTL)
  $redis->setex($cache_key, 3600, serialize($product));
}

return unserialize($product);

Benefits:

See WordPress database optimization.

Nginx FastCGI Cache

Nginx caches PHP responses without external caching layer.

Configuration:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=MYAPP:100m inactive=60m;

server {
  location ~ \.php$ {
    fastcgi_cache MYAPP;
    fastcgi_cache_valid 200 60m;
    fastcgi_cache_key "$scheme$request_method$host$request_uri";
    add_header X-Cache-Status $upstream_cache_status;

    fastcgi_pass unix:/var/run/php-fpm.sock;
  }
}

Benefits:

Edge vs. Origin: When to Use Each

Choose based on content type and audience.

Use Edge Caching When:

1. Static content:

2. Globally distributed audience:

3. High traffic:

4. Content updates infrequently:

Use Origin Caching When:

1. Dynamic content:

2. Frequently changing content:

3. Privacy-sensitive data:

4. Regional audience:

Hybrid Strategy: Edge + Origin Caching

Combine both for maximum performance.

Layer 1: Edge Caching (Static Assets)

Cache at Cloudflare edge:

Cloudflare Page Rule:

Cache Level: Cache Everything
Edge Cache TTL: 1 month
Browser Cache TTL: 1 day

Layer 2: Origin Full-Page Cache (Dynamic Pages)

Cache at Varnish/Nginx:

Don't cache at origin:

Layer 3: Object Cache (Database Queries)

Cache at Redis:

Implementation:

// Layer 3: Check Redis
$product = $redis->get('product_' . $id);

if (!$product) {
  // Layer 2: Varnish serves if cached
  // Layer 3 miss: Query database
  $product = get_product_from_db($id);
  $redis->setex('product_' . $id, 3600, serialize($product));
}

Request Flow with Hybrid Caching

Cache hit at each layer:

Request → Cloudflare Edge (hit: 20ms)
       ↓
Request → Varnish (miss, hit: 100ms)
       ↓
Request → Redis (miss, hit: 150ms)
       ↓
Request → Database (miss: 500ms)

Best case: Edge hit = 20ms TTFB Worst case: Database query = 500ms TTFB

Cache Control Headers

HTTP headers control caching behavior at edge and browser.

Cache-Control Directive

Public (cacheable by edge and browser):

Cache-Control: public, max-age=86400

Private (browser only, not edge):

Cache-Control: private, max-age=3600

No cache:

Cache-Control: no-store

Set Cache Headers (Apache)

# .htaccess
<FilesMatch "\.(jpg|jpeg|png|gif|webp|svg)$">
  Header set Cache-Control "public, max-age=2592000"
</FilesMatch>

<FilesMatch "\.(css|js)$">
  Header set Cache-Control "public, max-age=604800"
</FilesMatch>

Set Cache Headers (Nginx)

location ~* \.(jpg|jpeg|png|gif|webp)$ {
  expires 30d;
  add_header Cache-Control "public, immutable";
}

location ~* \.(css|js)$ {
  expires 7d;
  add_header Cache-Control "public";
}

Vary Header for Dynamic Content

Serve different cached versions based on headers:

Vary: Accept-Encoding, Cookie

Example: Serve compressed vs. uncompressed, logged-in vs. logged-out users.

Cache Purging and Invalidation

Update content without waiting for TTL expiration.

Cloudflare Cache Purge

API purge:

curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/updated-page.html"]}'

WordPress plugin: Cloudflare plugin auto-purges on post publish.

Varnish Cache Purge

PURGE request:

curl -X PURGE https://example.com/updated-page

Varnish VCL:

sub vcl_recv {
  if (req.method == "PURGE") {
    return (purge);
  }
}

Programmatic Invalidation

Invalidate cache after content updates:

// After saving product
function purge_product_cache($product_id) {
  $url = "https://example.com/products/" . $product_id;

  // Purge Cloudflare
  cloudflare_purge($url);

  // Purge Varnish
  shell_exec("curl -X PURGE $url");

  // Clear Redis
  $redis->del('product_' . $product_id);
}

Frequently Asked Questions

Does edge caching hurt dynamic e-commerce sites with personalized content?

Not if configured correctly. Use Vary: Cookie header to serve different cached versions for logged-in vs. logged-out users. Or bypass edge cache entirely for logged-in users, use origin caching only. Example: Cloudflare Page Rule excludes /cart and /my-account from edge cache. Static assets (images, CSS) always benefit from edge caching.

What's the difference between CDN and caching?

CDN (Content Delivery Network) is the infrastructure (global edge servers). Edge caching is the feature (storing content at edge servers). All major CDNs include caching, but CDNs also provide DDoS protection, load balancing, and SSL termination. Some CDNs (basic tiers) don't cache HTML by default — only static assets. See DNS configuration for CDN setup.

How long should cache TTL be for e-commerce product pages?

15-60 minutes for product pages with price/inventory changes. 1-6 hours for static product info (descriptions, images). Edge TTL shorter than origin TTL (edge: 15min, origin: 1hr) allows faster content updates at edge while reducing origin load. Use cache purge API for immediate updates after manual changes. See Core Web Vitals optimization.

Can I use edge caching with WordPress or Shopify?

Yes. WordPress: Use Cloudflare plugin or WP Rocket with CDN integration. Shopify: Shopify includes Fastly CDN by default (built-in edge caching). Custom Shopify Plus stores can use additional CDNs. Most CMSs work with edge caching with proper cache-control headers. Test logged-in user experience to ensure personalization still works.

Will caching fix slow database queries?

Origin caching (Redis) caches query results, avoiding slow queries after first execution. Edge caching doesn't help database speed (queries still run on cache miss). For slow databases, optimize queries first (see WordPress database optimization), then add Redis object caching, then add edge caching for maximum speed. Caching masks database issues but doesn't fix root causes.

When This Fix Isn't Your Priority

Skip this for now if:

This is one piece of the system.

Built by Victor Romo (@b2bvic) — I build AI memory systems for businesses.

See The Full System View Repo
← All Fixes