WordPress caching explained: page, object, browser, and edge

Caching means doing expensive work once and reusing the result instead of redoing it for every visitor. On WordPress that work happens in a few separate layers, and most sites only set up one of them. Set up all of them and your server spends most of its day handing out files it already made.

I touched on this in how to actually speed up a WordPress site. Here is the longer version: the layers, from the database out to the visitor, and what each one is actually for.

Page caching: the big one

A WordPress page is not a file. Every request runs PHP, queries the database, and assembles the HTML from scratch. Page caching does that once, saves the finished HTML, and serves the saved copy to everyone after. The server goes from running a program to handing over a file.

This is the single highest-impact cache, because it attacks time to first byte directly. Google’s rough target is a TTFB of 0.8 seconds or less, and you cannot hit that if every request rebuilds the page in PHP. A warm page cache turns a 600 millisecond render into a few milliseconds of reading a file, and a fast TTFB is the foundation every other LCP fix sits on.

You get page caching from a plugin (the well-known caching plugins all do it) or, better, from the server itself with something like NGINX FastCGI cache, or a managed host that bakes it in. The one rule: do not cache pages for logged-in users or anything personal, like a cart or an account screen. Serving one person’s session to someone else is how caching turns from a speedup into a security incident.

Object caching: for the work page cache cannot skip

Page caching only helps when you can reuse a whole page. Logged-in dashboards, search results, busy stores, and anything built per request still has to run queries. Object caching makes those queries cheaper.

WordPress already has an object cache, but by default it only lasts for a single request. It forgets everything the moment the page finishes rendering. A persistent object cache, backed by Redis or Memcached, keeps those query results in memory across requests, so the second visitor reuses the first one’s database work. WordPress will even nudge you about it: the Site Health screen recommends a persistent object cache once a site is busy enough to benefit.

This is the layer to add when page caching is already in place and the site is still slow on the pages it cannot cache. On a small brochure site you may never need it. On a membership site or a store, it is often the difference.

Browser caching: stop re-downloading the same files

The first layers live on your side. Browser caching lives on the visitor’s. When someone loads a second page, their browser should already have your CSS, JavaScript, fonts, and logo rather than downloading them again.

You control this with the Cache-Control response header. The trick is to put a version or hash in each asset filename (style.4f2a.css) so the URL changes whenever the file does. That lets you cache as hard as possible with no risk of serving a stale file. web.dev recommends Cache-Control: public, max-age=31536000, immutable for fingerprinted assets, which tells the browser to keep the file for a year and not even ask whether it changed. Your images earn the same treatment.

Most caching plugins and CDNs set sensible headers for you. Check them in the Network panel anyway, because a short or missing max-age on static assets is free performance left on the table.

Edge caching: move the cache closer to the visitor

The last layer is about distance. Even a perfectly cached page still has to travel from your server to the visitor, and a request from the other side of the world is slow no matter how fast your server is.

A CDN, or a platform like Cloudflare, stores your cached pages and assets in locations around the world and serves each visitor from the nearest one. For static assets this is standard. For full-page HTML it takes more care (the same logged-in rule applies), but when it works your origin server barely gets touched and everyone gets a nearby copy.

This site runs on exactly that model: static files on a CDN, with no PHP to run at all. That is the far end of the caching idea, a site that is nothing but cache.

Which layers you actually need

Start with page caching. It is the biggest win and the easiest to add. Then set long-lived browser caching on your versioned assets. Add a persistent object cache if the site is dynamic or busy enough to still drag after the first two. Put a CDN in front for the network distance.

A cache is always a trade against freshness, so every layer needs a clear-on-update story: publish a post and that page’s cache clears, ship new CSS and the filename changes so the browser fetches it. Get that wiring right and caching is about as close to free speed as WordPress offers.

For the bigger picture this fits into, see how to actually speed up a WordPress site, and for why a fast server response matters so much, Core Web Vitals for WordPress.