Website Caching Is Not Just About Being “Active”: How to Determine What Can Be Stored

Many websites already use caching, but they may not be using it correctly. Some set a cache duration that is too short for all pages, causing the server to work hard. Others store HTML for too long, resulting in content changes not being immediately visible to visitors.

The issue is not with the cache itself, but with the decisions about what can be stored, how long, and who can reuse it. With the right rules, browsers, CDNs, and servers do not need to repeat the same work for every visit.

Cache works like a storage shelf near the door

Imagine a store that frequently sells the same items. Instead of retrieving products from the warehouse every time a customer comes in, the store places some popular items on a shelf near the door. Visitors can grab them directly, while the warehouse does not have to work continuously.

In a website, that “shelf” can be the browser cache, CDN, reverse proxy, or server-side cache. If a CSS file, JavaScript, image, or page can be reused, requests do not always need to reach the main server. As a result, response times and the load on the origin server can decrease.

However, that shelf must be clearly labeled. The HTTP header Cache-Control is used to inform browsers and shared caches like CDNs whether a response can be stored, how long it is considered fresh, and whether the response is private or public. MDN explains that directives like max-age, private, public, and no-store serve different functions.

Differentiate between static assets, HTML, and personal data

The most common mistake is applying a single caching rule for all types of responses. In fact, logo files and checkout pages have very different needs.

1. Versioned static assets

Files like CSS, JavaScript, fonts, and images are usually suitable for long cache durations—especially if their names change whenever their content changes. For example:

app.2026-10-22.js
style.a81f3c.css

If the content of the file changes, the file name also changes. Browsers can store the old version for a long time because the new version will be called with a different URL. This pattern is safer than forcing the browser to guess whether the old file is still valid.

For assets that truly have versions, rules like public, max-age=31536000, immutable often make sense. That number is equivalent to one year. But do not use it on files whose URLs remain the same while their content frequently changes.

2. Public HTML

Article pages, documentation, or landing pages can be cached, but their duration is usually shorter than that of static assets. For example, HTML can be stored for a few minutes and then validated back to the server.

Here, no-cache is often misunderstood. This directive does not mean “do not store.” It means the response can be stored, but it must be validated again before use. This is different from no-store, which instructs the cache not to store the response at all.

3. Pages and responses containing user data

Dashboards, shopping carts, profile pages, and responses that change based on cookies or login sessions must be treated more carefully. For responses that should only be used by the same user, use private. For highly sensitive data that should not be cached, consider no-store.

The risk is not just that users see outdated data. If personalized responses enter a public cache without the correct rules, there is a chance that those responses are served to other users. web.dev's cache security guide recommends that responses relying on cookies be given private rules or use appropriate cache keys via Vary.

Do not use no-store as a catch-all solution

Adding Cache-Control: no-store may feel safe because the browser does not store the response. However, on public pages, this rule can eliminate the benefits of caching and make repeated navigation heavier.

In addition to HTTP caching, modern browsers also have a back/forward cache or bfcache. This feature allows pages to be restored almost instantly when users press the back or forward button. web.dev documentation notes that using no-store on pages can disqualify them from bfcache under certain conditions.

Therefore, differentiate between the need for “must always be validated” and “must not be stored at all.” For public pages that need to be checked continuously, no-cache or max-age=0 may be more appropriate than no-store.

How to check if caching rules are actually working

1. Select a few representative URLs. Test one article page, one JavaScript asset, and one page that requires login. Do not just test the homepage.
2. Open the Network panel in DevTools. Check the response headers, especially Cache-Control, ETag, Last-Modified, and information on whether the response comes from the cache.
3. Test the second visit. The first request is not enough. Reload the page, reopen the tab, then use the back button. Cache behavior often only becomes apparent on subsequent visits.
4. Test after content changes. Publish small changes and ensure that new assets or the latest HTML actually appear. If you need to clear the CDN cache every time you publish an article, the invalidation strategy may not be tidy.
5. Test login and logout conditions. Ensure that pages containing names, carts, or account status do not appear after switching users or devices.

The relationship with Core Web Vitals

Caching is not the only performance factor, but healthy caching can reduce network wait times and server workload. The impact can enhance user experience, especially on repeat visits or for users far from the main server.

To assess the results, pay attention to the three Core Web Vitals: LCP for the speed of main content appearance, INP for responsiveness after interaction, and CLS for layout stability. The common “good” target at the 75th percentile is a maximum LCP of 2.5 seconds, maximum INP of 200 milliseconds, and maximum CLS of 0.1. However, lab numbers alone are not enough; also test from real user data and slower devices. Web.dev summarizes those definitions and thresholds.

What can be done now

• Create separate caching rules for static assets, public HTML, and user pages.
• Use versioned file names for CSS and JavaScript that you want to cache for a long time.
• Do not cache personal responses in public caches.
• Use no-store only when necessary, not as a substitute for clear caching design.
• Check headers via DevTools and conduct testing after every CDN or server configuration change.

Good caching is not about caching everything for as long as possible. Good caching knows when to serve an old copy, when to revalidate, and when to fetch new data. Once this division is clear, websites typically become faster without sacrificing information accuracy or user privacy.

Sources & further reading

• Cache-Control header - HTTP | MDN
• HTTP caching - MDN
• Improve security and privacy by updating HTTP Cache - web.dev
• Back/forward cache - web.dev
• How the Core Web Vitals metrics thresholds were defined - web.dev

– Rio Yotto @rioyotto