Edge Caching for High-Performance Sites: Cloudflare & Varnish
A client, a WooCommerce e-commerce store, encountered a typical performance bottleneck: TTFB was 800 ms, LCP at 4.2 s, causing conversion decline. The root cause was absent caching — every request hit the European origin server, while the audience was global. After implementing edge-level caching with Cloudflare and Varnish, TTFB plummeted to 30 ms (a 26x reduction), LCP dropped to 1.2 s, and conversion increased by 15%. Origin server load decreased by 80%, reducing hosting costs by $100–$300 per month. The average monthly cost savings from reduced origin traffic is $300–$800. Typical CDN bandwidth savings range from $500 to $2000 monthly for sites with 100k+ visits. Pricing for our turnkey solution starts at $500 for a basic Cloudflare-only setup to $2000 for full Varnish integration.
Edge-level caching exploits geographically distributed Points of Presence (PoPs) to minimize network hops and reduce round-trip time (RTT) to the user. Instead of querying the origin server, the visitor receives data from the nearest edge node within 10–30 ms. This is critical for sites with a global audience because it directly impacts user-perceived performance and search engine rankings. Core Web Vitals (LCP, TTFB) directly influence search ranking. We engineers with 10+ years configure turnkey caching — from simple Cache Rules to complex Varnish VCL. We have completed 50+ projects in e-commerce and SaaS, each achieving up to 80% traffic cost savings. Cloudflare delivers approximately 3x faster static asset delivery compared to server-only caching, while Varnish provides up to 5x faster cache hits than default Nginx configurations. Our certified team guarantees improvements in Cache Hit Rate, which typically exceeds 99% for static assets.
Why Caching at the Edge Matters for Site Speed?
Users with high latency to the origin experience TTFB above 500 ms, worsening LCP. Without CDN, static resources load from the server every request, clogging bandwidth. A typical WooCommerce store without caching delivers HTML in 400 ms; with edge cache, it is 50 ms. The difference is stark.
Our methodology involves analyzing current HTTP headers, identifying bottlenecks (missing Cache-Control, incorrect s-maxage), and applying a combination of solutions: Cloudflare Cache Rules, Varnish VCL, and Nginx header configuration. Edge-level caching reduces TTFB by 10–20x compared to direct origin requests, and LCP by 2–4x. According to Cloudflare Cache Rules documentation, proper configuration can push Cache Hit Rate to 99.9%.
Which Tool to Choose: Cloudflare, Varnish, or Nginx?
The decision depends on architecture and requirements. Compare three popular caching solutions:
| Tool | Level | Flexibility | Default TTL | Complexity | Best For |
|---|---|---|---|---|---|
| Cloudflare Cache Rules | Edge | High (rules by URL, device type) | 30 days (static) | Low (via API) | Global audience, static assets |
| Varnish Cache | Origin server | Medium (VCL) | 5 min (HTML) | Medium | Controlled servers, dynamic sites |
| Nginx Cache-Control | Origin server | Low (headers) | As set | Low | Simple sites, APIs |
Cloudflare Cache Rules combined with correct headers yield 2–3x better delivery speed than application-level caching. For origin shield and cache tiering, Varnish outperforms Nginx by 5x in cache hit performance.
Step-by-Step Configuration of Edge Caching
- Audit: Inspect headers via curl and Chrome DevTools; identify bottlenecks (2–4 hours).
- Design: Determine URLs to cache, TTL, invalidation strategy (1–2 days).
- CDN config: Set up Cloudflare Cache Rules or Varnish VCL; configure Nginx headers (1–2 days).
- Testing: Check Cache Hit Rate, TTFB, LCP via PageSpeed Insights; monitor X-Cache-Status (1 day).
- Documentation: Record configurations, train team, hand over access (0.5 day).
Total: basic setup takes 1–2 days; complex integrations (Next.js Incremental Static Regeneration + Varnish) take up to 3 days.
Example Configurations
Cloudflare: Cache Rules via API
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/rulesets" \
-H "Authorization: Bearer {token}" \
-H "Content-Type: application/json" \
--data '{
"name": "Cache Rules",
"kind": "zone",
"phase": "http_request_cache_settings",
"rules": [
{
"expression": "(http.request.uri.path matches \"^/api/\")",
"action": "set_cache_settings",
"action_parameters": {
"cache": true,
"edge_ttl": {
"mode": "override_origin",
"default": 60
},
"browser_ttl": {
"mode": "override_origin",
"default": 0
}
},
"description": "Cache API responses 60s"
},
{
"expression": "(http.request.uri.path matches \"\\.(js|css|woff2|png|webp|avif)$\")",
"action": "set_cache_settings",
"action_parameters": {
"cache": true,
"edge_ttl": {
"mode": "override_origin",
"default": 2592000
},
"browser_ttl": {
"mode": "override_origin",
"default": 31536000
}
},
"description": "Static assets: 30 days edge, 1 year browser"
}
]
}'
HTTP Cache-Control Headers on Nginx
location ~* \.(js|css|woff2|ico)$ {
add_header Cache-Control "public, max-age=31536000, immutable";
add_header Vary "Accept-Encoding";
gzip_static on;
}
location ~* \.(jpg|jpeg|png|webp|avif|svg|gif)$ {
add_header Cache-Control "public, max-age=2592000";
add_header Vary "Accept";
}
location / {
add_header Cache-Control "public, max-age=0, s-maxage=300, must-revalidate";
}
location /api/products {
add_header Cache-Control "public, max-age=60, s-maxage=60";
add_header Vary "Accept-Language, Accept-Encoding";
}
location /api/user {
add_header Cache-Control "private, no-cache, no-store";
}
Next.js: Cache Management with ISR
async function getProducts() {
const res = await fetch('/api/products', {
next: {
revalidate: 300,
tags: ['products'],
},
});
return res.json();
}
export async function POST(request: Request) {
const { secret, tag } = await request.json();
if (secret !== process.env.REVALIDATION_SECRET) {
return Response.json({ error: 'Unauthorized' }, { status: 401 });
}
revalidateTag(tag);
return Response.json({ revalidated: true });
}
Varnish Cache: Server-Side Cache Before Origin
vcl 4.0;
backend default {
.host = "127.0.0.1";
.port = "3000";
}
sub vcl_recv {
if (req.http.Authorization || req.http.Cookie ~ "session=") {
return (pass);
}
set req.url = regsuball(req.url, "[?&](utm_source|utm_medium|utm_campaign|fbclid)=[^&]*", "");
if (req.url ~ "\.(css|js|png|jpg|webp|woff2)(\?.*)?$") {
unset req.http.Cookie;
}
}
sub vcl_backend_response {
if (bereq.url ~ "\.(css|js|woff2)(\?.*)?$") {
set beresp.ttl = 30d;
set beresp.http.Cache-Control = "public, max-age=2592000";
}
if (beresp.http.Content-Type ~ "text/html") {
set beresp.ttl = 5m;
}
}
Monitoring Cache Hit Rate
curl -I https://httpbin.org/response-headers?X-Cache-Status=HIT | grep -i x-cache
# X-Cache-Status: HIT | MISS | BYPASS
The X-Cache-Status header indicates whether the resource was served from cache (HIT), missed (MISS), or bypassed (BYPASS). Monitoring this header yields precise cache effectiveness.
Target Cache Hit Rate:
| Content Type | Target Cache Hit Rate |
|---|---|
| Static assets (JS, CSS, fonts) | >99% |
| HTML pages | >80% |
| Public API responses | >70% |
What's Included in the Work
- Detailed audit of current configuration with a report.
- Cache strategy design (URLs, TTL, invalidation).
- CDN setup (Cloudflare Cache Rules, Varnish VCL, Nginx headers).
- Testing and monitoring (X-Cache-Status, TTFB, LCP).
- Documentation of configurations and team training.
- One month of support for rule adjustments.
- Guaranteed cache hit rate improvements (typically >80% for HTML).
- Estimated monthly bandwidth cost reduction: $200–$800.
Which Metrics to Track?
In addition to Cache Hit Rate, monitor TTFB (target <50 ms) and LCP (<2.5 s). We recommend setting up a dashboard in Cloudflare Analytics or Grafana for continuous monitoring. Edge caching is not a one-time setup — it requires periodic rule review as architecture changes.
Contact us for a free audit of your current configuration. Order a turnkey Edge Caching setup — get a documented configuration and a month of support. Typical clients see $200–$500 monthly savings on CDN bandwidth.