A cache change can speed public pages yet show the wrong account data, stale basket state or an outdated form to a signed-in visitor. Test the experiences that should vary by person before widening the cache rule. The decision is which responses are safe to reuse, not whether a cache is good in general.
Decision framework
| Step | Practical check |
|---|---|
| Inventory dynamic paths | List account, checkout, cart, search, pricing and other personalized pages. |
| Compare sessions | Use two test accounts plus a signed-out window and note visible differences. |
| Inspect responses | Check cache headers and the configured page, object and CDN layers where accessible. |
| Retest after purge | Confirm both an uncached first view and a later repeat view. |
How to make the decision
Use a three-column matrix: guest, account A and account B. Add expected page content, action result and cache state for each. If a page varies by login or cart cookie, verify that the cache bypass or variation rule matches the real request. A correct homepage speed result does not justify caching a checkout response. Coordinate with the hosting provider when server and CDN layers both apply; record which layer was purged during the test.
Worked example
Synthetic store test: guest sees an empty cart, account A sees one item and account B sees two. After a cache setting changes, account B briefly sees account A’s count in the header, though checkout contents remain separate. The team rolls back the header cache rule, purges affected responses and repeats the three-session matrix before release.
What can change the answer
Never run this test with real customer accounts. A privacy leak or incorrect price should stop the release immediately; a performance score does not compensate for it.
Review checklist
- Do personalized screens differ correctly across test accounts?
- Can the team identify the cache layer responsible?
- Was the corrected rule tested after a purge and repeat visit?
Common question
Should all logged-in pages bypass every cache?
The answer depends on the stack and which fragments vary. Begin with safe exclusions and validate actual responses before optimizing further.
Next useful step
Report what a cache change meant for visitors and the business: Website Maintenance Reporting That Explains Business Impact. For help applying this to a UAE business, see Megvi’s website development service. Bring the source records and the decision you need to make.
Source checked 26 October 2026: WordPress Developer Handbook: performance optimization. Check the current platform interface and rules before acting.
Worked examples are illustrative unless a public source is explicitly named; they are not claimed Megvi client outcomes.