High-Performance WordPress Basics

Getting started with high-performance WordPress requires understanding the concepts of speed, scale, and elasticity.

What do we mean by WordPress performance anyway?

You cannot separate the definition of “performance” from the overall purpose of the site itself.

If you’re a small business who just needs to post your store’s hours and contact info, a 1-second improvement in load-time may not be all that important to you — especially once you consider the additional cost. Everyone wants a faster more efficient site, but time is not an infinite resource and–unless you are Bill Gates or Warren Buffet–neither is money.

But if you are a search marketer, obsessing over page rank, bounce rates and conversions then 1 second can change your world and will probably be worth every penny you put into it.

As you read this book always keep recommendations in context of your overall purpose.

Dimensions of WordPress Performance

There are three primary consideration when talking about WordPress Performance:  speed, scale and elasticity. This ebook examines all three but will be mostly concerned with speed and scale. Elasticity comes mostly from the server/infrastructure and as such will only be dealt with in the hosting discussion.

Speed is an easily understood concept. How fast does my page load damnit! That’s all you need to know. It’s not quite this simple of course, but for the introductory chapter it’ll suffice.

Scale is a slightly more complicated concept. What do we mean when we ask can my application scale?

Computing power is a limited resource and the performance of your website or application will be impacted by the available and consumption of that resource.

An analogy.

Imagine a bagel shop owner in a small town. They get healthy foot traffic but not enough to afford an employee so they do everything themselves. They take the orders, make the bagels, ring the register. This can totally work so long as the number of people coming in and placing orders isn’t any more than can be served relatively quickly. But as more people come in, orders pile up, wait times increase, and the customer experience is wrecked.

What worked at the scale of one customer every five minutes broke down once there were two.

Of course our intrepid Bagel-ista will inevitably have to hire someone to help her out. But if she waits too long she’ll risk losing business because of the poor customer experience. She might just go ahead and hire early expecting the increasing demand. But what if business grows slower than expected? She’s spending more than she can afford on help she doesn’t need yet.

WordPress Scaling is a Balancing Act

The same goes for websites and application. You could spend thousands of dollars a month on sophisticated Amazon AWS machinations but not have a single customer to support the investment. Likewise you could go super-cheap with BlueHost or DreamHost and end up with a crashed server on the biggest day of your business.

It’s a balancing act. And there is no right equation or server or plugin that can make the decision for you. But you can plan ahead, accepting that those growing pains will happen and putting yourself in a position to scale as rapidly as possible when that time comes.

Strategies For WordPress Performance and Scale

Given the analogy above you can see to competing strategies developing, an aggressive or over-investment strategy and a conservative or under-investment strategies. Both have advantages and disadvantages and either can be used successfully.

Aggressive v. Conservative

The key consideration of the aggressive strategy is a complete intolerance downtime. In the movie “Social Network”, Mark Zuckerburg is memorably quoted saying:

Okay, let me tell you the difference between Facebook and everyone else, we don’t crash EVER! If those servers are down for even a day, our entire reputation is irreversibly destroyed! Users are fickle, Friendster has proved that.

This is a supremely aggressive strategy, but it was probably warranted given that the ONLY market advantage Facebook had was popularity.

I think too often though those with sites/applications very different from Facebook feel they need the same strategy.

Downtime is definitely a problem, especially when it happens at an inopportune time.The advantage to an aggressive strategy is that if done right, a promo video going viral will be no big deal. But you could easily spend thousands per month on a servers you don’t need in the meantime.

A Conservative approach can be just as effective. In most web hosting scenarios, you can upgrade your site to better hardware and be back online in no time. A few minutes, or even a couple hours downtime, while inconvenient can be tolerated if expected and planned for.

We will discuss this more in later chapters but this concept of expanding quickly to accommodate a change in traffic is known as “elasticity”.

In the next chapter we will ask the question “How do I pick a WordPress Host?”

Use ZenHub.io to organize your github issues into a scum board

Just a quick endorsement. I’ve been very much enjoying using zenhub.io for work lately. I’m managing the development of “Terminus” which is Pantheon’s command line utility. Zenhub.io is a chrome extension that allows you turn the normal issue queue via into a pseudo scrum board.

zenhub.io turns your normal issue queue into a scrumboard

zenhub.io turns your normal issue queue into a scrumboard

