Website Caching Is Not Just About Turning on the Plugin: How to Configure Cache Without Serving Expired Content

If a website feels slow even when the server is not overloaded, the issue may not be with image sizes or the number of plugins. Often, browsers and CDNs still need to request files that have not actually changed: CSS, JavaScript, logos, fonts, even the same HTML pages.

This is where caching helps. Cache stores a copy of the response so that subsequent requests do not always start from the origin server. As a result, network wait times decrease, and the server does not have to perform the same tasks repeatedly. However, cache is not a simple "turn it on and forget it" solution. It requires rules that differentiate static files, public pages, and private data.

Cache Works with Rules, Not Guesses

Browsers and intermediary caches like CDNs read instructions from the HTTP headers, especially Cache-Control. This header determines whether a response can be stored, how long the copy is considered fresh, and whether the response needs to be revalidated with the server.

If this header is not set, the browser can still use heuristic caching behavior. This means the browser tries to guess how long a response is valid. For serious websites, it’s better to define these rules explicitly rather than leaving the decision to client guesses. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching?utm_source=openai))

In addition to Cache-Control, there are ETag and Last-Modified. Both help the server respond, "This file has not changed," without resending the entire file content. If there are no changes, the server can return a 304 Not Modified status with a very small response size. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching?utm_source=openai))

Differentiate Three Types of Content Before Determining Duration

1. Versioned Static Files

CSS, JavaScript, fonts, and images are usually suitable for long caching if their URLs change every time the file content changes. For example:

app.8f31c2.css
app.1ab94e.js

Since the file names already contain versions or fingerprints, the browser can store these files for a long time. When changes occur, the website calls the new URL, prompting the browser to fetch a new copy. This pattern is often referred to as cache busting.

Here’s a common header for versioned assets:

Cache-Control: public, max-age=31536000, immutable

The number corresponds to one year. Do not apply such a long duration to files whose URLs remain the same but whose contents change frequently. If done, visitors may see old CSS or JavaScript until the cache expires or is manually cleared. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching?utm_source=openai))

2. Public HTML

Article pages or landing pages that are the same for all visitors can be cached, but the duration needs to be adjusted according to the frequency of content updates. News websites may require a TTL of a few minutes, while documentation that rarely changes can be longer.

For HTML pages whose URLs cannot be changed like static assets, a revalidation strategy is usually safer. With Cache-Control: no-cache, the browser can still store the response but must check with the server before reusing it. If it hasn’t changed, the server simply sends 304.

Cache-Control: no-cache
ETag: "homepage-v42"
Last-Modified: Wed, 26 Aug 2026 08:00:00 GMT

It’s important to note that no-cache does not mean "do not store at all." If it truly should not be stored, use no-store. This distinction is crucial because many caching configurations fail simply because these two terms are considered the same.

3. Private Pages and Login Data

User dashboards, shopping carts, account pages, and responses influenced by cookies should not be treated like public pages. Storing these responses in shared cache can risk displaying user A's data to user B.

For private responses, use rules like:

Cache-Control: private, no-cache

Or, for data that absolutely must not be stored:

Cache-Control: private, no-store

If responses change based on cookies, the cache settings also need to account for those variations. Errors in this area are not just performance issues but also privacy and security concerns. ([web.dev](https://web.dev/articles/http-cache-security?hl=en&utm_source=openai))

Stale-while-revalidate: Fast Now, Updated in the Background

For content that can afford to be slightly stale—such as lists of recent articles, catalogs, or weather data—stale-while-revalidate can be an option.

Cache-Control: public, max-age=60, stale-while-revalidate=300

With this rule, the response is considered fresh for 60 seconds. After that, the cache can still serve the old copy for up to 300 seconds while requesting the latest version from the server in the background. Visitors do not have to wait for the update process on the first request.

This strategy is useful if a slight delay in information is acceptable. Do not use it for account balances, payment statuses, very limited stock, or other information that must always be precise. ([web.dev](https://web.dev/articles/stale-while-revalidate?hl=en&utm_source=openai))

Incorrect Cache Often Looks Like Application Bugs

After enabling caching, several common issues may arise:

• CSS changes are not visible because the browser is still using the old file.
• Users see an outdated checkout page.
• New articles do not appear because the CDN cache has not been cleared.
• Logged-in visitors receive an anonymous version of the page, or vice versa.
• The browser cache has been updated, but the reverse proxy cache still holds the old response.

Therefore, testing should be conducted under various conditions: incognito windows, different devices, anonymous users, and logged-in users. Also, check response headers through browser DevTools or commands like curl -I https://example.com/. Look for Cache-Control, ETag, cache age, and headers from the CDN if used.

What You Can Do Now

1. Create an inventory of important URLs. Separate static assets, public HTML, API endpoints, login pages, and checkout.
2. Use versioned URLs for assets. Do not cache for a year on files whose names always remain the same if their contents change frequently.
3. Start with conservative TTL. Short durations are easier to extend than fixing content that has already been stuck in multiple caches.
4. Define a purge procedure. Ensure the team knows how to clear browser cache, plugins, reverse proxies, and CDNs.
5. Measure the results. Compare response times, the number of requests to the origin, and real user experiences. PageSpeed Insights distinguishes lab data from field data, while Core Web Vitals uses metrics like LCP, INP, and CLS to describe user experience. ([developers.google.com](https://developers.google.com/speed/docs/insights/v5/about?authuser=2&hl=en&utm_source=openai))

What It Means for Us

A good caching strategy is not one that keeps everything stored for as long as possible. A good strategy knows what is safe to store, how long it can be used, and when it should be revalidated.

Start with versioned static assets, then tidy up the rules for public HTML. After that, audit private pages and endpoints that use cookies. With this order, caching can reduce server load and speed up the website without sacrificing content accuracy or user privacy.

Sources & Further Reading

• HTTP caching - MDN Web Docs
• HTTP conditional requests - MDN Web Docs
• Cache-Control header - MDN Web Docs
• Prevent unnecessary network requests with the HTTP Cache - web.dev
• Keeping things fresh with stale-while-revalidate - web.dev
• About PageSpeed Insights - Google for Developers
• Understanding Core Web Vitals and Google search results - Google Search Central

– Rio Yotto @rioyotto