How long browser cache

Caching is a process in which data is kept in a cache. A cache is simply a storage area that stores data for a short time. Browser caching is a process that involves the temporary storage of resources in web browsers. When the user visits the website subsequently, the web page will load faster and the bandwidth usage will be reduced. Image Source: Pressidium.

The web server collects information from the website and passes it to the web browser. Caching is done depending on whether the user is a first-time visitor or has used the site before. Image Source: Square Space. When you visit a website for the first time, the web browser will collect data from the web server.

This is because the web resources have not yet been stored in a cache. The web browser will then store the web resources in a cache to improve your experience in the subsequent visit to the website.

If a user visits a website for the second time using the same computer device, the web page will load faster than the first visit. This is because the web browser will retrieve the static web resources like images, CSS, and JavaScript from the cache. The web browser will be used to provide the HTML page. The image above assumes that the content is fresh. Fresh content means that it has not expired and it can be retrieved from the cache.

Stale content means that its cache period has expired and it can only be retrieved from the web server. The owner of a website has control over the cache policy. This control is exercised using HTTP cache headers. These headers are used to define the maximum time that web resources can be cached before expiring.

It works as a cache validation token. It is used when the cached files have expired. The web browser uses ETag in its requests to establish whether there is a stale copy existing in the cache. This header consists of various parameters that control validation, cache behavior, and expiration. This header defines when the resources stored in the cache will expire. When the expiry date reaches, the browser will consider the content stale. This header provides information regarding when the web content was modified.

While in the same browser session, all content for a site will be served from the local browser cache. If a user clicks through multiple pages of an application and the same graphics and elements are found on each page, the request will not be sent to the origin web server.

Instead it will be served from the local cache. If the user re-visits a page during that session, all of the content—including the HTML—will be retrieved from the local cache, as shown in the image below depending on the browser settings. As soon as the browser is closed, the session cache is cleared. For the next session, the only cache that will be used is the disk cache.

Users might also hit refresh on a page to check for new content, such as an updated sports score or news article. Hitting refresh results in an "If-None-Match" header being sent to the origin web server for all content that is currently on the disk cache, independent of the expiration date of the cached content.

This results in a response code for each reusable item that is currently in the browser's cache, as illustrated in the picture below. All objects will contain a response code of , indicating that all were served directly from the servers as in the illustration below. If a new browser session is started and a user returns to a frequently visited site, the local browser cache will be used based on the browser settings.

If a valid expiration date exists for cached content, it will be delivered directly from the cache and no request will be issued to the origin web server. If content does not have a valid expiration date, the browser will insert an "If-modified-since" or "If-none-match" header into the request. If the content has not changed, then a will be returned from the server and the content will be retrieved from cache. On the other hand, if the content has changed, the server will respond with a and deliver the content to the user.

By using these settings, the user will get the most benefits from the Intelligent Browser Referencing features of WebAccelerator. If static content contains random query parameters to prevent caching an iRule can be used to remove these random parameters and enable caching. The use of META tags will potentially negate the end user benefits of acceleration. META tags can be eliminated through the use of iRules or custom rewrite scripts.

To see the differences of the application with and without acceleration, a new browser session must be initiated; the other three ways of loading a page on repeat visits will show no differences with or without acceleration. Eliminating the need for the browser to download content on repeat visits can greatly improve the performance of web applications. There are many factors that impact whether or not content can or will be retrieved from the local browser cache on repeat visits, including the browser settings, the web site, and the user's behavior.

Skip to main content Skip to footer Skip to search. Use this header to define your caching policies with the variety of directives it provides. The cache should not store anything about the client request or server response. A request is sent to the server and a full response is downloaded each and every time. A cache will send the request to the origin server for validation before releasing a cached copy.

The "public" directive indicates that the response may be cached by any cache. This can be useful if pages with HTTP authentication or response status codes that aren't normally cacheable should now be cached. On the other hand, "private" indicates that the response is intended for a single user only and must not be stored by a shared cache. A private browser cache may store the response in this case. See the "Freshness" section in this document to see what "fresh" means here.

This directive is relative to the time of the request, and overrides the Expires header if set. For the files in the application that will not change, you can normally use aggressive caching. When using the " must-revalidate " directive, the cache must verify the status of stale resources before using them. Expired resources should not be used. For more details, see the Validation section below.

See the "Freshness" section below to see what we mean by "stale resources". Pragma: no-cache is like Cache-Control: no-cache in that it forces caches to submit requests to the origin server for validation before releasing a cached copy.

Once a resource is stored in a cache, it could theoretically be served by the cache forever. Caches have finite storage space so items are periodically removed from storage. This process is called cache eviction. Also, some resources may change on the server so the cache should be updated when this happens. As HTTP is a client-server protocol, servers can't contact caches and clients when a resource changes; they have to communicate an expiration time for the resource.

Before this expiration time, the resource is fresh ; after the expiration time, the resource is stale. Eviction algorithms often privilege fresh resources over stale resources. Note that a stale resource is not evicted or ignored; when the cache receives a request for a stale resource, it forwards this request with a If-None-Match to check if it is in fact still fresh.

If so, the server returns a Not Modified header without sending the body of the requested resource, saving some bandwidth. The freshness lifetime is calculated based on several headers. If this header is not present, which is very often the case, the cache checks whether an Expires header is present.

If an Expires header exists, its value minus the value of the Date header determines the freshness lifetime. If an origin server does not explicitly specify freshness for example, using Cache-Control or Expires header then a heuristic approach may be used. If this is the case, look for a Last-Modified header. If the header is present, then the cache's freshness lifetime is equal to the value of the Date header minus the value of the Last-modified header divided by The expiration time is computed as follows:.

Calculating Heuristic Freshness. The more we use cached resources, the better the responsiveness and the performance of a website will be. To optimize the use of cached resources, good practices recommend to set expiration times as far in the future as possible.

This is possible for resources that are updated regularly or often, but it is problematic for resources that are updated rarely or infrequently.