---
title: "Page cache, object cache, edge cache: which one you actually need"
id: "296"
type: "post"
slug: "page-cache-object-cache-edge-cache-which-one-you-actually-need"
published_at: "2026-08-02T09:00:00+00:00"
modified_at: "2026-10-06T15:11:12+00:00"
url: "https://danielpazwp.com/page-cache-object-cache-edge-cache-which-one-you-actually-need/"
markdown_url: "https://danielpazwp.com/page-cache-object-cache-edge-cache-which-one-you-actually-need.md"
excerpt: "Page, object and edge caches solve different problems. What each one stores, who it helps, its trade-offs and the order to add them."
taxonomy_category:
  - "Performance"
---

[Performance](https://danielpazwp.com/category/performance/)
6 min read

# Page cache, object cache, edge cache: which one you actually need

Page, object and edge caches solve different problems. What each one stores, who it helps, its trade-offs and the order to add them.

Published **02/08/2026**Updated **06/10/2026**6 min read

[Written byDaniel PazDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.](https://danielpazwp.com/author/daniel-paz/)

Most WordPress sites need a page cache first, a persistent object cache second, and an edge cache only when visitors are spread across regions or the traffic spikes are real. A page cache stores the finished HTML, so PHP and MySQL do not run for anonymous visitors. An object cache (Redis or Memcached) keeps database query results in memory between requests, which matters for logged-in users, WooCommerce carts and admin screens that page caching cannot serve. An edge cache stores the HTML on a CDN close to the visitor and cuts network latency. Each one solves a different problem, so the answer is usually a combination, added in that order.

## What does each cache layer store?

People mix them up because all three are called “cache” and all three make the site faster. They sit at different points of the request, though, and each one only helps the requests that reach it.

- **Page cache** stores the complete HTML response for a URL. The next anonymous visitor gets a file or a memory entry, and WordPress never boots.
- **Object cache** stores pieces of data WordPress already asked for: query results, options, post objects, transients. WordPress still runs, but it talks to the database far less.
- **Edge cache** stores the HTML (and static assets) on CDN servers around the world, so the response does not travel back to your origin at all.

WordPress ships with an object cache, but by default it is non-persistent: it lives for one request and then gets thrown away. When someone says “add an object cache”, they mean installing a drop-in (`object-cache.php`) that connects it to Redis or Memcached, so the data survives between requests.

| Layer | Where it lives | What it skips | Who benefits | Main risk |
| --- | --- | --- | --- | --- |
| Page cache | Server disk or memory (plugin, Nginx, Varnish) | PHP and MySQL entirely | Anonymous visitors | Serving stale or personalised content |
| Object cache | Redis or Memcached on the server | Repeated database queries | Logged-in users, WooCommerce, admin, uncached pages | Hiding slow code instead of fixing it |
| Edge cache | CDN points of presence | The trip to your origin | Visitors far from the server, traffic spikes | Purge logic and cache-bypass rules |

## Why the page cache comes first

I see the same thing in audits over and over: a slow time to first byte, a long list of optimisation plugins, and no working page cache. Or there is a page cache, but it gets bypassed because a plugin sets a cookie on every visit or a query string variation makes every URL unique.

On a content site, a working page cache is the biggest server-side win you can get. A cached response goes out in tens of milliseconds, against the hundreds it takes to bootstrap WordPress, load plugins and run queries. That improves TTFB directly, and TTFB is the floor under your Largest Contentful Paint. If the HTML arrives late, nothing else on the page can be early.

Check that it works before you move on. Load a page in a private window and look at the response headers. Most cache layers expose a header that shows a hit or a miss. If you only ever see misses, find out why before you buy anything else.

## When does a persistent object cache pay off?

Page caching has a hard limit. It only works for responses that are identical for everyone. Logged-in users, membership areas, the WooCommerce cart and checkout, account pages, the admin and the REST API all bypass it, and they should. Those requests hit PHP and MySQL every time.

That is the job for Redis or Memcached. WordPress loads options, user meta, term relationships and post data on every request, and with a persistent object cache most of those lookups come from memory instead of the database. You notice it most on:

- WooCommerce stores, where cart, checkout and my-account are uncacheable by design.
- Membership, LMS and community sites where most users are logged in.
- Large catalogues or sites with heavy admin use, where editors feel the slowness first.
- Sites with expensive transients or API calls that are cached through the transients API.

On a small brochure site, where almost every visitor is anonymous and the page cache hits, a persistent object cache adds little. It does no harm, but it is one more service to run and monitor.

> An object cache makes repeated queries cheap. It does not make a bad query good. If one query takes two seconds on a cache miss, users will still meet that miss.

This is the trap I warn clients about most. A slow uncached query, a bloated `wp_options` table with megabytes of autoloaded data, or a plugin that writes to the database on every page view will still hurt. Fix those first, then let the object cache absorb the normal load.

## Do you need an edge cache or a CDN for HTML?

Most sites already put images, CSS and JavaScript on a CDN. Caching the HTML itself at the edge is a separate step. The server stops being involved in anonymous page views at all, and the CDN answers from the location closest to the visitor.

It pays off when the audience is far from the origin server. If the server is in São Paulo and half the visitors are in Europe, every uncached request pays for a round trip across the Atlantic before the first byte arrives. A page cache does nothing about that distance. An edge cache does. It also protects the origin during traffic spikes, since the CDN absorbs repeated requests for the same URL.

The price is complexity. You need correct `Cache-Control` headers, purge on publish and update, and bypass rules for logged-in cookies, cart sessions and preview links. Get those wrong and you serve one user’s cart to another, or keep showing an old price for hours. Edge caching is worth it once the page cache and its bypass rules are already correct, because the edge copies whatever the origin tells it to.

## How to decide for your site

Start from who your visitors are and which requests are slow, not from a list of tools. This is the decision path I use:

- Mostly anonymous visitors, one region: a properly configured page cache, with static assets on a CDN. Stop there until data says otherwise.
- Mostly anonymous visitors, global audience or spiky traffic: page cache plus edge caching of HTML, with purge on publish.
- WooCommerce, memberships or many logged-in users: page cache for public pages plus a persistent object cache for everything that bypasses it.
- Large store with an international audience: all three, configured so each layer respects the same bypass rules.

Whatever the combination, measure after each change. Watch TTFB on cached and uncached pages separately, check hit ratios, and confirm in field data that LCP at the 75th percentile is moving toward 2.5 seconds or less. Treat caching as infrastructure, not a checkbox, and pick the layer that removes the work your slowest real requests are doing today.

[Work with Daniel](https://danielpazwp.com/#book)
[More in Performance](https://danielpazwp.com/category/performance/)

[About the authorDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.Author page](https://danielpazwp.com/author/daniel-paz/)

## Related articles

[All articles](https://danielpazwp.com/blog/)

[Performance Oct 2026What is enterprise WordPress?](https://danielpazwp.com/enterprise-wordpress/)
[Performance Oct 2026Headless WordPress: when it makes sense and when it does not](https://danielpazwp.com/headless-wordpress/)
[Performance Oct 2026How to speed up Elementor: the fixes that matter](https://danielpazwp.com/speed-up-elementor/)