[diagram] Level up Cache in WordPress – a Practical Guide

1. Why this article

Why are we writing this article?

There are many good articles out there to help people understand caching. We have listed some in the reference section below. This article is not a comprehensive guide to cache, or a general guide to WordPress caching, although it could be. Instead this is an explanation and reference point for us and our clients and an explanation of our views on caching.

There are two reasons for this article. Firstly we do have a preferred way of working which sometimes takes some explaining of some complex issues. This article tries to explain our methods and reasons.

Secondly we find ourselves explaining many times over what cache is, and how it works with WordPress in particular. We like our sites built for speed – this includes our setup. But this comes at a cost in that cache needs to be cleared for users to see content. The diagrams below we hope will explain our setup and why we do what we do!

What actually is Cache?

In all sorts of computing, a cache is a storage layer that holds a subset of data, to speed up access to frequently requested information. “The primary purpose of caching is to reduce latency and improve the efficiency of data access by minimising the time needed to retrieve information from slower storage systems, such as databases or remote servers.” The term latency is key. Latency is the speed at which a computer output gets back to the user.

Cache Definition: The word “cache” originates from the French word “cacher,” meaning “to hide.” This is not such a bad definition. Think of a pirate saving booty they need again, close to where they will next need it quickly later. More in the glossary.

If you would like help to make your site faster or better, please give us a zoom.

2. Cache explainer

Please click the tabs below to view the levels of cache we add.

3. Explanation

The pieces of the cache puzzle

A. User

Let’s start at the top. The user is YOU – the browser of web content. Hello!

b. Browser Cache

To get to any content on the web you need a web browser – software that can read the very specific language of the web. It doesnt matter what flavour of browser you have or if it is a “service” of app of some description. For example a web enabled game that looks up your score, or a booking system still are defined as web browsers as they use the Internet to get or browse data.

Of course your browser takes local copies of files and chunks of files as you visit pages on the net. This makes your experience faster and better. So when you see a website the images, scripts and styles are cached on your browser. Ever noticed that the second page of the site loads faster than the homepage? That’s because you only need to download a fraction of the files, as the rest are already downloaded to your machine.

Mobile browsers tend to keep hold of a lot more files than desktops as when you are out and about your phone really wants to give you the best experience. They also tend to hold on to files for longer which means clearing your phone’s browser cache is more difficult.

We developers can also instruct your browser to keep hold of those files for a long time. A year is recommended by Google, but then they break their own rules for things like Google Analytics reporting which for obvious reasons has no caching. When your browser caches files then something or someone has to tell them to pick up changes in those files. More usually we serve files with entirely different filenames that have never been seen before. But your website’s homepage always has the same filename, for example, so these tricks don’t always work. 

Your browser is the first thing to check if something looks older than it should.

Tip:
Something is amiss?
First thing to try is to clear your cache or force refresh the page –
Press Shift and then the refresh button on your browser.

C. Pages

Now let’s look at what your browser is accessing – the html page which sits on a web server. All web browsers are designed and made to read web pages. No matter how the site is created (Wordpress / CMS / PHP etc ) it must generate ‘pages’ in html format for your web browser to read. Alongside this the page will pull in external files such as stylesheets (CSS) and images.

Webservers are designed to serve html files to users all day long. In the old days we created websites by hand which meant updating and uploading lots of html files –  one per page…

D. Server

But… Most websites you visit are generated on the fly, so without any form of caching that html has to be generated when a visitor request a page though their browser.

How caching works for WordPress
First let us talk about what WordPress, or any CMS (content management system) does. The application (e.g. WordPress) ties together a database (which holds all the content) together with templates and scripts (PHP) to create a HTML page that is readable by any browser. This all happens on some sort of webserver – a computer with some direct connection to the Internet.

The generation of the page takes time and the server has to do lots of work to read all the data, format it and then render. WordPress, for example, works on the concept of loops whereby it loops through all sorts of content to pull out the right piece of content. To print a list of blog post titles in a certain category it must loop through ALL blog posts to find those that match. Those blog posts are found in the database, the template is the bones of the page that tells the system what to do. And the server powers the whole thing.

There are many versions of caching but the key is to make the generation of the page quicker. We do this via an Object Cache and of course trying to make our queries as efficient as possible. An Object Cache “saves” results of common database queries so that the next request can be served quicker.

