Table of Contents
Last update on
This is the first post in a series where we will look at various aspects of website performance, and try to explain them in terms understandable to non-developers. This first installment looks at the concept of caching.
A lot of WordPress users have heard they need to “use a caching plugin”, and may even be using one without really understanding what it’s doing. It can be pretty technical, even for a lot of developers, so a lack of understanding leads to frustration when things go wrong.
I want to try and demystify it a little.
There are several different kinds of caching. What we are talking about in this post is specifically “page caching”. This is the kind of caching that plugins like WP Rocket, WP Super Cache, WP Fastest Cache and others do.
What Does Caching Do?
Most articles will explain caching in terms something like this:
When a visitor comes to your WordPress site, their browser talks to your web server which loads up WordPress – this involves PHP processing, making requests to your database, sending files back to the browser to finally be assembled into a fully formed webpage. This can take several seconds – an eternity to modern web surfers.
Caching replaces that process by sending a static HTML file to the browser instead, which is much faster.
While all of that is technically true, for most people, it doesn’t really make much sense, and doesn’t help you get a grasp on what’s going on.
Caching – The Big Picture
One of the best explanations of caching I have come across was at a WordCamp talk (I wish I could remember who the speaker was so I could properly credit him).
He asked the audience, what’s 3,549,752 divided by 23,234 (or something equally complex)?
Everyone fell silent. Some people pulled out calculators to do the math, and finally someone yelled out the answer after a few seconds.
Then the speaker asked the exact same question again. This time everyone was able to immediately call out the answer.
This is a great demo of the concept. The initial time-consuming process was done once, then after that, when the same question was asked, the answer was readily available, and delivered much faster.
When applied to the context of your website, this translates to the ability to deliver a webpage with a super-fast response time, without having to do all the time-consuming processing, every time the page loads.
The first visitor to a particular page on your site is “asking the question” and your server provides the answer. The next time a visitor goes to the same page, ie. “asks the same question”, your server can provide the answer, i.e the web page, much faster.
What does this mean for your WordPress site?
When you have a caching plugin, this is responsible for providing those fast answers. The plugin is basically taking snapshots of all your webpages.
All of the heavy-lifting that WordPress typically does to display the webpage is done the very first time a page is visited. Once that process has happened the first time, your caching plugin takes a “snapshot” and then, when the next person comes to your site, it whips out the snapshot instead of going through the whole rigmarole again.
Static vs. Dynamic
In technical terms, the “snapshot” is a static HTML file. Static means it doesn’t change by itself. The content of it is going to stay the same unless something tells it otherwise.
If you’ve ever looked at your site via FTP (or the file manager in your cPanel), you don’t see a file for every page on your site. That’s because the page is dynamically generated fresh each time it loads – there is no physical file.
When you have caching, you will actually see a cache folder with all the HTML files in it. Those files will only be changed when the cache is refreshed.
This is where things get a little tricky….
Imagine you take a photo of your house, which is brown. Tomorrow, you paint your house blue. The photo you have of your house is now inaccurate. If you want an updated photo, you have to take a new snapshot.
The house is your website, and the photo is the cached version.
So you have a cached version of a page on your site, then you change something, perhaps you publish a new post, you add a new widget, change your theme etc, and now the cached version is out of date.
So if you want your site visitors to see the new modification you made, you need to clear the cache for that page so a new snapshot can be generated.
Some caching plugins (like WP Rocket) handle this intuitively. We see that you “painted your house” i.e. published a new post (for example), so we take a new snapshot for you automatically.
This way your cache stays up to date.
Why Does Caching Seem To Break Stuff?
When you take a snapshot of your content, it’s like a moment frozen in time. If your WordPress site is like a movie, your cache is like a freeze-frame from that film.
This won’t matter too much if all you have on your site are blog posts or pages that consist of text, photos, videos: things that don’t change unless you yourself decide to change them (like going into the editor and changing a photo, or some text).
But modern websites can have a lot of fancy features, like content that updates automatically (without you doing anything), or that adjusts according to who is looking at the page.
A couple of examples:
Maybe you have a sidebar widget that displays your Twitter feed. When you post a new Tweet, you don’t manually go to your website and also post the Tweet there. You have a plugin, or some code, which talks to Twitter and automatically updates the widget for you – it could be happening while you sleep. This is an example of dynamic, not static, content.
Another example could be an ecommerce site that has a shopping cart icon on every page which tells you how many items are in your shopping cart. That feature is specific to each visitor because each visitor has a different number of items in their cart. So that number is dynamically generated for each visitor.
These are just a couple of common examples of content that needs to be treated differently with caching. If things aren’t coded correctly, and you use a caching plugin, you’ll find that things don’t work quite right.
Your Twitter feed doesn’t update as often as normal, or the cart icon doesn’t accurately show the number of items in your cart.
So this is where I have to get a little technical because if you have this type of issue on your site, you’ll need the technical terms in order to find a solution.
In technical terms, if your dynamic features (anything from rotating banners, voting systems, social feeds, user-specific features etc) are using pure PHP to display the output, they won’t work with caching.
That’s because PHP doesn’t run on a cached page: PHP is part of the time-consuming work that gets cut out when you use page caching.
Without caching, every time a person comes to your website their browser asks your webserver for the webpage.
PHP is a programming language running on the webserver to process this request: finding the right content from the database and sending it back to the browser. It’s like a messenger, carrying info from the database to the visitor’s browser.
Earlier I said that caching creates snapshots.
PHP is engaged the first time a page loads, but once the snapshot is taken and turned into a static HTML file, PHP goes on lunch-break. This means that no more messages are going to come from the database to your browser via PHP.
So when things need to change on your site, like your Twitter feed, you need a different messenger. In this case, it’s another programming language called JavaScript (JS). JS operates on your browser’s side rather than on the server, so even when your page is cached and PHP is relaxing with a cup of tea, you can still call upon JavaScript and its sibling AJAX to do some work for you.
So anything dynamic needs to be handled using JavaScript / AJAX because that WILL run on a cached page.
For the regular WordPress user, this means:
- You ask your developer to code things this way;
- You find a plugin that handles the dynamic content with JavaScript and states that it is compatible with page caching;
- If neither of the above are possible, turn off caching for that page, or remove the feature if it is less important for user experience than speed.
For developers this means:
- Use Javascript / AJAX for dynamic elements.
- As an example, look at our blog post on making a dynamic cart, and WooThemes’ documentation on cache-friendly cart totals.
I hope this helps to make things a little clearer, but I’d love to hear your questions – leave a comment if you still have no idea what I’m talking about!
*header image courtesy Gonzalo Iza // PHP diagram courtesy OpenClassrooms
