Small percentage of users loading days-old HTML?

Question

We have a page with +50.000 active users. Sometimes when we do an update where we change both the backend and frontend, we see JavaScript errors coming in for a small percentage of people that seem to load the old HTML. (It can't find object X because we removed it from the JSON in the backend).

We witnessed this in at least both Android and IOS devices, but maybe also on desktop browers.

This can be days after the code has been changed.

I have the feeling this has something do to with bookmarks, or really old tabs.

• Is this a common well-known problem?
• What can be the cause of this old HTML loading?
• Is there anything to do against?

I don't think our users are experiencing something really negative (maybe it's a preload and they don't even see it), but it is making a lot of noise hiding real problems that we might have.

Example of one of these pages: https://poules.com/en/pools/aaygun96-wk-poule/world-cup-2018/ranking

Expatiate

You can version the JS files. Like "/20180610/file.js" to make sure the version called is the latest – Selfdeceit

Hi mplungjan, the strange thing is - it's the HTML page itself that is out of date. – Expatiate

GET requests may always be cached by intermediaries (e.g. CDNs). Try to set the Cache-Control header so you forbid this behaviour: developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control – Scow

Answer 1

this is actually a common problem with cache. So there are few things you can do to avoid or minify the problem.

1. Add a hash to the name of the files - Cache Busting «this works especially well for assets».
   Well this is easy if you are using something like webpack, gulp or grunt in your build chain. This means that all your javascript, css or other files should have a random key embedded on the name, like bundle-21mn3j32j2.js This will ensure they will be fresh new an load.

2. Also like adding a hash, sometimes not that effective, adding a version to this files at the urls - add querystring.
   In this case you will add something like myscript.js?v=26062018 «Actually you can see this very often.» Here a nice article about, why not to use it
   And here about Why and How to Use Cache Busting

3. Working with the cache configuration on the server, for your files.
   In this case configuring the response header of the files «this works specially for initial files like index.html where you won't be able to add a hash».
   Using configurations like Etags Cache-Control and Here more.
   And yes, this depends on the server so I will add urls for the major ones «apache, nginx and IIS». The use of Etags is very interesting, because it tells the browser when the file changes.

Now, my recommendation and what I have being doing. make a small index.html file and take it out of cache or use really good Etag configuration for this file, use hashed cache busting for all dependencies using webpack (ore one of the others), work on your cache strategy for images, audio,etc.

Remember that everything that you take away from cache will increase your bandwidth consumption, everything on cache will save bandwidth and also increase speed.

One last recommendation, use cloudflare.com it make it easy to do all this fine tuning and more.

To read:
- Related to Webpack, cache and filename hashing
- Cache Busting Front-end Resources: Is File Name Revving Still Necessary? - Cache-control

About cache on servers:
- Apache, and here
- Nginx, and here
- ISS

I hope it helps.

Vc

Answer 2

Looking at your page code here's what your server response header gives me for the HTML documents:

Cache-Control: private, no-transform, s-maxage=0

Breaking that down:

private means only my machine should cache it, no proxy servers.

no-transform means proxies should preserve content type, encoding and range headers.

s-maxage means the number of seconds to consider the response as fresh. It's higher priority than max-age, but here's the thing, s-maxage is a directive for public (ie proxy) caches only, a private cache will just ignore it. Try max-age instead.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control

Ethel

Answer 3

Excellent answer by miknik on what's happening. I wish I could upvote it more.

I wanted to add an additional option for handling this situation besides cache-busting, as I think that's overused and sub-optimal in many cases.

---

First, "out-of-date" caches are very common; almost everything in a computer has some sort of caching scheme, often multiple layers of caching.

I would recommend version adapting your API. The client would send its version to a central endpoint and/or request to a versioned endpoint. The API could do one of two things based on version:

1. Return all the data the client expects on that version (at least something sensible in the deleted data's place)
2. Return a standard error that says "Sorry, you are too far out of date, you must update in order to continue"

This would allow people to use their cached versions for as long as possible, reducing your load and improving performance and their experience. This will also keep all those extraneous errors from happening, because it will be handled appropriate by the version adapting.

Eventually, the user's cache will expire and they will get up to date with you. Or eventually you'll send them that error message and they will refresh their page/clear cookies/whatever in order to update themselves.

Fool