How to Check Whether Your Website Cache Is Working

Key takeaways

Compare a fresh visit with a normal repeat visit.
Check which cache layer served each request.
Verify that published edits reach the public page.
Keep delivery evidence alongside the DEX page review.

To test website caching, compare the same page on a fresh visit and a repeat visit. Check the page and its files, then confirm that a small published change reaches the public version. A fast reload alone does not prove that every cache works or that readers see fresh content.

Start with the wider website performance guide if you have not yet chosen the problem to test. This guide focuses on stored copies, reuse, and updates. It does not replace a full speed review.

How to test website caching with a clear expected result

When deciding how to test website caching, write down the expected result before you open a tool. A public guide may reuse a stored page for a short time. Its logo may stay the same for months. A signed-in account page needs different rules. Do not treat all three as one test.

Choose a public URL that you own. Note the date, browser, device, and login state. Pick one image, one script, and one font used by that page. Keep the same set for the repeat run. This turns a vague complaint into a test someone else can repeat.

Also define how soon a normal edit should appear. Use the release process agreed with your developer. Do not set a new cache lifetime just to make a score rise. The right result must balance reuse with the need to show current content.

Separate browser cache from shared cache

A copy may be stored in the browser or in a shared service between the reader and your server. A repeat visit can use one layer while another layer is bypassed. Record which layer you are checking rather than writing only “cache on.”

MDN explains that no-cache requires validation before reuse; it does not mean the response cannot be stored. A 304 response can be a valid check that the saved copy is still current. See the official source below for the full rules.

Read status labels using your provider’s own terms. A missing cache-hit header is not proof of failure. Ask the developer which signal identifies the shared cache, which pages are eligible, and which requests should bypass it.

Run a fresh visit and a repeat visit

Open the browser’s Network panel before loading the page. Keep a note of any option that disables caching. For the normal repeat test, leave that option off. A run with browser caching disabled answers a different question.

Load the chosen public page and save the request list.
Note the main document and the files you selected.
Visit the page again under the same conditions.
Compare transfer details, response headers, and the visible content.
Repeat the pair of runs to see whether the pattern holds.

Use the same route into the page. A normal visit, a forced reload, and the Back button can behave differently. Label each run. Do not combine them into a single average and call the difference a fix.

For a file that appears only after scrolling, follow the same scroll path on both visits. The guide to image lazy loading tests helps separate a deferred request from a failed cache check.

Read the evidence for each URL

Inspect the exact request URL. Two similar file names can be different releases. Record the response status, the displayed cache source, relevant response headers, and whether bytes were transferred. Save enough context for your developer to check the same item.

A header states a policy or describes one response. The repeated request shows what happened in that run. Read both together. If you expect a shared-cache hit but see a miss, note cookies, query strings, region, and any provider rule that might explain it.

Do not copy headers from another site as a universal fix. Share the record with the person who owns delivery settings. Ask them to explain any gap between the intended policy and the observed behavior.

Test whether an edit reaches readers

Use a small, safe change on a test page or staging copy first. Record the old text and the new text. Publish it through the usual process, then open the public URL as a reader. Check the visible sentence and the document response.

Next, test a changed file. Versioned file URLs let a release refer to a new asset instead of relying on the old stored copy. Confirm that the new page actually requests the new URL. Changing a file name in a build folder is not enough if the live page still points to the old one.

This matters for web font loading too: check the font file requested by the current styles. Keep text readable while you verify the release.

If old styles appear with new markup, check both versions before changing the layout. Then use the separate guide to fix shifts from images and embeds if the current page still moves. A stale file and an undersized media slot need different fixes.

Use a controlled example to locate a stale copy

Imagine a repair business changes a public booking notice from “Call on Friday” to “Call on Monday.” This is a hypothetical test, not a measured DEX result. The editor shows Monday, but one reader still sees Friday.

The reviewer records the public URL, the two sentences, and the test time. A fresh browser and a repeat visit are compared. The developer checks the stored document at each managed layer. The team changes only the layer linked to the stale response, then repeats the same test.

If a cache plugin is involved, follow a controlled WordPress plugin test. Avoid changing several plugins and delivery settings at once. You would lose the evidence of what solved the problem.

Keep cache success separate from page speed

A current cached file can still do too much work when the browser runs it. Use the guide to find costly JavaScript when clicks remain slow after the file arrives. Reuse and execution are separate questions.

Likewise, a slow document response needs a TTFB diagnosis. Save whether the request was a hit or a miss so that the server review starts with useful context.

DEX Health can review the published page’s SEO quality, including on the free plan. Keep that page review alongside the browser evidence. It does not prove which cache served a request. Close the task only when the expected version appears, the repeat visit works, and key page functions still pass.

FAQ

Does a fast reload prove the whole cache works?

No. Check the page and its files, the cache layer involved, and whether a published change reaches readers.

Does no-cache mean nothing is stored?

No. It requires validation before reuse. Read the intended policy and the response evidence together.

Can DEX Health prove a CDN cache hit?

No. Keep the page review alongside browser and delivery-service evidence.

Sources

HTTP caching · MDN Web Docs

Dex SEO

Dex SEO is an AI SEO agent for small businesses. Every article here is planned from search data, drafted by Dex, fact-checked against the sources it cites, and reviewed by the team before it is published.

How this article was made: planned and drafted by Dex from search data, fact-checked by Dex (5 claims checked), then approved by the Dex SEO team.