Website Caching

Website Caching

because performance matters

Caching is incredibly important when it comes to your site’s speed and performance.

But, the word does get thrown around a lot. “Caching will increase your site speed”, “Caching is key to your site’s performance”, etc.

Everything You Need to Know About Caching

What exactly is caching? And why is it so important when you’re designing a site?

This article will help you understand just that; what website caching is, when to use it, and how to use it effectively.

What Exactly Does Caching Do?

According to the dictionary, a cache is a collection of items stored in a hidden place.

When it comes to your site, a cache is no different: it’s a temporary location on a server and/or your computer that holds a website’s assets.

There are two types of caching that I’ll talk about;

  1. Server-side caching and
  2. Browser-side caching.

Browser Caching

A user loads your site for the first time. The browser will store or cache the contents (Assets) of your site locally. Assets include HTML files, CSS stylesheets, images, Video, or any other assets your site may contain.

When the user’s browser caches your site’s content, the browser already has all of the assets it needs to load your site. This technology is super beneficial.

The reason being, the next time that same user visits your site, the browser will load the content without having to retrieve everything from the server again, improving your site’s performance.

Server-side caching is the same idea, but the Cache occurs on the server level instead of the browser. It is easy to see why this saves a heap of time loading content.

The server doesn’t have to use PHP to communicate to the database every time a page needs to load. Once your site’s content is cached, whether it’s on the browser, the server-side, or both, your site will load much faster for your users.

So How Does All of This Work?

When you visit a WordPress website, several things happen all at once.

An Uncached Site

A single request from your computer or phone to an uncached WordPress site typically looks like this:

  1. A user wants to load a web page, so they enter the URL.
  2. The browser sends an HTTP request to the server.
  3. The server gets the request.
  4. The server passes the request to PHP so as it can execute.
  5. PHP requests the database for the site’s content.
  6. The database responds with the information that PHP needs.
  7. PHP generates all the static HTML.
  8. PHP hands off all information back to the server.
  9. The server sends that information to the browser.
  10. The web page loads for the user.

If a user has already visited your site, browser caching can help speed things up by eliminating the need to talk to the server.

When It Doesn’t Work

The only times caching doesn’t improve performance is if it’s a user’s first time visiting your site. Another example of when caching won’t work; if you have new, updated content.

In this case, the browser still has to communicate with the server and complete all of those tasks. If your site is experiencing a low amount of traffic, these requests can happen pretty quickly.

However, the moment traffic begins to scale up. This process quickly turns into a series of bottlenecks that have to be navigated by the server repeatedly.

Server-Side Caching

Here’s where a server-side caching engine comes into play. A caching engine is a software process that sits between the web server and WordPress (and its database).

With a caching engine, the server saves the output of the long process I talked about above for a set amount of time to automatically re-serve the same content to new users.

That way, instead of executing the same code and talking to the database 1,000 times for 1,000 users visiting the same page, the server runs the code one time, caches the result, and serves it back up 999 times.

In other words, server-side caching is where you can make a decent difference in performance.

Not only will server-side caching reduce the load on your server, but pages will load significantly faster because the server has only to grab and serve the saved copy instead of executing code, querying the database, and generating the output.

But, How do Users See Updated Content? Don’t worry. You’ll always be able to serve up your newest content for your users. The secret is to define the caching rules that are best for your site’s content.

Static assets that don’t change often are usually pretty safe to cache for more extended periods. These would be assets such as your logo, any central imagery, CSS stylesheets, etc.

Anything that you don’t foresee yourself updating for a while, you can go ahead and cache that content for a more significant period.

On The Flipside

On the flip side, if you have content that changes frequently, you’ll want to consider caching it for less time to make sure your users are always getting the latest content.

These would be aspects of your site, such as Static assets that don’t change often are usually pretty safe to cache for more extended periods.

An example might be a blog or eCommerce section where content is frequently evolving and updated frequently.

Don’t worry, though – even if outdated cached content is loaded, that usually doesn’t last long before the Cache resets (depending on your settings, of course).

Even on massive websites with frequently updating and changing content, caching is still used extensively. Setting server-side caching to save pages for ten minutes, for example, will result in a massive speed increase and generally won’t affect content delivery.

If you’re concerned, though, you always have the option to manually flush your site’s Cache.

How Does Browser Caching Work?

It’s easy, I promise. But first, let’s quickly go over some of the technical aspects of caching. When a user loads a web page, the browser sends an HTTP request. That request looks something like this:

