HTTP caching for https://cachecheck.net/examples/stale-while-revalidate

Overview

✅

This resource can be cached.

This response can be cached because of a directive in the Cache-Control header.

✅

This resource has a cache control header.

Cache-Control: no-transform, max-age=3600, s-maxage=7200, stale-while-revalidate=36000
❌

This resource does not have an entity tag.

HTTP response cache headers

These are the raw caching-related HTTP headers that were returned by the server:
cache-control: no-transform, max-age=3600, s-maxage=7200, stale-while-revalidate=36000
vary: Accept-Encoding
🧭

Cache-Control

Cache-Control: no-transform, max-age=3600, s-maxage=7200, stale-while-revalidate=36000
  • ⏳
    Max Age
    (RFC)

    The max-age directive indicates the response should be considered stale after 3600 seconds (1 hour).

    For example, since this response was fetched on Sep 16, 2025, 10:36:50 AM, it will become stale on Sep 16, 2025, 11:36:50 AM.

  • ⌛
    Shared Max Age
    (RFC)

    The s-maxage directive indicates the response should be considered stale by shared caches (such as a CDN) after 7200 seconds (2 hours).

    For example, since this response was fetched on Sep 16, 2025, 10:36:50 AM, it will become stale for shared caches on Sep 16, 2025, 12:36:50 PM.

  • ✨
    No Transform
    (RFC)
    The no-transform directive indicates that any intermediate cache must not transform this response (for example: change content type, compress data, filter responses, etc.)
  • 🔁
    Stale While Revalidate
    (RFC)
    The stale-while-revalidate directive indicates that after a response becomes stale, the cache may continue to serve it for up to 36000 seconds (10 hours) while it is revalidated in the background.
🔀

Vary

The Vary header indicates which request headers the server response may be dependent on. If any of the listed headers change, then the response may be different. This allows the server to send the correct cached response for each request. For example, ensuring that a client that does not support compression does not receive a cached compressed response.

Vary: Accept-Encoding

Accept-Encoding: The server response is expected to be different depending on the encodings that the client accepts via the Accept-Encoding header in the request. For example, if the client does not support compression, then the server may send a cached uncompressed response. If the client does support compression, for example, by sending a a Accept-Encoding: gzip header, then the server may send a cached compressed response.