Why no cache

Always use the Expires header to specify the most reasonable time when a particular file on the server needs to be updated by the client. When pages are updated regularly, the next period for update is the most efficient response. Take, for example, a daily news page on the Internet that is updated every day at 5 A. The Web server for this news page should return an Expires header with a value for 5 A. When it's done, the browser doesn't need to contact the Web server again until the page has changed.

Pages that aren't expected to change should be marked with an expiration date of approximately one year. In many cases, Web servers have one or more volatile pages on a server that contain information that's subject to change immediately. These pages should be marked by the server with a value of "-1" for the Expires header. On future requests by the user, Internet Explorer usually contacts the Web server for updates to that page via a conditional If-Modified-Since request.

However, the page remains in the disk cache Temporary Internet Files. And the page is used in appropriate situations without contacting the remote Web server, such as:. Certain pages, however, are so volatile or sensitive that they require no disk caching.

This header prevents all caching of a particular Web resource when the no-cache value is specified by an HTTP 1. Pages that are kept out of the cache aren't accessible until the browser can recontact the Web server. So, servers should use the Cache-Control header sparingly. Note that no-cache does not mean "don't cache".

If the sense of "don't cache" that you want is actually "don't store", then no-store is the directive to use. The must-revalidate response directive indicates that the response can be stored in caches and can be reused while fresh.

Once it becomes stale, it must be validated with the origin server before reuse. HTTP allows caches to reuse stale responses when they are disconnected from the origin server. The proxy-revalidate response directive is the equivalent of must-revalidate , but specifically for shared caches only.

The no-store response directive indicates that any caches of any kind private or shared should not store this response. The private response directive indicates that the response can be stored only in a private cache e. You should add the private directive for user-personalized content — in particular, responses received after login, and sessions managed via cookies. If you forget to add private to a response with personalized content, then that response can be stored in a shared cache and end up being used by multiple users, which can cause personal information to leak.

Responses for requests with Authorization header fields must not be stored in a shared cache. But the public directive will cause such responses to be stored in a shared cache.

In general, when pages are under Basic Auth or Digest Auth, the browser sends requests with the Authorization header. That means the response is access-controlled for restricted users who have accounts , and it's fundamentally not shared-cacheable, even if it has max-age. The must-understand response directive indicates that a cache should store the response only if it understands the requirements for caching based on status code. If a cache doesn't support must-understand , it will be ignored.

If no-store is also present, the response isn't stored. If a cache supports must-understand , it stores the response with an understanding of cache requirements based on its status code. Some intermediaries transform content for various reasons. For example, some convert images to reduce transfer size. In some cases, this is undesirable for the content provider. It converts images to minimize data for a cache store or slow connection, and supports no-transform as an opt-out option.

The immutable response directive indicates that the response will not be updated while it's fresh. When a user reloads the browser, the browser will send conditional requests for validating to the origin server. But it's not necessary to revalidate those kinds of static resources even when a user reloads the browser, because they're never modified. When you use a cache-busting pattern for resources and apply them to a long max-age , you can also add immutable to avoid revalidation.

The stale-while-revalidate response directive indicates that the cache could reuse a stale response while it revalidates it to a cache. In the example above, the response is fresh for 7 days s. After 7 days, it becomes stale but the cache is allowed to reuse it for any requests that are made in the following day s — provided that they revalidate the response in the background. Revalidation will make the cache be fresh again, so it appears to clients that it was always fresh during that period — effectively hiding the latency penalty of revalidation from them.

If no request happened during that period, the cache became stale and the next request will revalidate normally. The stale-if-error response directive indicates that the cache can reuse a stale response when an origin server responds with an error , , , or After 7 days it becomes stale, but it can be used for an extra 1 day s if the server responds with an error. After a period of time, the stored response became stale normally.

That means the client will receive an error response as-is if the origin server sends it. The no-cache request directive asks caches to validate the response with the origin server before reuse.

Browsers usually add no-cache to requests when users are force reloading a page. The no-store request directive allows a client to request that caches refrain from storing the request and corresponding response — even if the origin server's response could be stored.

Clients can use this header when the origin server is down or too slow and can accept cached responses from caches even if they are a bit old. They are essentially directives consisting of key-value pairs separate by a colon.

The value of the header appears on the right of the colon. Cache-control directives are considered request directives if they are used by the client in an HTTP request and response directives if they are used by the server in an HTTP response.

The max-age directive states how long the browser can use the fetched HTTP response stored as a cached copy from the time the request was made. It is the maximum amount of time specified in the number of seconds. For static files such as images, CSS and Javascript files, it is possible to use aggressive caching.

This directive tells caches that a resource is not available for reuse for subsequent requests to the same URL without checking if the origin server for the resource has changed. In other words, it is an instruction to the browser that it must revalidate with the server every time before using a cached version of the URL. This is useful to ensure that authentication is respected among other benefits. The no-cache directive uses the ETag header field for validation of the cached response by making a roundtrip to and from the server to ensure that the response has not changed.

If there has been no change, no download is required. With this directive, the HTTP response cannot be cached and re-used. Instead, the resource has to be requested and a full response is downloaded from the original server each time. It overrides the max-age directive and the expires header field when present. When resources are stored in the cache server, intermediate proxies can sometimes make modifications to these assets.

For example, they could change the format of images and files in order to save space and improve performance. This can cause problems if the asset is to remain identical to the original entity-body. The no-transform directive tells the intermediate caches or proxies not to make any such modifications.

Caching can be thought of as moving resources closer to a local drive from a server for faster access and reduced latency. This same idea applies for Content Delivery Networks CDN which moves your website content to proxies for accelerated content distribution and bandwidth optimization. This helps bring content closer to the site visitors and makes sure that a single cached copy is served to multiple visitors.

It also allows for quick delivery of resources even to first-time visitors whose browsers may not have cached the site content yet. For example, a HTML file that has not changed much over time can be labelled static and classified as cacheable. It can be served directly from the CDN servers for faster page load and responsiveness. The algorithm can continue to track the status of the page and classify it as dynamic as soon as there is a change.

This optimizes your storage and caching policies and improves content delivery speed. Skip to content.