A cache is a temporary storage layer that saves copies of web pages, files, or data so future requests can be served faster. Instead of regenerating the same page from scratch, the server (or the browser, or a CDN node) returns the saved copy in milliseconds. Well-configured caching can reduce page load times by 50-90%, directly improving Core Web Vitals and downstream SEO signals.
Caching is the single highest-leverage performance tactic on the web. Get it right and every visitor sees a faster site while your servers do less work. Get it wrong and users see stale prices, missing images, or the wrong shopping cart.
What is a cache?
A cache is any storage layer that keeps a copy of the result of an expensive operation so the operation does not have to run again. In web performance, the "expensive operation" is usually rendering an HTML page, executing a database query, or transferring a file over the network. Caches sit between the requester and the origin, intercepting requests and serving the saved copy whenever one is available.
Every web request typically passes through four cache layers:
- Browser cache — on the visitor's device
- CDN / edge cache — at a geographically-nearby node
- Reverse proxy cache — in front of your web server (Varnish, Nginx)
- Application cache — inside your app (Redis, Memcached)
Cloudflare reports that adding a CDN cache in front of an un-cached origin typically reduces Time-to-First-Byte (TTFB) by 60-80% and cuts origin bandwidth by 50-80%. Every 100ms of TTFB shaved off has been linked by Google to measurable ranking and conversion improvements.
Why caching matters for SEO
Caching is not a "nice-to-have optimisation" — it is one of the highest-ROI investments a technical SEO can make. Five reasons every performance-conscious team obsesses over it:
- Core Web Vitals become achievable. LCP under 2.5s and TTFB under 200ms are far easier with caching than without.
- Ranking signal. Google confirmed page speed as a ranking factor in 2010 and made Core Web Vitals official in 2021.
- Crawl efficiency. Faster responses mean Googlebot indexes more pages within its crawl budget.
- Lower bounce rate. Google research shows bounce probability rises 32% when page load goes from 1s to 3s.
- Cost reduction. A 90% cache hit ratio can slash origin infrastructure spend by an order of magnitude.
How caching actually works
Every cache follows the same lifecycle: request, check, serve, update.
GET /blog/awesome-post/ HTTP/1.1
# 2. CDN checks its cache
→ Is this URL cached and unexpired?
→ YES: return 200 OK with X-Cache: HIT
→ NO: forward to origin
# 3. On MISS, origin renders and returns HTML
HTTP/1.1 200 OK
Cache-Control: public, max-age=3600, s-maxage=86400
# 4. CDN stores the response and serves it
→ Future requests within TTL return HIT
The Cache-Control header is where caching behaviour is defined. Key directives:
public— anyone can cache thisprivate— only the browser can cache it, not shared cachesmax-age=3600— browser TTL in secondss-maxage=86400— shared cache (CDN) TTL in secondsno-store— do not cache at all (login pages, checkout)
Types of cache
| Cache type | Where it lives | What it caches | Typical TTL |
|---|---|---|---|
| Browser cache | Visitor's device | CSS, JS, images, fonts | 1 day - 1 year |
| CDN / edge cache | Global PoPs (Cloudflare, Fastly) | Full HTML + assets | 1 hour - 1 day |
| Reverse proxy | Varnish, Nginx | Rendered HTML | Minutes to hours |
| Object cache | Redis, Memcached | DB query results, API responses | Seconds to minutes |
| Opcode cache | PHP OPcache | Compiled PHP bytecode | Until deploy |
Real caching examples
1. Cloudflare Cache-Control on a marketing page
Cache-Control: public, max-age=300, s-maxage=86400
CF-Cache-Status: HIT
Age: 4321
The browser caches for 5 minutes, Cloudflare caches for 24 hours. The HIT status confirms this response came from the edge cache — TTFB will be under 50ms globally.
2. WordPress + Redis object cache
A WordPress site with 50 database queries per page adds a Redis object cache. Repeated queries now return in under 1ms instead of 20-40ms each. Server TTFB drops from ~800ms to ~120ms.
3. Purging a stale product page
POST /client/v4/zones/{zone_id}/purge_cache
{
"files": ["https://example.com/products/blue-widget/"]
}
Cache vs CDN — related but not the same
Every CDN is a cache. Not every cache is a CDN.
Cache (concept)
- Any temporary storage of computed results
- Lives in browsers, servers, apps, and CDNs
- Purely about reuse and speed
- Configured via headers or code
- Example: Redis, browser storage, OPcache
CDN
- A global network of edge servers
- Caching is one of its jobs (also security, TLS, routing)
- Purely about geographical proximity + speed
- Configured via dashboard + Cache-Control
- Example: Cloudflare, Fastly, Akamai
7 caching best practices for SEO teams
- Set long TTLs for static assets. CSS, JS, fonts, and images should cache for 1 year with fingerprinted filenames.
- Use shorter TTLs for HTML. Minutes to hours — long enough to matter, short enough that content stays fresh.
- Purge on publish. Every time a page updates, purge the specific URL from the CDN.
- Cache the full HTML on the edge. Serving HTML from a CDN node cuts TTFB more than any origin tweak.
- Never cache logged-in or personalised pages. Use
Cache-Control: private, no-storefor cart, account, and checkout URLs. - Monitor cache hit ratio. Target 95%+ on static, 70%+ on HTML. Sub-50% means your TTLs are wrong.
- Fingerprint your assets. Ship files as
app.4f2a1c.cssso cache-busting is automatic on deploy.
The most damaging caching bug is caching a personalised page — like a logged-in dashboard or a cart page — publicly on the CDN. One user starts seeing another user's data. Always exclude authenticated URLs and cookies from your cache key.
Common cache mistakes to avoid
- No
Cache-Controlheader at all. Browsers and CDNs guess conservatively and cache almost nothing. - Same TTL for HTML and assets. HTML needs freshness, assets do not.
- Caching auth-protected URLs publicly. Data leaks and privacy incidents.
- Forgetting to purge on publish. Users and Googlebot see stale content for hours.
- Cache keys that include tracking params.
?utm_source=twittercreates a new cache entry per campaign — hit ratio collapses. - Ignoring Vary headers. Serving the wrong language, currency, or mobile variant from cache.
How theStacc keeps pages fast without extra work
theStacc-generated pages ship with edge-cacheable, statically-rendered HTML and long-TTL fingerprinted assets by default. Publishing new content triggers a targeted CDN purge, and pages are pre-warmed on the edge so the very first visitor still gets a cache hit — no manual caching config, no stale pages.
Frequently asked questions
Yes, indirectly. Caching improves page speed and Core Web Vitals — both direct Google ranking signals. Faster pages also reduce bounce rate, increase crawl efficiency, and give Googlebot more budget to index deeper pages.
Browser cache stores resources on the visitor's device so repeat visits are near-instant. Server cache (or CDN cache) stores rendered pages closer to the request so first visits are faster. Great sites use both.
For browsers: DevTools → Application → Clear storage, or a hard refresh (Ctrl+Shift+R). For CDNs: use a purge API or dashboard button. For server-side caches: restart the caching layer (Redis, Varnish) or expire specific keys.
For static assets, aim for a cache hit ratio of 95% or higher. For dynamic HTML, 70-90% is achievable with smart TTLs. Sub-50% usually means TTLs are too short or cache keys are too specific.
Google previously offered a public 'Cached' link in SERPs but retired it in February 2024. Google still caches pages internally for indexing, but users can no longer view the cached copy from the search results.
Related glossary terms
Sources
