1

In our project, we follow frequent deployment process. With every deployment our client has to refresh the browser to reflect the changes because of browser cache. I want to know how can we avoid this situation.. i.e., when we deploy it should reflect directly in all users browsers with out the need of refresh. please help me to resolve this issue.

Spanizen
  • 15
  • 5
  • Too broad. This sounds wonderful, but actually it will increase the overhead excessively. Changing things suddenly to user is not also a good idea. Are you using it for development or production? Are you changing code or just a parameter/text? – Tatsuyuki Ishi Apr 14 '17 at 09:23
  • At present using for development only. Sometimes changing code also. – Spanizen Apr 14 '17 at 09:40

3 Answers3

0

There's a solution called Hot Module Replacement. This seamlessly replaces your webpack bundle (assuming you're already using it).

See What exactly is Hot Module Replacement in Webpack? for some references. HMR setup is quite complicated and differs for each framework.

webpack-dev-server also depends on webpack, but it's much simpler: it automatically push the refresh button for you.

Community
  • 1
  • 1
Tatsuyuki Ishi
  • 3,883
  • 3
  • 29
  • 41
0

Consider updating the cache directives in your response header to reduce or remove the cache duration allowed for browser caching.

To see what your website is currently using, view a page with Chrome with the "Inspect" option enabled and the "Network" tab selected. Then select a downloaded file to see the "Response Headers" information.

As an example, this SO page downloads a script file called ados.js that has a "max-age" value of 604800 (seconds, 7 days). That is the amount of time that the browser can wait before checking to see if a newer version of that file is available from the web server. If the file is almost never changed, then 7 days may be tolerable.

enter image description here

However, a max-age of 7 days may be too long of a duration for dynamic situations in which browser cached files are changed frequently.

Refer to this MDN page on HTTP caching for more information on this.

Changing the cache-control directives depends on your web server. For ASP.NET, it can be done in the web.config file.

One option to consider is a two phased approach for releases.

Phase 1: change the cache-control directives to no cache prior to the release for any cache-able file that is about to be updated by the pending release.

Then wait for the longest time duration that the updated files currently have their max-age value set to. This allows the current website browsers to pickup the "no cache" directives. Then, all of the current website browsers have been primed to pick up the updates immediately after the file updates have been released.

Phase 2: release the file updates to the website with the desired max-age cache-control directive. These updates should be picked up immediately due to what was done in Phase 1.

Another option is to shorten the current max-age value to a smaller value, like 5 minutes. This option is simpler, but there may be problems in that 5 minute period after the release. However, the shorter time span reduces the likelihood and/or impact of updates made to cached browser files.

JohnH
  • 1,920
  • 4
  • 25
  • 32
0

You can prevent cache by busting cache from the front end.

You can add a v={{number-of-version}} and you will always be shure that the loaded version is the one you want.

There is a gulp plugin which takes care of version your files during the build phase, so you don't have to do it manually. It's handy and you can easily integrate it in your build process. Here's the link gulp-annotate

Phugo
  • 400
  • 1
  • 10