Avoid a messed up rendering of your web applications due to cache when you release a new update

The modern web applications both public facing and SAAS variety extensively cache HTTP elements like Javascript, CSS, images as well cacheable parts of the webpage both by using a web accelerator like Varnish/Squid or Nginx as well as by the browser to improve the user experience of an end user.

A browser based in-memory cache intercepts incoming HTTP responses from the web application servers, saving copies of the HTTP elements on local storage. If there is repeat request for the same HTTP element, it can use the response received earlier.

Extensive usage of web caching has several User Interaction advantages:
a. Reduced latency — Because the request is satisfied from the cache instead of the origin server, it takes less time for it to fetch the content to the browser.
b. Reduced page rendering time — When browser cache is re-used from the local machine of the client it reduces the page rendering time.
c. Reduced load on origin servers — since a lot of requests get served from cache, the origin servers are hit with lesser number of requests, thus letting them serve far more number of page views than without using caching.



webcacheblog
According to rule 3 of Yslow, the components of a web page can be made cacheable by adding an expire i.e. implementing “Never expire” policy by setting far future Expires header.

However, as the content and apps are served locally, browser cache or reverse proxy cache can serve web resources that are out of date. Page rendering can go out of whack if cached versions of CSS and JS are used and latest versions didn’t get fetched by the browser or the reverse proxy returned a stale version of these type of files.

The browser therefore must be forced to download the latest copies if changes are made to web content. It can be achieved by following simple guidelines as below :
1. All JavaScript or CSS files should be versioned, so that browsers interpret them as new files. This can be done by adding a query string at the end of the file name. e.g. myscript.js should be written as myscript101.js, and in the subsequent updates myscript102.js and so on and the corresponding reference changed in the refreshed HTML content of the page itself.
2. Session cookies should be renamed via auto-versioning in the release process of your web application. Default cookie names should ideally not be used, reverse proxy caching old cookies can result in incorrect working of browser sessions.
3. CDN/Reverse Proxy should not be setup to cache dynamic Ajaxified requests in general.
4. Wherever URL change is not possible for significantly dynamic content ( such as newsfeeds etc. ) via versioning due to SEO related considerations, Expires time value of less than 15 minutes should be avoided, even for high traffic websites as it wouldn’t result in significant reduction in hit-ratio of web caching on reverse proxy end.