Identify the cached item before changing a setting: HTML, application data and static files need different investigations.
Three different items can be cached
A page cache reuses a rendered response. An object cache reuses application data, while a browser cache can reuse downloaded resources such as stylesheets. WordPress documents these as separate caching mechanisms. Enabling one does not tell you whether the others are working. A public article can have a quick HTML response and still download unnecessarily large images.
Draw your stack before changing it
Write one row for each component: WordPress plugin, hosting page cache, persistent object cache, CDN and browser. Beside each, record the item it stores, the person or service controlling it, and the documented purge action. Mark unknowns explicitly rather than assuming your plugin controls the hosting layer. This small inventory is especially useful when hosting includes optimization automatically.
Use the symptom to choose the layer
If an edited headline is stale for signed-out visitors, begin with HTML caching. If the headline is fresh but the design is old, inspect the stylesheet URL and response. If uncached pages remain slow, gather server timing evidence before assuming a browser-cache setting will help. These are starting hypotheses; response headers and the provider's documentation should confirm them.
Run a controlled content change
On staging, update a harmless sentence in a public article. Record which sessions see the change before purging anything. Purge one managed layer at a time and repeat the same request. Keep the browser test separate from the CDN test so you can identify which operation changed the result. Avoid repeatedly purging everything: it removes evidence about where the stale response lived.
Make the result operational
Your final record should name the layer responsible, the verified purge procedure and the affected pages. Add that procedure to the content-publishing checklist. If you cannot tell which layer serves a response, ask the hosting provider for a documented cache-status indicator. Do not infer a cache hit solely from a fast response; a naturally fast uncached page can look similar.
Put it into practice
- Inventory every cache layer and its owner.
- Record the stale or slow item, not just the URL.
- Compare signed-out and signed-in sessions.
- Purge one layer and retest the same request.
- Document the working procedure for future editors.
AI-assisted educational content prepared for the Velonic resource library. How these guides are prepared.