The first line, GET, is the request the browser is sending to the server.

		GET /design-and-wordpress-resources/ebooks HTTP/1.1
		User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36
		(KHTML, like Gecko) Chrome/48.0.2564.103 Safari/537.36
		Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/
		Accept-Encoding: gzip, deflate, sdch
		Accept-Language: en-US,en;q=0.8
		Cache-Control: public

The rest of the lines are all examples of HTTP headers-how your site can communicate additional information.

Notice the very last line, Cache-Control: public. It is one of the many caching headers you can use to tell the browser how to cache your site.

Some popular headers you can use to give the browser caching instructions are:

  • Cache-Control
  • Date
  • ETag
  • Expires
  • If-Modified-Since
  • If-None-Match
  • Last-Modified

We’ll do a quick overview of each type – but don’t worry, there’s no test afterwards.


One of the most popular options, cache-control, is simply a powerful header for defining multiple caching rules.

With five values that can be comma-separated, you can mix and match to create the perfect caching scenario for your content.


  • Public: Allows the browser and any other network (such as CDNs) to cache the content.
  • Private: Restricts caching to ONLY the browser.
  • No-cache: The file may still be cached, but the browser should still check the server to see if the content has changed.
  • No-store: NOTHING should be cached.
  • Max-age: The maximum number of seconds a browser should use a cached file before checking the server for new content.

ETag / If-None-Match

Entity tags, or ETags, are basically like a version number that’s associated with the file.

These are super useful for cache validations when the browser checks with the server to see if the cached content is out of date or still current.

The browser uses the If-None-Match header to compare the ETags to see if the new content matches the old content or if it should take a new cache.

Expires / Date

The Expires header is very similar to the max-age value of the Cache-Control header, but instead of defining how long a cache is suitable for, you set the exact date and time that a cache expires. It looks something like this:

		Fri, 08 July 2016 23:59:59 GMT

One important thing to note: If you use an Expires header, it’s also a good idea to use a Date header to make sure the server knows the correct date right now.

If-Modified-Since / Last-Modified

Using If-Modified-Since and Last-Modified headers is an alternative to using ETags and If-None-Match headers. In this case, instead of the ETag, the validation is based upon the date a file was last modified.

The browser then uses the If-Modified-Since header to compare the date of the cached content with the date of the server content and determines if it should download a new copy of the content.

How About Server-Side Caching?

In proper WordPress form, all it takes is a plugin to tell the browser your server-side caching settings: W3 Total Cache. Of course, other plugins would also work, but this is one of the most common options out there.

Plugins like this will allow you to control server-side caching on your site, which will help you deliver content to your users super quickly.

One Thing to Note

While using plugins like this to improve server-side caching can be effective; they can take a lot of configuration and aren’t the fastest server-side solution out there.

Because WordPress plugins are PHP-based, it still takes time for the server to execute PHP-based caching code.

A much better solution is to use an HTTP accelerator such as Varnish, which sits outside of WordPress, instead of living inside WordPress as W3TotalCache does.

Varnish caches pages rendered by WordPress in memory and can serve them up at lightning speeds. A server-side solution like Varnish is often the fastest possible caching system because it serves pages directly from the server’s memory.

But also, it never has to execute PHP (or any other part of WordPress) to work.

While, in most cases, caching is incredibly beneficial to your site, there are a few scenarios where you’ll want to pay special attention to what’s going on.

The First Scenario

The first situation is probably most common whenever you install a new theme or plugin on your WordPress site.

Remember those headers that communicate to the browser? Sometimes theme or plugin developers will set their own that can override your current settings.

Instead of increasing performance, that can have the opposite effect and cancel out whatever performance boosts you had in place.

The Second Scenario

The second scenario is whenever you’re making updates to your site. While caching is essential, I’m guessing it won’t constantly be at the front of your mind for the rest of your design career.

If something doesn’t look right immediately following an update, always remember to refresh the page (and then maybe flush the Cache).

Then, depending on what content you’ve added to the site, consider how it affects your users and if you need to redefine any caching settings.

Luckily, with some help from your trusted plugins, if something gets a little messed up, you can usually get everything back on track pretty quickly.

Once you’ve optimised your site’s caching settings, your site’s loading times will be super fast.

However, if you want it to be even faster, you might want to look into other ways to improve site performance, such as auditing plugins or using a CDN.


If you’d like help with your caching (or website performance), get in touch.

(All fields are required because those spammers are a pesky bunch)