WordPress Caching Layers: Page, Object and Edge

WordPress caching works in three layers: a page cache that stores finished HTML, an object cache that keeps database query results in memory, and an edge cache that serves pages from a CDN close to the visitor. Each layer solves a different problem, and each needs rules for when it must step aside, such as for logged in editors and shoppers with items in their cart. Get those bypass rules and the purge strategy right, and the site stays fast without showing anyone stale or private content.

Why WordPress caching needs more than one layer

Every uncached WordPress request runs PHP, loads plugins and queries the database before sending any HTML. On a busy publisher or WooCommerce store, that work repeated for every visitor means slow responses and an overloaded server.

Caching removes repeated work, but no single cache covers every request:

• Page cache helps anonymous visitors on pages that look the same for everyone.
• Object cache helps the requests a page cache cannot serve: the admin area, logged in users, carts, checkout, search and API calls.
• Edge cache moves cached pages and static files to a CDN, so the request may never reach your server at all.

WordPress itself recognises this split. Since version 6.1, the Site Health screen includes separate checks for a persistent object cache and for a page cache, according to the WordPress core team. If either check raises a recommendation on your production site, that is a useful starting point.

Layer one: the page cache

A page cache saves the complete HTML of a page the first time it is built, then serves that copy to the next visitors without running WordPress again. It is the layer that makes the biggest difference to time to first byte for anonymous traffic.

Where the page cache can live

• A caching plugin that writes HTML files to disk and serves them early in the request.
• The web server or a reverse proxy, such as Nginx FastCGI cache or Varnish, which answers before PHP starts. Many managed WordPress hosts run this for you.
• The CDN, covered below as the edge layer.

Pick one primary page cache. Two layers both caching HTML cause purges that seem not to work and pages that differ depending on which cache answered.

Cache lifetime

Set lifetimes by content type. A homepage that changes daily needs a short lifetime; evergreen service pages can be held longer, because a good purge refreshes them when an editor makes a change.

Layer two: the object cache with Redis or Memcached

WordPress has a built in object cache, but by default it only lasts for a single request. The WordPress developer reference states that the object cache is non persistent by default and that a persistent backend, such as Redis or Memcached, can replace it through a drop in file in wp-content.

With an object cache Redis setup, the results of expensive queries, options and transients are kept in memory between requests. The next request that needs the same data reads it from Redis instead of running the query again.

Where it pays off

• Logged in users, including editors working in the dashboard.
• WooCommerce cart, checkout and account pages, which cannot be page cached.
• Search, filtered archives and REST API requests, including a headless front end calling WordPress for content.
• Membership and learning platforms where most visitors are logged in.

What to watch

• Memory sizing and eviction. If Redis runs out of memory, it starts evicting keys. Set an eviction policy and monitor the hit rate rather than guessing.
• Shared servers. When several sites share one Redis instance, give each a unique key prefix or database so one site cannot read or flush another's data.
• Plugins that misuse transients. A plugin that writes large or constantly changing transients can fill the cache with data nobody reads again.

Layer three: CDN edge caching

CDN edge caching stores responses on servers spread across many locations. A visitor in Abu Dhabi, Riyadh or London is served from a nearby point of presence rather than from your origin server, which may be in a different country.

Static files versus full pages

Most CDNs cache images, CSS, JavaScript and fonts by default. Caching WordPress HTML at the edge is usually an explicit rule, and it carries the biggest gains and risks: the page cache bypass rules must also apply at the CDN, or the edge may serve a logged in view to a stranger.

Headers that control the edge

• Send clear cache lifetime headers from the origin for pages you want held at the edge.
• Mark private responses, such as account and cart pages, as not cacheable.
• Avoid varying the cache on cookies that do not change the page, such as analytics cookies, or your hit rate will collapse.

For a decoupled build, edge caching works differently again, because the front end is a separate application. Our guide to headless WordPress with Next.js covers how revalidation replaces some of these rules.

Cache bypass rules for logged in and cart users

Cache bypass rules decide which requests skip the page and edge caches. Misconfigured, they cause anything from a confusing cart to private data shown to the wrong person.

Logged in users

WordPress sets a login cookie whose name begins with wordpress_logged_in. Any request carrying it should bypass the page and edge caches. The same applies to the comment author cookies if visitors see personalised comment forms, and to password protected posts.

WooCommerce shoppers

WooCommerce documentation on configuring caching plugins lists the pages and cookies to exclude:

Check the current version of that page when you configure a store, as plugins and extensions can add their own cookies.

Other requests that should skip the cache

• wp-admin, wp-login.php and admin-ajax.php.
• POST requests and form submissions.
• Preview links and requests with query strings that change content, such as search or filters, unless you deliberately cache them.
• Pages with per visitor content: currency switchers, geolocated prices or language detection based on cookies.

Hypothetical example: a Dubai retailer adds a currency switcher that stores the choice in a cookie. The page cache ignores that cookie, so a visitor who chose one currency sees prices cached for another. The fix is either to vary the cache on that cookie or, better, to give each currency its own URL so each version can be cached cleanly.

A purge strategy that does not break content updates

The best cache is only as good as its purge strategy. Editors need to see their changes go live quickly, and the site should not lose its whole cache every time someone fixes a typo.

Purge by relationship, not everything

When a post is updated, purge that post, the homepage if it lists recent posts, the relevant category and tag archives, the author page and the feeds. Most mature caching plugins and host integrations handle this automatically when they hook into WordPress publish events. A full cache flush should be the exception, used after theme deployments or menu changes that affect every page.

Keep the layers in order

1. Clear the object cache keys affected by the change, if the content is cached there.
2. Purge the server page cache for the affected URLs.
3. Purge the same URLs at the CDN, using its API or a tag based purge if your CDN supports cache tags.

Purging the edge before the origin can let the CDN refetch the old page and cache it again.

Warm the important pages

After a large purge, preload the homepage, key landing pages and top products so real visitors, especially during a campaign, do not pay the rebuild cost.

Testing and monitoring your caching setup

• Read the response headers. Most caches add a header showing a hit or a miss. Check it for a homepage, a post, a product and the cart, both logged out and logged in.
• Test in a private window with items in the cart. Confirm the cart count and prices are correct on cached pages.
• Watch the object cache hit rate and memory use in Redis or your host's dashboard.
• Retest after plugin changes. A new plugin can add cookies or headers that quietly disable caching.

Caching can hide a slow site but cannot fix an overloaded architecture. If you are deciding whether WordPress is still the right base, read when WordPress is the wrong choice and the case for hybrid WordPress. For teams weighing quick site builders, AI builders versus WordPress for a production site compares what you control in each.

Getting caching configured properly with Codeeo

Codeeo's WordPress development team configures page, object and edge caching as part of builds and performance work, including bypass rules for WooCommerce stores and purge rules that match how your editors publish. If your site is already live and slow, a speed optimisation review or our Core Web Vitals work is a sensible first step. With an office in Dubai, UAE clients can meet the team in person. Contact Codeeo to talk through your setup.