Answers: <p>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 <code>index.html</code> file is. </p>
  
  <p>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.</p>
  
Answers: CC BY-SA 4.0
Answers: 2019-02-19T18:29:23.663Z
Answers: 2019-02-19T18:29:23.663Z
Answers: Dan Cornilescu
Body: <p>I have a web frontend app uses <a href="https://webpack.js.org/guides/code-splitting/" rel="nofollow noreferrer">code splitting</a> to reduce the individual file size. And it's distributed on a CDN and works most of the time.</p>
  
  <p>A problem occurs when we update the project at any time. Assume that our project consists of following files:</p>
  
  <ul>
  <li><code>index.html</code></li>
  <li><code>main.1ef1a.js</code>(where <code>1ef1a</code>, as well as <code>bce31</code> in the next line, is content hash)</li>
  <li><code>on-demand.bce31.js</code></li>
  </ul>
  
  <p><code>index.html</code> imports <code>main.[content-hash].js</code> and <code>main.[content-hash].js</code> loads <code>on-demand.bce31.js</code> on demand.</p>
  
  <p>The error scenario is a user loads our page just before our update and he/she gets <code>index.html</code> and <code>main.1ef1a.js</code> and browser caches them. And then our update happens: we replace the files, flush the CDN, and following files are get distributed:</p>
  
  <ul>
  <li><code>index.html</code> now imports a new version of <code>main.js</code></li>
  <li><code>main.2a3db.js</code></li>
  <li><code>on-demand.5231f.js</code></li>
  </ul>
  
  <p>Then user does something that triggers the loading of <code>on-demand.js</code>, while since his/her <code>main.js</code> is old, he/she requests <code>on-demand.bce31.js</code>, which no longer exists, and then the page crashes. </p>
  
  <p>He/she is a very nice user with patience and tries a refresh, but the browser serves the cached <code>index.html</code> and <code>main.js</code> again and he/she cannot get ouside the loop.</p>
  
  <p>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.</p>
  
  <p>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 ?</p>
  
Comments: CC BY-SA 4.0
Comments: 2019-02-19T17:43:02.697Z
Comments: 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.
Comments: simbo1905
Tags: <cdn>
Title: Code splitting practice using CDN
UserDisplayName: Nandin Borjigin
ThreadText: # Code splitting practice using CDN
  
  (Asked by: username_0 on 2019-02-19)
  
  I have a web frontend app uses [code splitting](https://webpack.js.org/guides/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 ?
  
  **Tags:** cdn
  
  > **Comments:**
  > **username_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.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2019-02-19. Score: 4 | Accepted answer
  
  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.
  
  
  ---
  
  