Wordpress Responsiveness, Part 1

How Fast Does Your Site Load?

It is a question that matters to your readers, to Google (and other search engines), and thus should matter to you. This is likely obvious to you. What you may not realize is there are a few fundamental types of site/page speed and how you handle each of them matters. In this article I’ll walk you through some of those details.

Response Time

This measurement is known from a technical standpoint by the name “Time To First Byte “, or TTFB. I discuss the details of this metric in an earlier Time To First Byte article about how much attention it should get. Now, I’ll discuss Wordpress specific aspects of it you should be aware of.

First and foremost your response time is dictated in Wordpress by how fast the page is assembled. Most often I see people blame or praise their provider for this speed. While the resource allocation from your provider is important, there are more important factors you have control over and your provider does not. Specifically, I am referring to Wordpress plugins.

You can have the absolute fastest database on the fastest possible web server hardware and still have a long TTFB due to your selection of plugins. Some plugins hook into the page generation phase and retrieve external data before allowing it to proceed. Some make expensive, and frankly ugly, DB queries before letting the server respond.

Examples of these I have found so far are every “combined SEO” plugin I’ve experimented with,  the plugins to activate “Social Logins” such as using Facebook, Twitter, G+, etc. to let readers comment on your posts, and any plugin building or modifying javascript or stylesheets.

These plugins may be useful, but you need to consider the tradeoff. Is it really a net positive when your site is so slow people simply move on, or it drops in search rankings because it takes 15 seconds to generate? How much benefit  do the SEO plugins provide if the increase in search ranking is countered by the ranking drop due to slowness?

Basic Testing

In order to determine this, you must do some form of testing. There are many resources available such as Webpage Test, a popular site to run spot-checks from. However, by installing a caching plugin and configuring it to place a footer in the cached page, you can do more direct and repeatable testing yourself rather easily.

For this (and many other reasons), I recommend installing WP Super Cache (WPSC). This plugin will speed up your site but for this purpose we are using it for it’s simplicity and the embedding of page generation time into the HTML.

Page generation time is not the same as TTFB. However, I have found a correlation between the two. Thusly, by reducing page generation time you should also see a reduction in TTFB. Plus, this is an easy way to test in a relatively simple fashion.

Once you have WPSC working load your page in a separate window and view the page’s source (how you do this is browser dependent). Scroll to the bottom and you will see the time it was cached and how long it took to generate the page. This is the metric we are looking for. Note the time in seconds it took, then using the control panel in WPSC clear the cache. Now reload the source and record this time. Do this a few times to get a baseline of your current page generation.

Now you can make module changes and repeat the process. For example if you are using an SEO plugin deactivate it, clear caches, and repeat the above process. Run your tests often enough to get a consistent number. Sometimes you may have to start from a setup where  all plugins other than WPSC are inactive and add+test one at a time. Indeed if you can do this, I’d recommend this method.

Alternatively you can bypass the cache by adding the donotcachepage variable to a given request. The details on this are on the Advanced settings tab in WPSC. There will be a string of numbers and letters which if added to a URL with “?donotcachepage=<INSERT STRING HERE>” will bypass the cache. In order to use this in testing you’ll need to script it somehow. For those on OSX or Linux a simple shell script which uses curl and time to record how long it takes to get the page can be useful.

Keep in mind this will be a  different metric as it will now be recording how long it takes to download the page as well. This can still be useful so long as you make one change and only compare this metric to itself. Do not compare the results of this test to the one above. I’ll be posting a more detailed and technical method to get strictly TTFB from the command line soon.

Alternatively you can use WebpageTest as noted above to get specific timings. These methods, combined with some custom testing code, provided me with the tools and data to dramatically lower the performance on this site. My front page went from taking nearly a minute to about a second or less.

Summary

Now that you have a means to determine how long your site is taking to respond, and potentially to load you have the means to identify what plugins you already use are causing slow performance, and to identify what the effect of a new plugin would be on your site. Be sure to use these tools to check your site now and after code changes such as updates, theme changes, and plugins used or added. Your users will thank you for it, the search engines will reward you with better ranking, and your audience will be able grow better.