Page caching and CDN behavior for WordPress and Drupal

Two things tend to go wrong with page caching, and they are opposites. Either a change does not appear because an old copy is being served, or the site is slow because pages that should be cached are being rebuilt for every visitor. Both have the same root: knowing which requests can be cached, for how long, and how the cache is cleared. Once you can read the headers, both problems usually take minutes to diagnose.

How a cached page is served

For an anonymous visitor, the full HTML of a page is the same for everyone. So instead of running PHP and querying the database for each request, the CDN or a page cache stores the finished HTML and hands it out directly. A cached page can be served in tens of milliseconds, and thousands of visitors cost the web servers almost nothing.

Logged-in users, shopping carts, and personalized pages are different. The HTML varies per person, so it must not be shared. The trick is to cache everything that is the same for everyone and bypass the cache for everything that is not.

Reading the headers

curl -sI https://www.example.gov/services/ | grep -iE "cache-control|age|x-cache|set-cookie|vary"

• Cache-Control says whether and how long the page may be cached. no-cache, private, or max-age=0 on a public page means something is preventing caching.
• X-Cache (or a similar header from your CDN) shows hit or miss. Age shows how long the copy has been cached.
• Set-Cookie on an anonymous page is a red flag. Most CDNs will not cache a response that sets a cookie.
• Vary: Cookie tells the cache to keep a separate copy for every cookie combination, which in practice means no caching.

Why a page will not cache

How long should pages be cached?

For most institutional sites, caching HTML for somewhere between 15 minutes and an hour, combined with purging on publish, gives both speed and freshness. Static assets such as CSS, JavaScript, and images can be cached for much longer when their URLs change with each new version, which both platforms do by default for their own assets.

Purging: targeted beats everything

When content changes, the cached copies need clearing. Clearing the whole cache on every edit is the simplest approach and the most expensive: every page then has to be rebuilt at once, which can slow a busy site noticeably.

• Drupal has cache tags built in. Every cached page knows which content it contains, so editing a node can purge exactly the pages that show it. The Purge module family connects those tags to the CDN or reverse proxy.
• WordPress relies on the page cache plugin or CDN integration to purge the edited post, its archives, and the homepage. The quality of these integrations varies, so it is worth testing what actually gets purged.

Where Drupal's own caches fit

Drupal core includes the Internal Page Cache for anonymous visitors and the Dynamic Page Cache, which caches the parts of a page that are the same for logged-in users. When a CDN handles anonymous traffic, the Internal Page Cache becomes a second line of defense rather than the main one. See caching layers for Drupal for the full picture.

One more check is worth doing after any caching change: log in, browse a few pages, log out, and confirm you never see another person's name, cart, or admin toolbar. Personalized content leaking into a shared cache is rare, but it is the one caching mistake that is a privacy problem as well as a bug.

How eWay runs page caching

eWay configures the CDN (CloudFront on AWS or Azure Front Door on Azure) together with the platform's page cache, sets cache rules by content type, strips marketing query strings from cache keys, and connects purging to publishing so edits appear quickly without clearing the entire cache. eWay monitors cache hit ratio and origin load, and when a plugin or module starts blocking caching, tracks down the cause rather than turning caching off.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• The URL, and whether the problem is stale content or slow pages
• The header output from the command above
• Any plugin, module, or marketing tool added recently

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: object caching with Redis and scaling WordPress and Drupal for traffic spikes. More on our WordPress and Drupal pages.