Website caching: improve speed without serving wrong data
Distinguish browser, CDN and application caching; choose safe content, avoid shared personal data and verify updates.
Updated: · AI-generated editorial illustration
Caching reuses an available result or resource to reduce repeated work. It can improve loading, but incorrect settings can show old prices, unpublished edits or information from another session. Speed is useful only when the response remains correct for the person receiving it.
This guide explains principles and diagnosis for business websites. Specific configuration depends on hosting, framework and data type. Do not copy a long-lived cache header onto every route without examining what that route returns.
1. Identify the cache layer involved
Browser cache retains resources on the device, a CDN can retain responses in distribution infrastructure, and application caching reuses data or results inside the system. Several layers can coexist. When old content appears, establish which layer serves it rather than immediately clearing everything.
MDN's HTTP caching guide distinguishes private and shared caches and their directives. Record URL, headers, authentication state, cookies and reload conditions. Opening a private window changes browser conditions but does not by itself prove that a CDN response has refreshed. Diagnosis needs evidence at the layer actually responsible.
2. Choose policies by content type
Versioned images or files can suit long-lived caching because new versions have different addresses. News HTML, prices, stock and session data have other requirements. Before choosing a lifetime, ask whether the data varies by person, language, authentication or time, and how much staleness is acceptable.
Do not solve a slow personalised page by putting its contents into a shared cache. For cookie-selected languages, inspect the cache key and variation policy; an English response should not replace Vietnamese content because infrastructure considered only the path. Static assets and personalised responses need different treatment even when they are delivered by the same application.
3. Distinguish no-cache, no-store and revalidation
No-cache does not simply mean never storing a response; it concerns validation before reuse according to the rules. No-store has a different meaning. Public, private, max-age and shared-cache directives also need context. MDN's Cache-Control reference documents syntax and behaviour.
Validation can use signals such as ETag or Last-Modified. Inspect actual responses rather than configuration files alone. Hosting or framework behaviour may add, alter or interpret headers at another layer. Compare platform documentation with the deployed version before concluding which policy the visitor receives. Similar wording does not imply interchangeable behaviour.
4. Plan how edits become visible
When an image changes, versioned names help avoid old bytes surviving at an unchanged address. For tag- or path-based content caching, identify which update action invalidates the result. Do not rely on an operator remembering to purge everything after every small edit.
An article update can affect its card, detail page, Open Graph image and sitemap. Check each surface because they may use different data paths. If stale-while-revalidate is used, document when an older response can legitimately appear under that policy. Not every stale response is a defect, but the accepted behaviour should be deliberate and understandable.
5. Measure cold and warm behaviour separately
Measure first and repeated visits while recording browser, network, viewport and cache conditions. A fast warm load does not represent a new visitor, while one slow cold load does not reveal the cache's overall contribution. Review server time, resource loading and LCP together. The Core Web Vitals guide places speed within the full experience.
If a widget or large image dominates loading, changing HTML caching may not address the cause. Prioritise trace and request evidence. Do not claim millisecond savings without comparable before-and-after measurements. A correct diagnosis should explain both the resource and the condition being improved.
6. Verify content correctness after optimisation
Test newly published and edited content, another language, authenticated and anonymous states where applicable, and relevant carts or forms. Compare independent sessions to ensure personal information is not shared. Inspect headers on the live domain because localhost often lacks the production CDN.
Report which routes are cached, which data is excluded, how invalidation works and what was verified. State limitations when hosting-layer access is unavailable. A useful optimisation has evidence of both improved performance and correct content. A high Lighthouse score without those checks does not establish a safe or complete caching policy.
Frequently asked questions
Should everything be cached for a year?
No. Versioned assets and data varying by person or price need different treatment. Choose lifetime according to data characteristics, acceptable staleness and update delivery.
References and further reading
To apply this to your current website, explore the page-speed optimisation service or contact Dean Vu to define a scope around your existing site and actual evidence.