A WordPress website without speed is like a snowfall in the spring. No one’s going to be happy about it and a lot of people will just stay away until it gets warm out again. You obviously can’t afford to let that happen on your site.
If you want to create a welcoming and warm environment on your WordPress site, it needs to be fast. There are no ifs, ands, or buts about this. Without fast-loading pages and content, you will lose visitors. That is a fact. But one way to get around this is by properly caching a website.
As this page abandonment chart from Kissmetrics demonstrates:
…visitors just don’t have the patience to wait around. So, what do you do?
But what about website caching? Have you looked into how to leverage WordPress browser caching as well as server caching and how it could further improve loading times on your website? Caching a website can mean the difference between a happy and frustrated visitor.
Let’s take a look at this. We’ll examine the benefits of website caching, the different kinds you might want to leverage for your WordPress site, and also look at the tools you can use to get the most out of it.
Caching a Website? What Is That?
So...what is website caching?
You’ve done as much as you think you can to optimize your WordPress site for speed and security, and yet, loading speeds are lagging. So, you pop open your favorite speed testing tool (like Google PageSpeed Insights) and you see optimization suggestions like this:
👍 If Google is telling you to leverage website caching, then you better do it. Click To Tweet First, of course, you need to understand what website caching is. So, let’s break this down:
When someone visits your domain, it’s not like the site magically appears on their screen. All of those pieces you’ve developed and compiled together in WordPress need to be transmitted to the user’s browser in order for them to see the website.
This means that content, images, scripts, stylesheets, and all of the other random pieces of your site all need to somehow move from your server to their browser when called upon. Which goes like this:
- The visitor loads your URL in their browser.
- The browser sends a request to your server that says, “Hey, I’d like to see this website now.” This is called an HTTP request.
- The server then gathers up the requested materials and sends them over. This is where the slowdown occurs, especially if nothing has been done to minify scripts, Gzip files, optimize image sizes, and so on.
- Once the files have been transmitted, the browser will then display the website. The process will repeat whenever the visitor goes to a new page on it. As you can imagine, all these server requests can stress out the system and put a serious strain on performance if your content isn’t optimized for speed.
This is why performance is such a common concern amongst WordPress developers. 😠 The first impression you make with a visitor is a big deal, so if it takes too long to load you could unintentionally (and perhaps permanently) turn someone off of your brand. Click To Tweet Just with one visit.
Which is why you need website caching. In the simplest of terms, here is how the process works:
- The visitor loads your URL in their browser.
- The browser sends a request to your server that says, “Hey, I’d like to see this website now.”
- The server then thinks, “Well, I just sent this page to another visitor and nothing has changed since, so I’m just going to send the same one to this guy.” That’s what website caching is. All of your images and content and scripts and text files are turned into a static HTML file and sent to the visitor. Then subsequent visitors receive the copy of that file your server has retained. It spares the server from having to repeat the same process over and over again.
- Once the files have been transmitted, the browser will then display the website.
- The cache gets “dumped” when the page updates or when the cache limit has expired. (Which I’ll explain in a bit.) And the HTTP request and processing starts over again.
As you can imagine, the process of website caching can be incredibly helpful in cutting down the time it takes your server to process all those back-and-forth queries. Especially if your WordPress site isn’t being updated on a daily basis.
Advantages of Web Caching
There are other benefits your website would reap from using website caching. In fact, there are a few advantages of web caching:
- A faster site means improved performance in search.
- Pages that load quickly contribute to a better overall experience for your visitors. While there are other factors at play, this may be the one that turns a wary visitor into a paying customer.
- Less time spent processing HTTP requests means more memory saved on your hosting server. If you’re paying for additional computing power, this could save you (or your client) money on web hosting services.
- Website caching is a helpful tool to have for WordPress sites that experience lots of traffic spikes, too.
Now that we’ve tackled what website caching is and why you should do it, let’s break down caching even further.
Free Website Speed eBook
The 12-Step Checklist to
Achieve Loading Times Under 1 Second
Server Caching vs. Browser Caching
As a WordPress developer, your main focus is going to be on server-side caching. This means putting a mechanism in place that sits between your visitors’ browsers and your web server that will generate cached web pages for your site.
Generally, when we talk about the process of website caching (as explained above), this is usually what we are referring to as it’s the most comprehensive. And there are a variety of ways you can put this caching system into place. Updating headers on your Apache server are one way. WordPress plugins are another. And you can also use a CDN.
These kinds of server intermediaries do a great job in caching most of your content, too. The pieces you’ll definitely want cached are media files, stylesheets, scripts, content, and, hopefully, API calls to third-party systems. You should also have your HTML documents cached as well.
Basically, anything that requires a lot of work to support on the server (because the files are heavy) or to process (because they run cumbersome processes) should be cached.
Browser-side caching, on the other hand, tackles this process closer to the end user’s side of things.
If you’ve ever run into issues in being able to see updates on a website from your own computer or, more likely, your client has run into these issues, the first thing you probably tried is clearing the browser cache. Which is done through an interface like this:
Basically, you’re telling the user’s browser to discard the saved copy of the web page (the cached page) so you can see the newly updated version.
Browser caching is slightly different than server caching in that there aren’t as many files stored in the browser. Images, favicons, content, and CSS files will likely be stored in a browser’s cache. All the rest, however, would need to be handled by the server.
But the process is the same. A new layer exists between the browser and the server that saves a copy of your web page. Once the cached copy expires or the user clears the cached content, the process starts all over again. This is why the browser presents the warning to users that “Some sites may load more slowly on your next visit.” When the cache clears, the server needs to generate the static HTML page all over again… which takes time.
Web Caching Techniques
Full-Page Caching vs. Object Caching
Let’s dig a little bit deeper into server-side caching as there are further ways in which you approach this. Specifically, there are two web caching techniques we should look at.
This is the standard server caching method we’ve already discussed. The cached (copied) version of an entire page is delivered as a single HTML file to your visitor’s browser. For some websites, this type of website caching makes the most sense.📈 If your website needs to handle large amounts of traffic on a regular basis or has a tendency to get big traffic spikes (like around sales holidays), full-page caching is most definitely helpful. Click To Tweet
It also would come in handy for websites that publish content regularly. Your server will still have to process first-time HTTP requests when a new article or blog post goes live. However, for visitors going to other pages that have existed for some time, full-page caching can greatly reduce the strain on your server by streamlining the process everywhere else.
On the other hand, object caching is when only part of a web page is saved for future use. Because an object cache can be programmed to be persistent, this means the caching can still be utilized as visitors move from page to page if the same “object” exists in various locations. This is particularly useful if you have the same cumbersome and resource-heavy elements or code throughout the website.
You might also hear the term fragment caching thrown around in conjunction with it. Fragment caching is basically just a type of object caching, whereby you store actual elements from a page (like widgets, images, and so on) as opposed to object caching which targets any piece of content or data from your server.
Ideally, if you are going to use object caching, you’d do well to focus on going after targets you know won’t change often but can still be problematic when called on with each new visit to a web page.
How to Leverage Browser Caching in WordPress
Our next step is to tackle actually leveraging and implementing these different kinds of website caching in WordPress. Let’s start with browser caching:
I know that I introduced browser-side caching as something that resides on the visitors’ end of the transaction, which is true. However, that doesn’t mean you can’t enable browser caching on your WordPress site. In fact, you should do this to make sure their browser gets the message that it’s okay to cache content, especially if your website has a lot of images that need speeding up.
There are a couple of suggestions from the WordPress Codex you should make use of here.
The first update you should make to your files is to set a max-age directive. Basically, this tells browsers how long they should store a copy of a web page for.
To do this, open the .htaccess file at the root of your website. Kinsta suggests you enter the following code after the
# END WordPress line:
Header set Cache-Control "max-age=84600, public"
Basically, this tells your visitors’ browsers that any media file or script shared with them can be cached for 84,600 seconds. Feel free to adjust this number if you want to extend or shorten the time frame.
Another update you can make is to dictate when the cached content must expire. This may seem redundant--and it mostly is--but certain browsers will look for both the max-age and Expires directives, so it’s best to just include both of these here.
Open your .htaccess file again. Again, somewhere after the # END WORDPRESS code line, insert the following:
## EXPIRES HEADER CACHING ##
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
## EXPIRES HEADER CACHING ##
You won’t need to include each of the Expires lines above if your site doesn’t include that type of content or script. However, if you want to be on the safe side, just leave the code as is and then update the access allowances based on what’s most appropriate for your WordPress site.
Finally, ETags should be turned off during this process. An entity tag (or ETag) allows browsers to cache web pages as they see fit. However, when you disable these in the .htaccess file, you inform browsers to disregard their rules and follow the ones you’ve specified in the Cache-Control and Expires Headers directives.
In your .htaccess, enter the following code:
# TN - BEGIN Turn ETags Off
# TN - END Turn ETags Off
Once you’ve saved the changes to your file, you should be ready to go with leveraging browser cache in WordPress.
How to Leverage Server Caching in WordPress
Moving on to server caching, you will need to employ third-party tools in order to implement this in WordPress.
The most popular option is the WordPress plugin, though not all plugins are acceptable to use. Here are some rules you should abide by if you do decide to use a plugin for server caching:
- Only use one caching plugin at a time.
- Before you choose a plugin, properly assess the quality of it. If you’re not careful, the caching plugin could slow down your site even further.
- Also, review your web host’s list of disallowed plugins. For some, the plugin is disallowed because of what it will do to your site’s performance. For others, it’s because your web hosting plan comes with server caching already. So be sure to check.
- Use a caching plugin that provides the right amount of features and controls you need. So, if you want to implement object caching, your plugin should enable you to do so.
- Also, review the results of your WordPress site once the plugin has been installed. Does your speed testing tool confirm that the caching plugin worked? Does your site load faster? And do you still see a “leverage caching” suggestion?
Any time you use a WordPress plugin, you have to be careful and make sure the installation of another tool on your site doesn’t detract from performance (which is what we’re trying to improve here in the first place). So, find the plugin that does exactly what you need.
Here are some suggestions on caching plugins you may want to use:
For some of the full-page caching plugins below, you’ll also need this guy, the Autoptimize plugin. This one specializes in handling scripts and stylesheets of a website, as opposed to media and content. It also streamlines the way in which scripts and styles are communicated to browsers (i.e. they’re placed in the footer), so it’s nice to have that additional speed optimization power inside this plugin.
The Cache Enabler plugin comes from KeyCDN and gives its users full-page caching capabilities. Simply turn it on and allow the plugin to generate static HTML versions of your web pages. In addition, you can minify HTML and CSS and you can also convert images to WebP when possible (all methods that help to speed up WordPress sites). This plugin suggests pairing it with Autoptimize.
Hummingbird Page Speed Optimization
The Hummingbird plugin isn’t just a page caching plugin. It also allows for browser and Gravatar caching, too (the latter of which is great if you run a comment-heavy blog or news site). In addition, Hummingbird does everything you would expect a WordPress optimization plugin to do: minification, Gzip compression, and image optimization.
For those of you looking for a WordPress plugin you can implement object and browser caching with, the LiteSpeed Cache plugin will do it. It also does some other nifty speed optimization tasks like minification, lazy loading images, and CDN integration.
W3 Total Cache
W3 Total Cache is one of the most popular WordPress caching plugins and for good reason. Before anything else, files, scripts, and content are minified on your server. CDN integration provides for improved management of media and theme files for faster delivery, too. And then there are all sorts of caching options available: pages, posts, feeds, scripts, database objects, and fragments.
WP Fastest Cache
WP Super Cache
Finally, we come to WP Super Cache, the most popular caching plugin available in the WordPress repository. And what makes this plugin so downloadable? For starters, it gives you three caching modes: expert, simple, and WP-cache, based on your level of comfort. The best thing about this is that each setting gives you the configurations you need to properly cache your web pages. It’s simply up to you to consider which option is best for your site.
Free Website Speed eBook
The 12-Step Checklist to
Achieve Loading Times Under 1 Second
If you’re really reluctant to add another WordPress plugin to your site, don’t sweat it. You can instead utilize a content delivery network (CDN).⚡ A CDN is, in essence, a caching server that sits atop your regular web server. Click To Tweet It stores a copy of your website and all its files on its servers in order to speed up your website and transmit your content much more quickly to visitors around the globe.
Recently, I wrote about what a CDN is and what it does for a WordPress website. Within this guide, I included recommendations for the following CDNs:
So, if you’re looking for an alternative to WordPress plugins or you want to bolster the power of the plugin with a CDN server, give one of these a go.
Server Caching with Varnish
There is one other option to consider if you want to leverage server caching on your WordPress site and this recommendation comes straight from the WordPress Codex:
This is an open-source web application accelerator (or caching HTTP reverse proxy) that works with WordPress, but does not live within the CMS. All you need to do is download the files from the website and then install them so they sit in front of your web server. Once they’re up and running, Varnish promises to speed up your website anywhere from 300 to 1,000 times the usual rate of delivery.
You already know how important speed is to your WordPress site and how well visitors receive it. (Of course, it’s not the only decision-making factor for them, but it certainly helps make a solid first impression with them.) With website caching systems in place at the server and browser levels, you can only help improve loading times even more. It’s just a matter of finding the right method of implementation or tool to get it right.
If you’re still concerned about the speed of your site and want to spend less time doing so, check out what WP Buffs has to offer. Our speedy plans will take care of all your website caching needs and more, all while sparing you the trouble of having to manage it on your own. Or check out our white-label program if you have client sites that need ongoing support.
Want to give your feedback or join the conversation? Add your comments 🐦 on Twitter.