A logo reused across ten pages does not always need ten full downloads. The browser can keep a stored response and reuse it according to the response’s caching rules. This reduces transfer and can make repeat visits faster.
The same mechanism can confuse testing. A stylesheet may have changed on the server while your browser still uses an older copy. The first step is to identify which version you actually received.
Observe a repeat visit
Open DevTools Network, reload the page, and find a shared resource such as the logo or main stylesheet. Keep cache enabled for the first comparison. Navigate to another page using the same file and inspect its request.
Chrome may indicate memory cache, disk cache, or a network response. A conditional network request can return 304, allowing the client to reuse a stored representation. These results differ from downloading a complete new response.
The HTTP headers matter. Cache-Control can define freshness and revalidation behaviour, while validators such as ETag can help determine whether a representation changed. Do not infer a site’s complete caching policy from one size column.
Run a controlled uncached comparison
With Network open, enable Disable cache and reload. This setting affects the browser cache while DevTools is open. Record it with your results, then restore the normal setting after the experiment.
Compare the same resource URL, response, and transferred bytes. A slower uncached visit is not automatically a regression; it has different starting conditions. Keep cold and repeat visits separate when evaluating a change.
A service worker can introduce another response path. If the results still seem inconsistent after disabling the normal browser cache, inspect whether the application has one and test its behaviour separately.
Locate the stale layer
There may be several caches between the stored file and the screen:
- The browser can retain a downloaded resource.
- The application or web server can serve cached page output.
- A CDN can keep a response at the edge.
Clearing the browser cache does not purge a CDN. Purging the CDN does not force every visitor’s browser to discard an already-fresh file. Response headers and a comparison with the intended origin output help narrow down the layer.
For a changed CSS file, inspect the response body and search for the revised rule. For an image, compare the exact requested filename with the new image’s URL. A different upload name can explain why the old image remains in use.
Test the fix without losing the normal visitor view
After correcting the file or cache rule, check the page with caching disabled to confirm the new content can be fetched. Then test an ordinary repeat visit with caching enabled. Both need to work.
Avoid diagnosing server speed from a visit that served most of the page locally. Conversely, forcing every resource to download on every visit can hide the benefits of a working cache. Network timing and CSS delivery need those conditions recorded.
The MDN HTTP caching guide explains freshness and validation. My page-speed and Core Web Vitals service includes caching checks, while technical SEO consulting can connect stale output with indexing or deployment problems.