What Is a Cache? The Speed Trick Behind Every Fast Site

Aug 01, 2026 · SEO Glossary

There's a coffee shop near my old office where the barista started making my flat white when I was still crossing the street. No order taken, no questions — she'd seen me every weekday for a year and cached the answer. Total transaction time: about forty seconds instead of four minutes.

That's caching. What is a cache, in computing terms? It's a storage layer that keeps copies of expensive-to-produce results — files, database query outputs, rendered pages — so the next request for the same thing can be served from the copy instead of redoing the work. Nearly everything fast about the modern web is caching wearing different uniforms.

What is a cache doing for a website, concretely?

Consider what happens when someone loads a product page with no caching anywhere. Their browser asks your server; your server runs PHP or Python; the code makes eight database queries; a template renders; the HTML travels back across the ocean; then the browser separately fetches forty images, stylesheets, and scripts, each one another round trip. Do all of that fresh for every visitor, on every page view, and a modest traffic spike will flatten your server — while every individual visitor waits seconds for work that was identical to the last visitor's.

Caching attacks that waste at every layer. And "layers" is the right mental model — a single page load can hit four different caches, each catching what the previous one missed.

The four layers, from visitor to database

1. Browser cache

The visitor's own machine. The first time someone loads your site, their browser stores the logo, CSS, fonts, and scripts locally. On the next page view, those files load from disk in milliseconds instead of over the network. You control this with HTTP headers — chiefly Cache-Control, which says how long a file may be reused (e.g. max-age=31536000 for a year on files that never change). This is why the second page of a visit always feels snappier than the first, and why PageSpeed Insights nags about "serve static assets with an efficient cache policy" when your headers are missing or timid.

2. CDN / edge cache

Copies of your files stored on servers physically near your visitors, so a request from Melbourne doesn't have to travel to Virginia. This layer is big enough to deserve its own article — see what a CDN is — but the short version: static assets get served from the edge, your origin server barely hears about them, and global visitors stop paying the distance tax.

3. Server / page cache

Your server storing fully rendered HTML. When a WordPress page is assembled — theme, plugins, database queries, the lot — a page cache saves the finished output, and the next visitor gets that stored HTML in a few milliseconds instead of a few hundred. For mostly-static content sites this is the highest-leverage layer that site owners actually control: plugins like WP Rocket or W3 Total Cache, or server-level tools like Varnish and nginx's FastCGI cache, routinely cut server response times (TTFB) from 800ms to under 100ms.

4. Object / database cache

Inside the application: tools like Redis or Memcached storing individual query results and computed fragments, so dynamic pages that can't be fully cached (carts, dashboards, logged-in views) still avoid re-running the same expensive queries. You'll care about this layer when your site has lots of logged-in users; until then, it's your host's problem.

Why SEO people care about any of this

Speed is the bridge. Caching is the primary mechanism behind good Core Web Vitals — particularly Largest Contentful Paint and server response time, which no amount of front-end tinkering can fix if every page load runs the full database gauntlet. Page experience feeds rankings; more importantly, it feeds conversions and bounce behavior. There's also a crawl angle: Googlebot fetches faster from a cached, quick-responding site, and on large sites that measurably improves how much gets crawled.

If you want to see where you stand, PageSpeed Insights will flag missing cache headers and slow server responses per page, and a full crawl shows response times across the whole site — put your site through a free audit and sort by slowest pages to find where the caching isn't doing its job.

When caching bites you

Every developer eventually says the industry's favorite joke out loud: there are only two hard things in computer science — cache invalidation and naming things. Invalidation is the real teeth of it. A cache serving old content doesn't know it's old, which produces classic failure modes:

• You fix a typo and it won't go away. The page cache is serving last Tuesday's HTML. You purge the cache — or wait out its TTL — and the fix appears. Every CMS caching plugin has a "clear cache" button for exactly this.
• The CSS changed but browsers cached the old file for a year. The standard fix is cache busting: fingerprint filenames (styles.a8f3e2.css) so a changed file is a new URL, letting you cache aggressively and update instantly. Every modern build tool does this automatically.
• Personalized content got cached and shown to the wrong person. The scary one — a logged-in user's page cached and served to someone else. This is why carts and account pages must be excluded from page caching, and why misconfigured Vary headers are a genuine security matter, not just a performance one.
• You're testing a fix and can't tell if it's live. Hard-refresh (Ctrl+Shift+R), or use Chrome DevTools → Network with "Disable cache" ticked. When debugging, always know which layer you're looking at.

A sensible caching setup for a normal site

1. Long-lived Cache-Control headers on static assets, with fingerprinted filenames so updates propagate instantly.
2. Full-page caching for anonymous visitors, excluded for carts, checkouts, and logged-in sessions.
3. A CDN in front if your audience is geographically spread — most now include sensible cache defaults out of the box.
4. A cache-purge step in your publishing workflow, so editors never file "my update isn't showing" tickets.

None of this is exotic; it's mostly configuration that pays out on every single page view afterward. The barista principle, applied ruthlessly: never do the same work twice when a stored copy will do.