How long is css cache

If you are not acquainted with the concept, you can read more about them in this detailed guide on CDNs. Resource loading without CDN Let's take a simple example. Resources are downloaded from the origin server Resource loading with CDN To avoid the high load time and reduce the stress on the servers, you use a Content Delivery Network. Resources are downloaded from the nearest CDN edge With the context set, in the rest of the guide, we will understand both the layers of caching - one on the user's device and the second on the intermediate layer provided by the Content Delivery Networks - and how to manage them best.

Best practices for cache control Here are a few things to help you get started while setting up your server, CDN, and the application for proper caching of content. Specifying how long the content can be cached There are two primary response headers responsible for specifying how long the content stays in the cache.

The Expires header It is used to define an absolute time after which the content should no longer be considered valid for caching. The Cache-Control max-age directive The Cache-Control header has a lot of other directives to control the cache behavior. Who can cache the content - public vs private directives The Cache-Control header has two other directives to specify who can cache the content.

Setting Optimal Cache Lifetime The cache lifetime depends on what kind of resource you are trying to cache. Note: Static assets can be safely cached for a longer duration, like six months or even one year. Some websites actually do that for faster access to the HTML. But the CDN should allow for such dynamic content caching. Different CDNs have a different way of caching the content at their level without polluting browser cache or other intermediaries.

Cached content Validation - ETag and Last-Modified Headers Let's say you have specified a cache lifetime of seconds, and now a page issues a new request for the same resource.

There are two ways to solve this - a. A validation token like ETag The server generates this token, and it is typically a hash or some other fingerprint of the content, which means if the content changes, then this token will change. If-None-Match: "jdsfjn39dsfnjkdss" b.

The Last-Modified time of the content This is similar to the ETag token, but instead of using a content hash, this header specifies the time when the content was last modified. If-Modified-Since: Mon, 03 Jun GMT If the token hasn't changed or if the content hasn't been modified since the last modified time, then a - Not modified response is generated.

Explaining Content Validation using ETag First download of the resource with ETag in the response Subsequent requests to validate the content Subsequent request with the If-None-Match request header You need to ensure that the server is providing the ETag tokens by making sure the necessary flags are set.

Use these sample server configuration to confirm if your server is configured correctly. Fingerprint should be calculated based on the content of the file and should only change when the content changes.

Factors that can reduce cache hit ratio Use of inconsistent URLs - If you serve the same content on different URLs, then that content is fetched and stored multiple times. Also, note that URLs are case sensitive. For example, the following two URL point to the same resource. And two different copies are maintained on the CDN cache. It could lead to a low cache hit ratio. If a user gets a tailored image dimension from your servers based on their screen width and DPR, then they might be the first user to request this specific image from your CDN layer.

A rule of thumb is to check popular viewport sizes and device types from your Google Analytics and optimize your application for them. Using shorter cache lifetime - Static assets can be cached for a longer duration as long as you have a mechanism to push updates like embedding fingerprints in the URL.

Setting a short cache duration increases the chances of a cache miss. You should never vary responses based on User-Agent. For every unique value of User-Agent, a separate object is cached. This reduces the cache hit ratio. Add a comment. Active Oldest Votes. Community Bot 1 1 1 silver badge. Michael Argentini Michael Argentini 56 6 6 bronze badges. Thanks a lot for the answer. But I really want to know what browsers do these days. For example, how long will chrome browser to update its cache?

Will it keep the old cached file forever? Sign up or log in Sign up using Google. Sign up using Facebook. Sign up using Email and Password. Post as a guest Name. 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.

The latter are the resources that would benefit the most from caching resources, yet they are very difficult to update. This is typical of the technical resources included and linked from each webpages: JavaScript and CSS files change infrequently, but when they change you want them to be updated quickly. Web developers invented a technique that Steve Souders called revving.

Infrequently updated files are named in a specific way: in their URL, usually in the filename, a revision or version number is added. That way each new revision of the resource is considered a resource on its own that never changes and that can have an expiration time very far in the future, usually one year or even more.

To get the new versions, all the links to the resources must be changed. That is the drawback of this method: additional complexity that is usually taken care of by the tool chain used by Web developers.

You are correct, the browser will still use the cache after expiry and revalidate before re-downloading however there are no guarantees or requirements in the standards for how browsers should manage their caching.

If the file is still in the cache, then the browser will attempt to revalidate it. I've corrected the part of my earlier answer that suggested expired cached files would be disregarded, apologies for confusion on that aspect. Specify must-revalidate to ensure that after seconds further requests will revalidate and buy you another seconds of validated cache copy.

If the only website users access is yours, the expired files would never leave the cache as most modern browsers seem to only delete old files from cache to make space for new files to be cached. Therefore the more frequent they access your site the more likely stale expired files will remain stored in the cache directory and be available for revalidation.

Show 1 more comment. Mike -- No longer here Mike -- No longer here I think "must-revalidate" means you should revalidate even within the cache expiry time. I'm happy to use cache within the shorter time 3 hours in my example without revalidating, but wanted to know if there was a way to keep it available to cache after expiry time so it could be used again if revalidated.

My concern is that a short expiry time will equate to a higher likelihood of cache purging. I test my website headers through redbot. I also ran a test on yahoo. More interesting reading here: stackoverflow. Although an answer has been accepted here, the advice given is IMHO not very good. There are multiple solutions to the problem. Thanks for taking the time, but this answer doesn't really answer the question at all in my opinion.

Additionally it IS possible to return caching headers with s at least in Apache and Nginx and the RFC says that "use other header fields provided in the Not Modified response to replace all instances of the corresponding header fields in the stored response. Could you please share how to send new caching information with a response in Apache? You don't need to do anything special. Once caching headers are set up they work for s in same way as s. For example go to www.

Pick an asset which will e. That didn't answer my question. Yes you basically reapply the same caching. Say you've said "cache it for 3 hours" on the original request, then you visit after 4 hours and luckily it's still in the browser cache so you get a which then says the cached version is still up to date and now is valid again for another 3 hours.

Not sure why you feel it's necessary to provide completely new caching information on a response?