A green “cache enabled” indicator does not prove that the tested response came from cache. Logged-in cookies, query strings, WooCommerce sessions, mobile variants or a CDN miss can send the request back through PHP and MySQL.
Trace one public response from edge to origin before changing plugins or hosting.
Define the response you are measuring
Test a normal public URL in a private session. Use the canonical HTTPS address without tracking parameters and make two or three requests separated by a few seconds.
Inspect headers:
curl -sS -D - -o NUL https://example.com/service/On Windows, NUL discards the body; on Linux or macOS use /dev/null. Run this only against a site you control.
Look for cache status headers, Age, server timing and unexpected redirects. Header names differ between hosts and CDNs, so interpret them using the provider’s documentation.
Separate a miss from a slow hit
The first request after a purge may legitimately be a miss while PHP generates the page. A second identical request should normally be a hit if the page is cacheable.
If every request misses, find the bypass reason. If headers report a hit but TTFB remains high, inspect CDN location, connection setup and whether the header refers to an inner cache while another slow layer still sits in front.
Do not average hits and misses together. They describe two different visitor experiences.
Check cookies and personalised content
Page caches commonly bypass logged-in users and visitors with cart or session cookies. Open a fresh private window and inspect request cookies.
A marketing or consent plugin can set a cookie that unintentionally matches a broad bypass rule. WooCommerce pages such as cart, checkout and account should not be cached as ordinary public HTML, but an informational service page usually should.
Never remove ecommerce exclusions just to create a hit. Confirm whether the tested URL contains personalised content.
Inspect URL variations
Trailing slashes, HTTP-to-HTTPS redirects, www variants and tracking parameters can create separate cache keys. A performance tool may test a URL that first redirects or never warms the canonical variant.
Choose one canonical address and make redirect chains direct. Decide whether harmless marketing parameters can reuse the same cached content using supported CDN or cache controls.
Do not ignore parameters globally. Search, currency, language and preview parameters may alter content and need separate handling.
Compare CDN and origin carefully
If a CDN fronts the site, a public miss may still reach a fast server cache—or an uncached PHP request. Use provider diagnostics or an authorised hosts-file/origin test to compare layers.
Do not expose a private origin IP or bypass security controls without permission. Where direct origin testing is unavailable, server logs and timing headers can show whether the request reaches PHP.
An edge cache near one test location does not prove equivalent behaviour in every region. Check a relevant visitor region where possible.
Measure the uncached path
Even excellent page cache needs a healthy miss path for purges, new pages and personalised requests. Profile WordPress in staging or with low-overhead production monitoring.
Break the time into:
- web server and PHP queueing;
- WordPress bootstrap;
- database queries;
- external API calls;
- template rendering;
- cache storage.
Do not install several profiling plugins on a busy production site. Use one controlled tool and remove or disable it after collecting evidence.
Verify cache warming and invalidation
Publish a harmless staging change and confirm the relevant URL invalidates, regenerates and then hits cache. A cache that never expires serves stale content; a cache purged by every cron event never remains warm.
Review whether a plugin clears the entire cache whenever one product stock value changes. Targeted invalidation can protect both freshness and hit rate.
When to request performance repair
Request an assessment when headers disagree, every anonymous request bypasses cache or the miss path is unusually slow. Share the public URL, request times and response headers with sensitive values removed.
The repair should identify which layer answers each request, preserve exclusions for personalised content and improve the uncached origin rather than reporting only that a cache switch is on.