Atomic Smash homepage splash

Add caching to WordPress [easy]

Words byDavid DarkeJuly 7, 2017

When your site is under pressure from increased traffic, the quickest possible win is to add caching. It has a bit of reputation for magically making a slow, or poorly constructed site fast. This sadly often doesn’t address the underlying cause of why the site is slow in the first place.

As a WordPress Studio, we’ve always used W3 Total Cache, it’s has a massive feature set and incredible granular control over all the different caching layers. We also take the view that it should help your site run faster with dramatic traffic increases, NOT speed up a site because it’s running a bit slow.

Like most things technology related, there are many solutions, with thousands of configuration permutations. It’s good to enable different caching layers one at a time to see their impact and performance improvements individually.

Page caching

The simplest to enable is ‘page caching’. This makes a flat HTML copy of all pages (not being excluded from caching) and then serves up this copy when a page is requested rather than the standard page. This hugely reduces database calls and can give a real boost to your site. In our experience, this form of caching will have the biggest impact on performance and general site speed.

It’s important to read through all the options for any of these caching layers as many might have an impact on site functionality. One very common example is how it effects a plugin like WooCommerce. Due to page caching essentially serving the same saved version to any user that visits that particular page, this can seriously effect checkout and cart pages. The simplest way to get around this is to exclude them from page caching completely.

Simply add these three lines to your ‘Never cache the following pages:’ text area in the page caching options:


Another major feature of page caching is its life expectancy, the cache may only ever need to be broken (cleared and rebuilt) when there is an edit to that particular page. This means that if your site consists of a large amount of content that changes infrequently, the cached versions won’t need to be updated for days, or even weeks, meaning less strain on the site and server.

Database caching

This will take snapshots of individual database queries and reduced the time of response rather than reducing the number/frequency of database queries. This becomes very useful when page caching isn’t an option, with page caching enabled far fewer individual queries and in turn less speed improvement from database caching.

One warning though, the lifecycle is actually very short for this form a caching. So if you have a page/ feature that has massive database queries, you might be able to speed them up for a short amount of time, but next user to visit that area directly after the cache dies will have to cope with those slow queries. This sometimes isn’t acceptable so it’s probably better to work out a way of reducing the larger queries rather than using caching as a speed boost for some users.

Browser caching

Most browsers by default will cache images, javascript, CSS and flat HTML automatically, but you don’t have much control over when the cache dies or any other specific details. One other really powerful option which might not be enabled by default is “HTTP (gzip) compression”. This tells the server to compress any text-based asset and then uncompress in the browser. This reduces bandwidth and amount of data going from the server to the client. Also, the processing time to compress and uncompress assets is far less than the power it takes to transmit the original assets. WIN WIN!


The last important aspect of caching is provable performance increases. This should consist of tests performed before and after the caching has been enabled. Ideally, these sort of tests would be performed on a live version of the site with no other traffic, this will give you the most accurate result possible without outside influences.

We usually perform two types of test:

Page speeds

Page speed is quite simply how long a single webpage takes to load from initial request to final asset arriving in the client’s browser. We primarily use a FREE third party tool from

Free load testing

This will give a breakdown of overall speed and what might be slowing your pages down. Having this information before and after applying caching brings a huge amount on insight into what makes your website slow to load.

Load testing

Performing a load test measures the amount of traffic (number of requests) your WordPress site can handle at in a given period of time. An open source tool like Apache Bench or a paid for service like Loadio are perfect for gauging the extra traffic afforded by adding caching.

Other ways to optimise

To find other ways to optimise your WordPress please check out some of our other posts in our series. W3 Total Cache works very well with content delivery networks.

Wordpress Optimisation


Comparing WordPress image optimisation tools to speed up your page loading

Over the next couple of months we'll be covering topics that will help speed up your site, this will improve user experience and help with your general SEO efforts.


Adding a Content Delivery network for super fast WordPress assets [easy]

Add a Content Delivery Network - CDN to your Wordpress Site in a couple of clicks


Add caching to WordPress [easy]

Speed up your site and increase possible traffic by using a WordPress Caching solution


Are simple errors and number of assets in your code slowing your site down? [intermediate]

Coming soon.


Full site PHP debugging to fix slow sites [Hard]

Coming soon.

Profile picture ofDavid Darke

David Darke

As the lead developer and co-founder at Atomic Smash, David’s wealth of knowledge in website development means that all sites work seamlessly across desktop, tablet and mobile devices.

Go back to top

Keep up to date with Atomic news