2

I have a web frontend app uses code splitting to reduce the individual file size. And it's distributed on a CDN and works most of the time.

A problem occurs when we update the project at any time. Assume that our project consists of following files:

  • index.html
  • main.1ef1a.js(where 1ef1a, as well as bce31 in the next line, is content hash)
  • on-demand.bce31.js

index.html imports main.[content-hash].js and main.[content-hash].js loads on-demand.bce31.js on demand.

The error scenario is a user loads our page just before our update and he/she gets index.html and main.1ef1a.js and browser caches them. And then our update happens: we replace the files, flush the CDN, and following files are get distributed:

  • index.html now imports a new version of main.js
  • main.2a3db.js
  • on-demand.5231f.js

Then user does something that triggers the loading of on-demand.js, while since his/her main.js is old, he/she requests on-demand.bce31.js, which no longer exists, and then the page crashes.

He/she is a very nice user with patience and tries a refresh, but the browser serves the cached index.html and main.js again and he/she cannot get ouside the loop.

We cannot assume our users to have certain knowledge to perform a "Clean cache and force reload", all we get are disappointed users who think our website sucks.

I think code splitting and CDN are both widely used techniques and there should be some nice solution that I'm missing. And what is that ?

1
  • I thought that the idea is to always have the filenames computed from the hash of the content. So the tool that made main.2a3db.js should have only created that name if the sha1 hash of its content is 2a3dbxxxxxxx` or some similar approach. So you shouldn't ever overwrite a file with different content to cause a crash. Instead you upload the new js that are unique files then lastly push out index.html that references the new js. Old files with no changes in them can be cached by the browser fine.
    – simbo1905
    Feb 19, 2019 at 17:43

1 Answer 1

4

Your main problem is that you're flushing the CDN when you're deploying a new set of artefacts, which will effectively ruin anything still in progress (whatever its state). You should add the new artefact versions and leave the older ones in place, at least for as long as your published cache lifespan for the top index.html file is.

This way even if users look at an older (cached) version of the page which references other older version artifacts they'll still be able to download them (users have no clue that a new version is available as the cached version is immediately served as long as it's not expired). And whenever the cache expires users will get the new version of the top page, with the references to the new artefact versions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.