• Created: 09/12/2024
• Last updated: 25/12/2024

Ever clicked refresh and been left wondering; “Why isn’t it changing??”

So your web developer has just updated you, letting you know that they have completed the latest set of changes to your website.

You open your website, and… nothings changed. You hit refresh… still nothings changed!! The same old content is sitting there looking back at you.

Now your left wondering what’s wrong. Did they even do the work? You ask them what’s up, and the inevitable response will be something along the lines of…

“Have you tried a hard refresh?”

We web developers can sometimes forget that this is not common knowledge, and that without further context, this could be confusing and frustrating.

Let me explain what’s going on, and try to give a more useful answer.

Why does this happen?

When you visit a website, your browser (Chrome, Firefox, Safari, etc.) locates and downloads the necessary files to display it. These can include:

• HTML (the structure of the page)
• CSS (styles like colours and layouts)
• JavaScript (interactive features)
• Images, videos, fonts, and others…

Downloading each of these files takes time, and there can be a lot of them! So web browsers use something called caching (its ‘cash-ing’) to speed things up a bit.

What is caching?

In this context, caching is when your browser saves a copy of some or all of the website’s files on your computer. This way, the next time you visit the website, or just visit another page of the same website, it can load much faster. This is because it doesn’t have to go and get these files again from (potentially) the other side of the world.

Caching is great. However, in programming we have a very clever saying which goes something like…

“There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.”

And what is cache invalidation?

Cache invalidation is ensuring that cached items are not hanging around for any longer than they are welcome, If they don’t, we wont always be looking at the latest version of every file… And that is exactly the problem that we are dealing with here!!

When your browser is holding on to these files, and nobody tells it to update them, it probably wont!

How do I fix it?

So now we know that the solution here is cache invalidation. To be specific we only want to get rid of files relating to your website held in the browser cache.

This is where the “hard refresh” comes in to it.

A hard refresh tells your browser to fetch everything for the current page all over again, even if it has already cached some of the files.

How do I do a hard refresh?

The table below shows keyboard shortcuts to perform a hard refresh depending on your browser and operating system:

(With mobile browsers it is often necessary to clear the cache in browser settings.)

So, visit your website which is not updating as expected, and try a hard refresh.

Can this be prevented in the first place?

The hard refresh is manually wiping out all cached files for your website. It would be much neater if the browser could automatically be told which of these files are out of date, and to fetch fresh copies of only those files.

Proper cache invalidation is the answer. And your dev ops / web development team are the people who can sort this out.

There are several things that can be done to achieve this, and in an ideal situation, you will have all of them in place for your website.

Cache static assets with ‘cache busting’

By giving each version of each static asset file (images, CSS, javascript, etc) its own URI, it ensures that it cannot already be cached, this is known as ‘cache busting’. By doing this you can set a long expiry date on each cached file, and be reasonably sure that every visitor will still see the latest version.

Implementing this requires a bit automation, as all references to your static assets now also need to be updated along with generating a unique URI.

This behaviour is built into most modern web frameworks, such as vue or phoenix, but cannot always be easily retro fitted to less advanced codebases.

Server configuration

Configure your server to tell browsers how long to cache files for. This is done by setting the Expires and Cache-Control headers appropriately.

The Expires header tells your browser the earliest date that it should check with the server for changes to the file.

The Cache-Control header tells the browser how, if at all to cache a file, and for how long.

If, according to the Cache-Control or Expires header, a cache is still valid, your browser will not automatically check for changes to that file. Saving you the time that it would take to download those files again… which is great, unless you need to make changes to said file!!

For example, with nginx, these headers can be set for specific file types in a location directive like so:

location ~* \.(?:ico|css|svg|js|webp|woff2)$ {
   expires 365d;
   add_header Cache-Control public;
   # ...
}

Here we tell the browser to hold on to static asset files for 1 year. This is fine when combined with cache-busting, or when you are sure that files will not change for at least a year.

Clear communication within teams and with clients

This doesn’t directly address the problem like the previous two points, but we can reduce the confusion and frustration caused by having clear, respectful communication.

By taking the time to explain why you cannot see the latest updates, and how get them to load with a hard refresh.

And of course, by writing brilliant blog articles like this one…

What if that didn’t work?

If you tried a hard refresh, and it hasn’t got the latest version of your website loading for you, try the following:

• Clear your entire cache: Most browsers allow you to do this in the settings menu. It’s less ideal, but might just get the job done.
• Test in a private/incognito window: This bypasses cached files.
• Contact me: If none of these solutions work, let me know, and I’ll be happy to help. I provide support and maintenance services to help keep your website running smoothly.

Conclusion

Web browsers are mighty tools which handle a lot of complexity behind the scenes in order to show us websites quickly and efficiently. We all depend on them more and more these days.

By learning a little more about how they work, we can wield them more deftly, helping us all to be less stressed, and more efficient.