Most importantly of all, power, speed and server resources are saved if we can store any generated pages, and serving these to the next user. As an aside, we should say that these stored “pages” are just chucks of code that make up pages. You cannot copy down the cache folder and expect the site to work.

A good page load speed is 0.5 seconds, so if a page takes 0.2 seconds to render before anything hits the browser this is not acceptable. Moreover the more work the server has to do the slower will other processes be. Speeding up websites is about reducing server bottlenecks, using cache, reducing data flow and serving the user only what they need. More on this later!

Most WordPress sites use some sort of file caching, where the html files are served once they are generated. If you dont then you should – see some of our recommendations below.

A site with initial visit to all pages (numbers are seconds)

CDNs

Content Delivery Networks are “cloud” based services such as AWS. They are distributed which means copies of your image file, for example, that you upload are distributed to different servers around the world. When your browser requests that image, and you are in the United States, you access the image from servers near to where you are in the US too. A html page might take an extra second to download (One whole second is a long time in web speed land) CDNs speed the web as distance to the server is one of the key aspects of improving site speed. More on this below.

Tip:
If you have international visitors then you Really need to use a CDN to be closer to all of your customers.

Cloudflare CDN

Cloudflare is different as its a pseudo CDN. Rather than uploading files and then copies are made, Cloudflare sits BETWEEN the user and the server. When a file is requested a copy is made on Cloudflare. The second user gets the Cloudflare copy which should be nearer and therefore faster than the original server. These are know as EDGE servers as they live near to the user. The WordPress server (in our case based in Manchester, UK) is known as the ORIGIN server.

This is remarkably efficient in that unlike a normal CDN unnecessary copies are not made. But it does mean that the first visitor, far from your server, might get a slow experience.

Cloudflare also caches html pages as part of what they do, meaning the visited page is more likely to come from a Cloudflare Edge server, than from the ORIGIN server.

Cloudflare also protects your server by being a barrier between it and end users. If thousands of people or more likely Bots visit your site at the same thing your server might struggle to cope with these requests. A CDN or a Cloudflare will save your server.

But we here at practically have gone further.

Cached pages are great If the site is busy. Remember the first person to visit a page causes the server to render that page, which is then stored in cache. The second user gets the cached version. But there are a lot of sites with many pages that rarely get visited. And as cache should have an expiration, for most pages on that site the user is ALWAYS the first to visit the page.

Practically Site Generator

So we created the Practically Site Generator for SEO (fancy). This creates static files for the whole site and puts them on the live server. In other words every page on the site is requested, cached and then saved as a raw html file.

There are other WordPress Static Site creators but we found lots of the great stuff that WordPress does was left behind. For example redirects which most sites rely on to mop-up changed and deleted pages. Also many compression and CSS optimisation tools are ignored by all other WordPress to HTML tools.

How does this work?

In the dashboard press “Generate Static Live Site” and the site will be converted, page by page into straight html pages. Search and replace happens and files are moved across to the correct place on the server. The result is that the user sees pre-rendered, optimised flat html files. No database, no templates. Magic and superfast!

Back to CloudFlare
In our Static Site Generator version it is not only the flat files that get served from CloudFlare servers (i.e. images and assets such as css files) but the whole site is created as flat files and these are served from cache too. Thus these files are also distributed across the net to those EDGE Servers.

What about non WordPress?
As well as WordPress sites of all sizes we here at Practically.io create big web-based business applications hosted on the cloud. Most of these are locked away behind passwords and the view is highly specific to that user. In other words the rendered html as seen in the browser is generated on the fly but is more of less unique to every user. This means that many of the steps in the uber diagram do not apply BUT we still make clever use of Object Caches to save frequent queries and CDNs for files.

4. The problem with cache

The more cache at all levels the faster the user experience.
But if the server at the of the tree is the latest and canonical version, this is also the version we want to get to the end user. But if ANY of the caches down the tree are out of sync then the end user will see the wrong version.

A practical example:

Let’s imagine you change your organisations colors and logo (and nothing else). We would change the logo image and change the stylesheet (css) to change the site colors. Both of those changes involve external files. We would then instruct the cache to be cleared at all levels. If we did not then the end user will see the old logo and colours.

5. Why speed matters

Search Speed = caching

