Force Cache Refresh After Deployment

Force cache refresh after deployment

Well, if the page is already cached by a browser it's difficult to tell it not to use its cached version because it probably won't bother to check again before it determines its cached version is stale. You'll just have to send a snail-mail letter to all of your users informing them to press ctrl+f5 :)

There is a chance that the browser might at least try a HEAD request to check the modified timestamp before it serves up its cached version, though. In this case the following will help you out.

Browsers negotiate their content from your web server using HTTP standard headers. Going forward if you want to tell a browser not to cache a file, you have to send the appropriate HTTP headers. If you want to do this in PHP you can use the header function to send the appropriate HTTP headers to the browser:

header('Cache-Control: no-cache');
header('Pragma: no-cache');

If it has to be done via HTML you can do the following in your page header:

<meta http-equiv="Expires" content="Tue, 01 Jan 1995 12:12:12 GMT">
<meta http-equiv="Pragma" content="no-cache">

There is no way for you to be sure if the browser will honor your request that it not cache a page, however. There are some other things like eTags and whatnot but frankly I don't think that's going to help you out if the page is already cached.

---

UPDATE

From the HTTP/1.1 specification on Response Cacheability:

If there is neither a cache validator nor an explicit expiration time
associated with a response, we do not expect it to be cached, but
certain caches MAY violate this expectation (for example, when little
or no network connectivity is available).

Website needs force refresh after deploy

You can append a variable to the end of each of your resources that changes with each deploy. For example you can name your stylesheets:

styles.css?id=1

with the id changing each time.

This will force the browser to download the new version as it cannot find it in its cache.

Force browser to reload all cache after site update

The correct way to handle this is with changing the URL convention for your resources. For example, we have it as:

/resources/js/fileName.js

To get the browser to still cache the file, but do it the proper way with versioning, is by adding something to the URL. Adding a value to the querystring doesn't allow caching, so the place to put it is after /resources/.

A reference for querystring caching: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.9

So for example, your URLs would look like:

/resources/1234/js/fileName.js

So what you could do is use the project's version number (or some value in a properties/config file that you manually change when you want cached files to be reloaded) since this number should change only when the project is modified. So your URL could look like:

/resources/cacheholder${project.version}/js/fileName.js

That should be easy enough.

The problem now is with mapping the URL, since that value in the middle is dynamic. The way we overcame that is with a URL rewriting module that allowed us to filter URLs before they got to our application. The rewrite watched for URLs that looked like:

/resources/cacheholder______/whatever

And removed the cacheholder_______/ part. After the rewrite, it looked like a normal request, and the server would respond with the correct file, without any other specific mapping/logic...the point is that the browser thought it was a new file (even though it really wasn't), so it requested it, and the server figures it out and serves the correct file (even though it's a "weird" URL).

Of course, another option is to add this dynamic string to the filename itself, and then use the rewrite tool to remove it. Either way, the same thing is done - targeting a string of text during rewrite, and removing it. This allows you to fool the browser, but not the server :)

---

UPDATE:

An alternative that I really like is to set the filename based on the contents, and cache that. For example, that could be done with a hash. Of course, this type of thing isn't something you'd manually do and save to your project (hopefully); it's something your application/framework should handle. For example, in Grails, there's a plugin that "hashes and caches" resources, so that the following occurs:

• Every resource is checked
• A new file (or mapping to this file) is created, with a name that is the hash of its contents
• When adding <script>/<link> tags to your page, the hashed name is used
• When the hash-named file is requested, it serves the original resource
• The hash-named file is cached "forever"

What's cool about this setup is that you don't have to worry about caching correctly - just set the files to cache forever, and the hashing should take care of files/mappings being available based on content. It also provides the ability for rollbacks/undos to already be cached and loaded quickly.

How can I force SPA clients to hard refresh if there is a new build?

As this question has been tagged with progressive-web-apps I'm going to assume that it's installing a service-worker, which is what is aggressively caching the resources.

This post runs though showing a "new version available" popup for PWAs - even if it's not the particular behaviour you want, it explains a lot about how service-workers get updated.

This question/answer also goes over how often the service-worker is checked for updates.

This question/answer goes over pros/cons of always using skipWaiting to keep the client immediately up to date.

Edit: If you're just dealing with regular HTTP Cache, try using location.reload(true) (reload with the forcedReload flag set) when you detect that there's a newer version on the server. In the past I've done this by putting the release number into the js code at build/release time, and having the server add its release number to every response as a header. A simple compare of the values after an ajax call can confirm whether the ui and server release numbers match and take action when they don't.

---

Related Topics