I am using Scripts.Render() on ASP.NET MVC - what can the reason be that 6 hours after the update users still get the old (bundled) script file?

https://poules.com/us doesn't have a cache-control:max-age specified so you probably have some users on browser cached html which would use the old scripts.

There is a s-maxage set, but that is only an override for public cache max-age which isn't set and this page cache is set to private; so I don't think it is doing anything.

Also, you can check Azure to see what is deployed if you have access to the Azure portal.

best way i find around any web interface that requires a forcing of update client is to use a manifest file, and have that specify the scripts. Your bundle needs to then update the manifest with the correct hash. I normally just use a grunt task for this and placeholders within the manifest.

You then manage the manifest in code. with listeners for updateReady and completed so you know when to refresh the browser.

On another note, Application Cache is for older browsers, for new browsers you have to use the Service worker in order to provide a facility to update your app.

With both applied you will have a release schedule you can manage and mitigate issues like you have been getting at the moment.

Another method if you have an API, is to allow the API to serve up Javascript, based on a given version number for the users current web front end. This way you can then inform the users that a more recent version is up to date, and offer a reload button.

However Application cache through manifest or service workers, is more accessible to other teams, if you have a split, front end and backend setup.

+++++++++++++++++++++

Another reason why, could be because your web font is blocked by ad blockers like Ghostery and AdGuard. This in turn creates a unhandled error

auth-dialog-window?openerOrigin=https%3a%2f%2fpoules.com&color=FF533C&pool=&openerType=iframe:82 Uncaught ReferenceError: WebFont is not definedat auth-dialog-window?openerOrigin=https%3a%2f%2fpoules.com&color=FF533C&pool=&openerType=iframe:82

This could potentially stop other things from working and loading in the right way. You need to make sure that you are picking up and catching all errors and events for all of the users, no matter what plugins they use.

To be fair, on looking it could very well be the adBlockers that are your main issue here.

Anyway hope this all helps

Even if the hashbomb stays the same, the asset/bundle files do expire at their own pace but only after a day; at the moment of writing I see the following dates

Date: Fri, 25 May 2018 17:11:21 GMTExpires: Sat, 25 May 2019 17:11:22 GMT

If you update your main-bundle at Fri 18:00:00, it might not be used until after Sat 17:11:22.I also notice you are mixing public and private cache locations; by caching the bundles public, any proxy server (if one is involved) maintains its own cache by which the browser might get served, which might also result in a delay.

Is it an option to not cache your webpages so that the hashbomb is always up to date?

I also usually server my assets without caching but with the Last-Modified header,doing so ensures that the browers at leasts makes a request for each asset providing the If-Modified-Since header, upon which IIS responds with te 304 status code if there's no change (so that no bytes go over the wire).