Browser Caching, Explained In Plain English

If you haven’t already read it, I recommend you check out the first post in our series of performance optimization explained ‘in plain English’ where we discussed page caching for WordPress.

Now we’re going to tackle ‘browser caching’ because a lot of people get the two confused.

So the first thing to know is that page caching and browser caching are two different things.

Caching is the process of “remembering” info for fast retrieval.
Both page caching and browser caching are methods for remembering info, but they do it in different places.

Page caching happens on your server, while browser caching happens, yes, in the browser. Specifically, in the browser of each visitor and on each device that they access your site with. And just to clarify, by the browser I mean the program you use to look at webpages, e.g. Safari, Chrome, Internet Explorer, Firefox, etc.

Let’s Cook Up A Webpage!

We can imagine browser caching in terms of making a meal. In this case, the “meal” is the webpage that you want to look at, and all the files used on that page are the “ingredients”. Before you can make a meal, you have to check that you have all the right ingredients and that they are fresh. You then combine all those ingredients in a specific way to create the meal.

If this is the first time you’re making this particular meal, you probably don’t have all the ingredients on hand in your kitchen. So you’ll have to go to the store and buy them – this will, of course, take some extra time.

Now let’s say you want to have that same meal again tomorrow. This time, because you already have most or all of the ingredients in your kitchen, you can prepare the meal much faster.

Ok, so in our analogy, you use your browser to request a certain webpage – a specific meal. The browser contacts the server where that webpage lives, it asks for the recipe for that page and gets sent the list of ingredients. These ingredients are basically, HTML, CSS, JavaScript, and image files. If it’s the first time you’ve gone to this webpage, your browser won’t have any of the ingredients on hand so it has to “go shopping” and retrieve them all fresh from the server.

But when you visit that same webpage again, your browser doesn’t have to reassemble everything from scratch, it can use the ingredients it’s already stored, and only ask the server for the new things it doesn’t have.

So that’s why the first time you visit a webpage it takes longer than the following visits.

You may have noticed this phenomenon when you do repeated speed tests, or when you use the “repeat view” on webpagetest.org. The repeat view is always faster because many of the components have already been downloaded and don’t have to be fetched fresh.

The point of browser caching is to make repeat views of a webpage more efficient.

Ingredients in your kitchen go stale though, don’t they?

They sure do, and so do the ingredients of your webpage. In terms of a webpage, “stale” means that you’ve updated something, making the cached version out-of-date. Just like food, webpage ingredients must also have an expiration date so the browser knows whether to use them, or whether to get a fresh version when cooking up the webpage.

When the browser gets the list of ingredients from the server, each file has a “header”. This is just some information about that file, including how long it can be considered fresh.

This is like checking the “sell by” or “expiration” date on your ingredients. That expiration will vary according to the type of file. The goal is to keep ingredients fresh as long as possible, to avoid those time-expensive shopping trips.

So the browser checks the expiration for the ingredients list and then checks its kitchen (browser cache) to see if what’s there is stale or not. If the expiration date has not passed, the browser doesn’t need to download that ingredient, it just uses the one it already has, which is much faster.

Sometimes in Pingdom/GT Metrix etc, you get the recommendation:

“The following cacheable resources have a short freshness lifetime. Specify an expiration at least one week in the future for the following resources”

What this is saying is that these ingredients had a short shelf-life, they go stale quickly so you’ll have to shop for them frequently and that’s inefficient.

So generally, it’s a good idea to have a far expiration date so that your browser doesn’t have to do the equivalent of running out to the store all the time for a new version of that file.

What is WP Rocket’s role in the meal?

WP Rocket determines the optimal expiration dates for the ingredients so that the chef (your browser) can make few shopping trips. We do that with rules in the htaccess files.

You can only set expiration dates on files served from your site – from your own kitchen if you will.
When you buy a pre-packaged meal from a store, you have to trust their ingredients – that’s just like when you use content from a third party like Google, Facebook, etc. It’s pre-packaged and it’s not from your kitchen so you can’t control the expiration.

Google PageSpeed Insights and other tools will make recommendations about these 3rd party files (see below screenshot), but it’s impossible for you to implement them:

Remove query strings from static resources

Some of the common speed testing tools have this as a “recommendation.”
But, we don’t recommend it because of browser caching.

They are talking about files that look like this:
style.css?ver=1.1
The query string is the question mark and the information after that (ver=1.1 in this example)

The problem is that if you remove the query strings from resources like CSS files, you can no longer communicate to each user’s browser when a file has been updated.

Let’s say you have the file ‘style.css’ in your theme.
You update that file with your spiffy new style, but the filename doesn’t change, it’s still style.css.
Then you go check out your website and you see your old style, not the new one. You clear your WP Rocket cache, but still, you see the old style.

This is because your browser has already stored a copy of the ingredient, style.css which it is using. Clearing the WP Rocket cache doesn’t help because the file is on your computer (not the server where the WP Rocket cache lives), in your browser’s kitchen.

So, if you empty your browser cache, then your browser will be forced to download style.css again, and then you’ll see a new style.

But, what about all those other visitors to your site? It’s important to remember that browser caching is happening for each user, on each browser/device they use. You can’t reach into their computer and make them clear their browser cache, and the average person doesn’t do that very often, if ever. So they will be unwittingly stuck with the old, stale, style.css.

Now, if you use a query string to version the filename, you can solve this problem.
So instead of style.css, you have style.css?ver=1
Then you make a change to that file and the filename changes to: style.css?ver=2

The browser sees it as a different file and gets the new version. Boom! Your spiffy new style is available for all to see.

So, having the query string serves an important purpose, and your site will not be faster if you remove it (go ahead, test for yourself), so why bother?

That wraps up browser caching  – if you have questions, let us know in the comments!
What other aspect of speed optimization would you like explained in this series?

Check out all the installments of our Performance Optimization Series:

1. Page Caching for WordPress
2. LazyLoad Your Images on WordPress
3. Browser Caching