When it comes to speed on the internet it helps to think of data as water, servers as reservoirs and wires (and Wi-Fi) as pipes. The nearer to the reservoir the bigger the pipe and the more bandwidth. As we get nearer to the end user the smaller the pipe (your home Ethernet cable or Wi-Fi). At all levels there is a limit to how much water will go down a pipe, and the longer water must travel the longer it will take.

Therefore the tactic when loading a web page as fast is possible is threefold:

Serve data as close to the end user;
Serve as small an amount of data as possible (with smaller, more compressed images for example);
Choosing what to load first.

Let’s look at that last item. As well as how much data you are trying to get through the system to the end user we use a number of tricks to serve ONLY the parts of the page the user can see first. This means that anything “above the fold” gets loaded first. Above the fold being what the user sees on their screen when the page first loads – without scrolling down. Any JavaScript, images, styles are loaded later or further down the page. This is no mean feat, as web pages are generally designed to be responsive and adaptive to all sorts of screens. Therefore the load needs to be perfect for all users and all screens. This actually means a slower load speed overall as you load some things twice. But it’s all about the user and how fast the page feels to that user.

Our very own homepage has a poor Google Page Insights score…

Speed metrics AND search results

Does speed matter?

A big assumption for all is that speed matters for search results. It does, but not directly.
This brings us to the thorny issue of automated speed metrics – notably Google Page Insights.

Speed does matter for all sorts of reasons. A fast website performs better, gives a better experience to users and eases pressure on your web server. And the site speed DOES influence search results, but not directly (as of 2024). Google measures usability and user experience by what they do. A bad site speed scores does NOT penalise you for results. in other words Google have said they do not use speed metrics as a way to influence ranking. This does bear out in that some high ranking sites also have appalling speed insights scores.  But if your site does not perform and irks your users then it is their user experience that will affect your search results.

“Core web vitals, metrics used to measure load time and other similar things, used to be a score we’d aim to get…but really, the reason we work to improve on core web vital scores is because users tend to like pages that load fast and don’t jump around.”
https://www.searchenginejournal.com/ai-has-changed-how-search-works/521724/

My site is slow – fix it please

What crops up in client conversations is speed metrics. There are many different ones, and they change all the time. The most widely quoted is of course Google and its page speed insights. But as we see above Google rankings are not directly related to page ranking. BUT you should make your site as fast as possible. If your customers are noticing problems this is the important factor. Automated systems such as Page Speed Insights are not as reliable as human interaction.

To take just one example, Google Page Speed Insights servers were (possibly still are) based in Luxemburg. So some of our sites were getting poor scores as they are optimised for that sites visitors – our Gloucester NHS site gets 95% of its visitors from Gloucestershire UK, JBR Capital gets 85% from London. Using a VPN we pre-generated the cache from Luxemburg and hey presto the Google Site Speed went up. This is not a valid test for user experience.

In other words do not be a slave to one particular automated system, but do use them as a guide. Just because Google’s particular Definition says it is slow does not mean it is.

Again does your site feel slow? Do you notice it? If so do something about it.

6. Speed vs control

When you look at our Uber caching explainer diagram above you can see many parts of the jigsaw and every one of those levels needs the cache clearing for all steps to 100% agree with the origin server. A lot of sites have mission critical information that changes from second to second. Most do not. And the caching setup needs to be decided on a site by site basis.

The static site generator takes a good long while – up to 30 mins for our most complicated sites. So it only works on sites that update once a week or less. But then most WordPress sites out there dont update their content very much at all.

The more cache you have, the more speed you get. But the more you have to clear the decks.

Speed is green

As part of a pitch for a “green” banking firm we had to audit the green credentials of our sites. Specifically carbon usage for websites is something we should all be aware of and be cutting down on. Turns out that fast sites are generally green too. CDNs aim to serve files from as close to the user as possible. So shortening the length of wire data must travel through cuts down speed as well as usage. Cache at all levels is more efficient as nothing has to be generated. At a browser level the more your computer can grab from local cache the less work it must do. And this is why mobile phones tend to keep hold of site data for longer.

7. The more visits the faster it gets

The wonderful thing about cache is by serving cached versions of files, and of CDNs such as Cloudflare rather than generated on the fly ones, the site is faster and faster for multiple users. With WordPress and only page caching enabled, the first user might get a slow experience but everyone afterwards gets cached versions and will have a lightening fast experience. Web servers are built to handle 1000s of requests a seconds, but the less work they have to do the better.

