Long term caching with webpack chunkhash and cache control

Related searches

I am using webpack to bundle all of my files. Inside webpack I use chunkhash, Md5Hash and manifest to produce unique chunkhash for each of my files that get download by browser. It would look like this.


This means that browser can cache them and if the hash is not changed it will use the cached version.At the same time I can for example just change styles and only that hash will be changed so when I deploy the app browser will download only the new styles.

The problem is that on my server i use this:

Cache-Control: public max-age=31536000

This represents aggressive caching and the browser will use cached version for one year unless URL, file name is changed. When I for example change styles my hash is changed and browser should request the new styles from server. That is according to this article(pattern 1) and a few more that I found https://jakearchibald.com/2016/caching-best-practices/

My problem is that when I update something, example styles, hash for styles is changed and I deploy that. The browser will not request new styles unles I hit reload while on my page. It will server the cached files. How can I fix this?

I can use Cache-Control: no-cache but that is not a solution because than browser has to check with server every time if he can use cached version. That is 4 http requests that are not needed every time someone visits the page.

The way I solved this is by adding one more number (which is Date.now()) into my file names as below.

filename: [name].${Date.now().valueOf()}.[chunkhash].js This works pretty reliably for foreseeable time. The only drawback I see with this method is that: With each release, this forces all the bundles to be refreshed.

However, There are cases when chunkhash is rendered to create problem is when the modules do not change but their order changes (and hence the module id). The module id and order is not part of chunkhash! Please refer: https://github.com/webpack/webpack/issues/1856

Other alternatives is to use named module (which I believe will have some performance impact) besides may probably involve naming my modules which I am not sure of.

Make use of long-term caching | Web Fundamentals, Generate the chunk-manifest JSON and inline it into the HTML page before loading resources. Use bundle versioning and cache headers. The common approach of doing caching is to: tell the browser to cache a file for a very long time (e.g., a year): # Server header Cache-Control:

I did it like this. I use different webpack config for my client and server bundle. For my client bundle that has bundle.js, vendor.js, styles.css... I use chunkhash and Cache-Control: public max-age=31536000 as described in my question. For my server bundle that serves html(ejs) I use Cache-Control: no-cache. This works good because browser will contact server on every reload but that will be only one http request. If nothing is changed browser uses the cached version of all the assets since chunkhash in html didn't changed.

If for example I update styles and chunkhash is changed browser will see that when in contacts the server on reload and only new styles will be downloaded.

Caching, The last step can be time consuming, which is why browsers use a technique called caching. by webpack compilation can remain cached unless their content has changed. splitChunks with cacheGroups with next params and build:. Long term asset caching is accomplished by adding a content hash to the filename of each public asset. This hash should only change when the content of the file changes. This enables browsers to

The browser is only instructed to load your assets when your page loads... That is just the way it works. You can poll or use any kind of push to the browser to detect backend changes and then force your users to refresh their browser.

This is not a caching issue, not a browser issue... just the fact that as soon as you have info it might already be outdated. You'll have to live with it or create a workaround.

See it as a calendar next to the coffee machine at your company which has an event 'party' this saturday. You see it and run to your coworkers to tell them the great news. Meanwhile the person who wrote the event on the calendar realized he has made a mistake and changes the event to next saturday. You don't have this new information so you will provide your coworkers with wrong information as long as you do not go for another coffee. The only way to know about the changes is if someone would notify you sooner than you go for another coffee... for example the person who wrote the event on the calendar sends an email to everyone to say sorry for his mistake and that the party is scheduled next saturday.

Long term caching with webpack chunkhash and cache control , The way I solved this is by adding one more number (which is Date.now()) into my file names as below. filename: [name].${Date.now(). Getting long-term caching right with Webpack is a problem that never really got a final answer. There is, however, this open issue on Github:. it has 162 comments

Caching Assets Long Term with Webpack, Long term asset caching is accomplished by adding a content hash to the [ chunkhash] for filename and chunkFilename in the webpack config output: proper HTTP Cache-Control header for our assets on the server side. Inlining manifest.js for webpack long-term caching with a deterministic [chunkhash] Ask Question Long term caching with webpack chunkhash and cache control. 3.

Hashing with Webpack for long term caching from @kentcdodds on , Leveraging the browser cache is an important part of page load performance. Webpack's hashing feature so you can take advantage of long term caching of your assets. This bundle.js is going to have to have the chunk hash right there. Make use of long-term caching The next thing (after optimizing the app size) that improves the app loading time is caching. Use it to keep parts of the app on the client and avoid re-downloading them every time. Use bundle versioning and cache headers

Reimplement [chunkhash], though I seem to remember reading issues about challenges with sourcemaps. Implement a new token value (e.g. output.filename = "[name]-[chunkhash]-[webpackhash].js") such that changing anything about your webpack config or its dependencies allows you to bust the cache. Other Considerations

  • Igor, I too am facing the same problem. Any one has a solution, please oblige by posting it here?
  • Hi Abhi. See my solution below.
  • I think, this same as what you described above. Cache-Control: private max-age=31536000 But still browser is not refreshing the JS when chunkhash is changed. :(