Does activating a new security officer affect cache backup?

Question

I use sw-precache along with sw-toolbox to allow offline viewing of cached Angular application pages.

The application is sent through the node express server.

One of the problems we encountered is that sometimes index.html not updated in the cache, although other assets were updated when a new worker was activated.

This leaves users with an obsolete index.html , which attempts to load an already existing versioned asset in this case /scripts/a387fbeb.modules.js .

I'm not quite sure what is happening, because it seems that in different browsers where index.html been updated correctly, there is the same hash.

Obsolete (problematic) Index.html in one browser

(cached with hash 2cdd5371d1201f857054a716570c1564 ) includes:

 <script src="scripts/a387fbeb.modules.js"></script> 

in its content. (this file no longer exists in the cache or on the remote computer).

Updated (good) index.html in another browser

(cached with the same 2cdd5371d1201f857054a716570c1564 ) includes:

 <script src="scripts/cec2b711.modules.js"></script> 

These two have the same cache, although the content that is returned to the browser is different!

What should I do? Does this mean that sw-precache does not guarantee the redundancy of the atom cache when activating new software? How can you protect against this?

If that helps, this is the generated service-worker.js file from sw-precache .

Note I understand that I can use the remoteFirst strategy (at least for index.html ) to avoid this. But I would still like to understand and figure out a way to use the cacheFirst strategy to maximize performance.

Note 2 In other related issues, I saw that you can change the name of the cache to force the entire old cache. But did this seem to surpass the idea of sw-precache only sorting through updated content? Is that the way?

Note 3 Please note that even if I strongly restart the browser where the website is damaged. The site will work because it will skip the cache of service workers, but the cache will still be erroneous - the working service does not seem to be activated - I think because this particular SW is already activated, but the cache could not be correctly closed. Subsequent non-hard updates will still see a broken index.html .

Answer 1

(The answers here apply to the sw-precache library . Details do not apply to service workers in general, but the concept of serving a cache can still apply to a wider audience.)

If the contents of index.html dynamically generated by the server and depends on other resources that are either embedded or specified via <script> or <link> tags, then you need to specify these dependencies using the dynamicUrlToDependencies option. Here is an example from app-shell-demo , which comes as part of the library:

 dynamicUrlToDependencies: { '/shell': [ ...glob.sync(`${BUILD_DIR}/rev/js/**/*.js`), ...glob.sync(`${BUILD_DIR}/rev/styles/all*.css`), `${SRC_DIR}/views/index.handlebars` ] } 

( /shell used there instead of /index.html , as this is the URL used to access the cached shell of the application.)

This configuration tells sw-precache that at any time when any of the local files matching these patterns change, the cache entry for the dynamic page must be updated.

If your index.html not dynamically generated by the server, but instead is updated during the build using something like this approach , then it is important to make sure that the step in the build process that sw-precache occurs after all other changes and replacements. This means using something like a run-sequence to ensure that the work service generator does not start in parallel with other tasks.

If the above information does not help you, write a file with an error with more detailed information, including the URL of your site.