What Is Website Caching, and How Do I Know It Is Working?
Understand browser, server and CDN caching, test whether cached copies are being used, and diagnose stale pages without exposing private content.
Part of our guide: The Complete Guide to Website Speed for Business Owners
Website caching keeps reusable copies of responses or assets so they do not always need to be fetched or generated again. It can make repeat visits faster and reduce repeated work, but a cache also needs rules about freshness and which content is safe to share.
If a change does not appear immediately, caching is one possible explanation. It is not proof that the edit failed, and it is not a reason to delete every cache without checking where the old copy is coming from.
Understand the three common layers
A useful business-level map is:
| Layer | Where the copy sits | First troubleshooting question |
|---|---|---|
| Browser | On the visitor’s device | Does a fresh browser session show the change? |
| Server or application | Near the website’s page-generation system | Is the origin still producing an older page? |
| CDN | In a shared delivery network | Has the distributed copy been refreshed? |
A website may use some or all of these. Its content system may also have an editing preview that differs from the public page.
Our CDN guide explains the distributed layer. The layers should be documented so somebody can identify which one to inspect.
Set rules for when cached content expires
HTTP response headers can tell caches how a response may be stored and reused. MDN’s HTTP caching guide explains that no-cache means the stored response must be revalidated before reuse; it does not mean “never store”. No-store has a different purpose.
Personalised or sensitive responses require particular care. A shared cache must not give one customer’s information to another visitor. Ask the developer how private pages, account areas and submissions are excluded or handled safely.
Do not apply a universal “cache everything” rule to a website you have not assessed.
Check whether the browser is reusing files
A developer can inspect requests in the browser’s network panel. Chrome’s Network reference explains the available request information and controls, including disabling cache for diagnostic testing.
Compare an initial load with a repeat load under recorded conditions. Some resources may come from memory or disk, while others are checked with the server or downloaded again.
An incognito window can help distinguish an existing browser session from a fresh one, but it does not bypass a CDN or server cache. A hard refresh is not a guaranteed purge of every layer either.
Use a small controlled content test
On a safe test page, make a harmless, recognisable edit and record when it was saved and published. Then check the public response, not only the editor preview.
If the old content remains, work through the layers with the person responsible:
- Confirm the intended edit and publication step completed.
- Check the correct domain, path and environment.
- Compare a fresh browser session.
- Inspect the origin or application response where access permits.
- Review the relevant CDN refresh or expiry behaviour.
- Re-test the public page after the targeted change.
Keep a note of what resolved the issue. Repeatedly clearing everything hides the evidence and may temporarily remove performance benefits.
Plan for updates before they become urgent
Ask how a changed price, service description or important notice reaches visitors. Agree which edits trigger automatic refreshes and which need a manual action.
Versioned asset filenames can help new releases point to new files without confusing them with older cached copies. The implementation belongs with the site’s developer or platform configuration.
Document the process in the hosting and account handover. The business should not need to discover an unknown delivery account during an urgent correction.
Measure speed and correctness together
The business-owner’s website speed guide puts caching alongside images, scripts and other performance work.
Check repeat visits, fresh visits and changed content. A useful result is both fast and current.
Caching may improve time to first byte for eligible responses, but it cannot remove all browser-side work. If the page still feels slow, use the slow-website diagnosis guide.
For WordPress, investigate the theme, plugins, host and delivery service together; our WordPress performance guide explains why adding another plugin is not automatically the answer.
Make caching understandable
Ask for a one-page record of the active layers, owner, refresh method and private-content safeguards. Include the test that confirms each important update is visible.
Document how the caches work so the person maintaining the website can identify and refresh the right one when a customer sees an old page.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