Tech is a Boys Club

And if you don’t think so ask around. I suspect a big reason for the inane and repulsive comments like these are that most men like Tech being a boys club, and not just the ones making said comments. It’s safe, you can make whatever jokes you want, group outings are to places like beer halls and bowling alleys and gun ranges. Internal politics are homogenous. It’s hard to admit that’s not the way it should be even though you like it that way. Indeed, that’s always the struggle with inclusion: those on the inside like it there. So as a man in Tech I/we have to be as conscious as possible about ways in which we exclude, even if it makes us/me uncomfortable.

Make WordPress AJAX Calls Cacheable and Improve WordPress Performance

WordPress Developers frequently make a very tiny but critical mistake when implementing wp_ajax calls that degrades WordPress performance and the scalability of  their website in cloud environments.

For instance, Daniel Pataki at WPMU offers a very clear and easy to follow tutorial on using the wp_ajax hook to make your web pages more dynamic. His example loads additional posts via an ajax-based pagination script. Very cool and very handy. Not only will it make you site more fun to use but also reduce overall server usage because the ajax call will be lighter weight than a full page view.

But once your site is on a modern cloud hosting infrastructure like WP Engine or Pantheon or Pagely, Daniel’s implementation will actually impede the performance benefits offered by these higher end hosts.

POST Requests Degrade WordPress Performance

Cloud hosts are usually running some sort of caching or “proxy”, usually Varnish, which dramatically speeds up your site load time. But POST requests are not going to get cached because it’s assumed that when POST’ing to a site your are performing a critical action like saving/submitting data.

But in the pagination example you’re just looking up what should be cacheable data. A GET request would allow the Varnish layer to serve that from cache much faster than would otherwise be possible. This also preserves your php resources for requests that actually need them and improves overall WordPress Performance.

Making this change is super simple (https://gist.github.com/mikevanwinkle/62fec97ac8cc8da5ff03):

		$.ajax({
 			url: ajaxpagination.ajaxurl,
-			type: 'post',
+			type: 'get',
 			data: {
 				action: 'ajax_pagination',
 				query_vars: ajaxpagination.query_vars,

Some links and stuff

Moving sucks. We moved to a new apartment over the weekend and there’s just so many ways in which moving sucks. The mess, the disruption, the cleaning, discovering how dirty you really are after all your crap is removed, the cleaning, the mess, the lifting, the dusting, the cost, the cleaning. You get the idea. So I’ve nothing of worth to tell you this morning.

But Brian Gardner does, he’s thinking a lot about minimalism … which rocks. But the whole “no-sidebar” makes me nervous. What if I want to sell ads? what if … what if? Come to think about it my sidebar has been a big pain in my ass from day one. Hmm. Let’s see.

Also this is really cool if you like SVG stuff.

Finally, I was reminded how awful the 80s were this morning:

Getting rid of .git untracked file errors with git clean

The following untracked working tree files would be overwritten by checkout:

Nothing drives me crazier than trying checkout a git branch and getting this error.

$ git checkout develop
error: The following untracked working tree files would be overwritten by checkout:
	tests/fixtures/5e1c60f7048c2630c76c7e268ed7ad55
Please move or remove them before you can switch branches.
Aborting

This usually happens to me when something in my application creates cache files and the git ignore wasn’t configured. So there are several different ways to solve this depending on what you want to do.

If you want to keep the files just commit them like the warning prompts you to. In this case:

git add tests/fixtures/
git commit -m "Adding fixture files" tests/fixtures/

But sometimes you don’t want to keep them so you delete the file with:

rm r-f tests/fixtures/5e1c60f7048c2630c76c7e268ed7ad55

But then you just get the same error for another file in the same directory. You can’t delete the whole directory because there are some files in it that ARE committed and need to be kept.

What I learned today is that you can use git’s ‘clean’ function to remove these.

git clean -f tests/fixtures/

The -f flag here will force delete all of the untracked files in that directory. Alternatively if you want to be more careful you can use -i for an interactive prompt:

$ git clean -i tests/
Would remove the following items:
  tests/test-input-helper.php   tests/test-site-workflow.php
*** Commands ***
    1: clean                2: filter by pattern    3: select by numbers    4: ask each             5: quit
    6: help
What now> 5
Bye.