We show unabashed favoritism and profess our love for a piece of software. You lose all confidence in our sanity and wonder why you’re reading this document at all.
WordPress is our best friend. We can (and do) use it to power 90% of the sites we build. With the right technology stack, it’s as fast as any ‘enterprise’ toolset. Kept up to date, it’s secure (we’ve never had an up-to-date WordPress install hacked). The CMS is easy to use.
So yes, we’re biased. That’s why we’ve written an entire chapter just about WordPress. We’ll talk about a few general ways to add some zip, and then dive deep into our favorite caching tool, W3 Total Cache.
W3 Total Cache for WordPress
We work on a lot of WordPress sites and our caching plugin of choice is W3 Total Cache (W3TC). This plugin offers a full suite of caching options as well as integrations with New Relic and popular CDN services. W3TC modules include browser, page, database, and object caching. It also has minification options, user-agent detection and redirection, performance monitoring, and much more.
It is a very powerful plugin that addresses many of our site speed recommendations, including leveraging browser caching with expires headers, resource minification, gzip compression, and CDN-based recommendations including parallelized downloading across domains.
It is important to configure W3TC to fit the needs of your application, but we have put together a starting guide of recommendations.
On the General Settings tab, enable Page Cache, Minify (auto), Object Cache, and Browser Cache. If you have a CDN, enable that as well. For each of these settings, use the best caching method available. If you are on a shared server environment, you may only have the options for Disk: Basic and Disk: Enhanced. If so, use Disk: Enhanced. If you are in a dedicated/virtual environment, ideally you have more advanced opcode options like OpCache/APC or XCache. If any of these are available, be sure to utilize them. Page Cache Page cache will keep entire pages of your site in local cache, reducing response time.
Enable these options:
If that script is inserted in to the combined file before jquery, it will break. The solution is to use the manual file management option to define and order your scripts. The same goes for CSS, if required. In a worst case scenario, you are unable to use combining and minifying for JS and CSS. If so, follow best use practices of at least minifying your resources, if not combining them too.
Here are other general options we recommend enabling:
Object caching helps further reduce execution time of commonly called operations. Enable this option and use the default values provided.
We addressed browser caching earlier, utilizing a user’s web browser to store site resources for increased page load times and reduced server load. W3TC can generate these directives for you.
Enable these options:
Configuring your CDN usually involves creating and selecting a pull zone, entering the authorization key, and defining 1 or many CNAME hostnames. When you define (and setup) multiple CNAME hostnames, you are essentially utilizing parallelized resource downloading. W3TC is equipped to handle this.
XML-RPC is a remote procedure call protocol…
Let’s try that again, in English.
XML-RPC is a way to make your content available to other servers. It’s a kind of Application Programming Interface (API)…
One more try.
XML-RPC makes it easy for developers to grab stuff off of your site. It lets those developers ‘talk’ to your site to add, edit and delete content, upload files, get and edit comments, etc. That’s not terribly accurate, but it’s the gist.
WordPress comes with XML-RPC enabled by default. Unless you plan to use it or let others use it, you can turn it off. But, since WordPress 3.5, you have to do so manually.
An easier way is to use this plugin:
Why do it?
It’s one more thing
It’s just one more action your server has to take. Your server is busy enough. Simplify its life a little.
Leaving XML-RPC hanging out there is kind of like walking around in an (unintended) hole in your pants. It’s not the end of the world. But it’s a bit… sloppy.
Developers can ping it
Other sites could, in theory, start accessing the API. They (hopefully) can’t do anything without your permission, but they can still make requests that slow your site.
Some WordPress plugins are absolute performance hogs. Others are performance hogs if you use ’em wrong.
As a matter of course, we remove any plugins we aren’t using. They tend to pile up, so a quick cleanup is always good.
You can get a look at potential problems a couple of ways:
We’ve had good luck with P3 (Plugin Performance Profiler).
It is, of course, a plugin. That’s a bit meta. Using a plugin to find slow plugins… Never mind.
Install it, run it and you’ll get a list of plugins and performance data (screen capture directly from the folks at P3):
We recommend installing it, running it, tweaking things and then uninstalling it. You can always install it again later, and one less plugin is always better.
If you want to look impressive at the next PHP/LINUX meetup, you can:
- Run ‘top’ at the command line, filtered for PHP threads. Get the average. Remove one plugin. Do it again. See the difference. And so on
- Profile MySQL
But really, P3 Profiler should get you what you need.