One of the problems is with sites that are rarely changed and whose pages are rarely visited, other than a few key ones. Most WordPress sites come into this category with the homepage and a few others taking a large proportion of the traffic. This means visitors to these key pages get cached pages, but for other pages they are the first, and often only visitor. They get a slower experience.

There are two (and a half) ways to get around this problem. The first is to simulate browser visits by crawling all of the pages on the site. We Use ScreamingFrogSEOSpider for this and other valuable site checking tools. This is where the green site speed graphs above come from.

The second is to create static versions of the pages and serve this static html instead. We built our own tool for this (more above).

And there is a third, which we have never successfully being able to deploy, which is to generate pre-emptive cache. Many of the WordPress plugins we list below have this capability, but we have found the results patchy and unreliable in all cases.    

8. Glossary

Browser Cache  – Temporary storage in a web browser that holds web documents (such as HTML pages, images, and scripts) to reduce server requests and load time on subsequent visits
Server-Side Cache – Cached content on the web server, which can be accessed by all users rather than individual browser caches.
Page Cache – Caching static pages to serve them quickly without needing to process server-side scripts or access databases.
Static page – A web page that is delivered to the user’s web browser exactly as stored, without any server-side processing or dynamic content generation.
Static Site Generator – tool that generates static HTML pages from source files. Unlike dynamic websites that generate content on-the-fly using a server-side language and database, static sites are pre-built and consist of static files that are served directly to the user by the web server.
CDN (Content Delivery Network) – A network of servers distributed across various locations to cache and deliver web content to users from the nearest server, improving load times and reducing latency.
Edge Cache – Caching at the edge of a network, close to the user, typically implemented by CDNs to reduce latency and improve response times.
Latency – The time delay between a client request and the initiation of the server response. This can be affected by network speed, distance between client and server, and the efficiency of the server’s processing.
Response Time – The amount of time it takes for a web server to respond to a client request. It is a critical metric for assessing the performance and user experience of a website
Browser Processing Time – The time it takes for the browser to render the received content. This includes parsing HTML, CSS, JavaScript execution, and rendering the page.
Load Time – The total time it takes for a web page to fully load and become interactive for the user. This includes downloading all resources (HTML, CSS, JavaScript, images) and executing scripts.
Render Time – The time it takes for the browser to display the web page after receiving the server response. This includes parsing HTML and CSS, executing JavaScript, and rendering the layout and images.
Minification – the process of removing all unnecessary characters from source code without changing its functionality. Minification reduces file size and improves load times for websites by decreasing the amount of data that needs to be transferred between the server and the client.
Compression – Refers to the process of reducing the size of data transmitted between a web server and a client (usually a web browser). This helps to speed up the delivery of web content, reduce bandwidth usage, and improve the overall user experience. Compression is typically applied to text-based resources like HTML, CSS, JavaScript, and sometimes images and other media files.
Pre-load – A technique used in web development to instruct the browser to load specific resources as soon as possible, even before they are needed by the rendering engine. This helps improve performance by ensuring that critical resources are available immediately when required, reducing delays and enhancing user experience.
Defer – Defer is an attribute used in HTML to manage the loading and execution order of JavaScript files, improving page load performance and user experience. When applied to a script tag, it instructs the browser to defer the execution of the script until the HTML document has been fully parsed. This prevents the script from blocking the rendering of the page, allowing the content to be displayed more quickly.
Async – Is an attribute used in HTML to control the loading and execution behaviour of JavaScript files. When applied to a script tag, it allows the script to be downloaded asynchronously while the HTML document continues to be parsed. Once the script is downloaded, it is executed immediately, potentially before the HTML document finishes parsing.
HTTP Request – Is a message sent by a client to a server in the Hypertext Transfer Protocol (HTTP), asking for specific resources or actions. It is a fundamental part of web communication, enabling clients (such as web browsers) to interact with servers and access web content. Pretty much all websites use HTTPS, which means the site is secured by a certificate.
Lazy Load – An optimization technique used in web development to defer the loading of non-essential resources until they are needed. This improves initial page load times, reduces bandwidth usage, and enhances the overall user experience by prioritizing critical content.
Above the Fold – Refers to the portion of a web page that is visible without scrolling when the page first loads in a user’s browser.

9. WordPress plugins

Not an exhaustive list but the ones we rely on and recommend.