Saturday, September 2, 2017

Cache busting in a Google Chrome Web Application

Leave a Comment

We are currently using Webpack with the HtmlWebpackPlugin to generate our javascript builds for our webpage.

new HtmlPlugin({     template: 'www/index-template.html',                //source path - relative to project root     filename: 'index.html',                             //output path - relative to outpath above     hash: true,     cache: true                                         //only emit new bundle if changed }), 

This causes a hash to be added to the query string of the bundled javascript file.

<script type="text/javascript" src="/build/vendor.min.js?4aacccd01b71c61e598c"></script><script type="text/javascript" src="/build/client.min.js?4aacccd01b71c61e598c"></script> 

When using any standard desktop or mobile browser, new builds are cache busted properly and the new version of the site is loaded without any effort from the user. However, we also have a chrome web app implementation where we call:

chrome.exe --app=http://localhost:65000 --disable-extensions

In this application, for some reason the hash on the end of the javascript build doesn't bust the cache. We have to manually right click somewhere on the page, then click reload (or press F5). For some reason the cache isn't busted in the web application.

I was thinking that possibly it is caching the index.html file maybe? That may cause the app to never receive the updated hash on the build. I'm not sure how to solve that issue though if that is the case.

I have also noticed that if our localhost server is down, the page still loads as if the server were running. This indicates to me some kind of offline cache. I checked the manifest.json parameters and can't find anything to force a reload.

I have also tried these chrome command line switches which did not help either: --disk-cache-size=0, --aggressive-cache-discard, --disable-offline-auto-reload.

Another caveat is that we need to retain the localStorage data and their cookies. In a standard browser window, or any browser for that matter it works just fine, but not when it is inside a Chrome web app.

2 Answers

Answers 1

Are you talking "Progressive Web App" with service workers? If so then the html file can (and should) be cached on first download. You need to have some sort of aggressive update process on the client to ensure new files are loaded properly.

Perhaps having an api call that checks some sort of dirty flag on the server could work, and if it comes back true, it should reload the template files. Or something more complex where it gets an array of dirty files from the server so it knows which ones to reload instead of loading everything. Just some ideas.

Answers 2

As your page works without the server running at localhost, I suspect that your app is offline first. This is done exactly through service workers(as pointed out by @Chad H) which are officially supported by Chrome and are experimental in other browsers. So, expect different behavior in other browsers. To bust the cache,

In Production

For a permanent solution, you to find and modify the service worker (SW) code. Deletion of old caches happens only in activate event of SW.

You can also read more about Service worker and ask a question with the updated SW code. Also, check out this resolved issue that faced a problem similar to yours.

For dev setup

You can use the Disable Cache option under Network tab in Chrome DevTools (works only when DevTools is open) or use a more robust chrome extension called Cache Killer.

If You Enjoyed This, Take 5 Seconds To Share It

0 comments:

Post a Comment