Ultimate Guide to Page Speed: WordPress Optimization

Chapter 1: A Guide To This Guide
Chapter 2: Why Page Speed Matters To Digital Marketing
Chapter 3: What Impacts Page Speed?
Chapter 4: Novice – Image Compression And Such
Chapter 5: Intermediate – Server Compression And Geekery
Chapter 6: Advanced – Varnish, Apache and nginx
Chapter 7: Tools
Chapter 8: Glossary
Hidden Track: WordPress Optimization ← You are here

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.

General Settings

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:

Minify

Minify is probably the trickiest option to configure and must be tested thoroughly. If you are able to use the auto option for both JavaScript and CSS, consider yourself lucky and go with it. Most of the time it is not that easy and requires manual defining and ordering of scripts. In this scenario, you will want to try and add in your theme’s required JavaScript and CSS scripts under their respectful file management area.

Using the auto option, W3TC tries to combine and minify all of the JavaScript into a single file as smartly as possible. However, without any ordering defined, scripts are often inserted into the combined file before their dependency file. For example, a custom script for your theme may have a jquery dependency.

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 Cache

Object caching helps further reduce execution time of commonly called operations. Enable this option and use the default values provided.

Browser Cache

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:

CDN

Configuring your CDN is made easy with W3TC’s built-in options. We (and W3TC) recommends using an Origin Pull CDN Type. This means that the CDN will automatically pull/mirror the resources from your site. The CDN should comply and mimic the header information generated by the server. This is ideal because it gives you control of your resources, like enabling cross-origin resource sharing (CORS) for JavaScript.

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.

Disable XML-RPC

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:

Disable XML-RPC.

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.

Remove plugins

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:

P3 Profiler

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.

Getting geekier

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.