For most people, WordPress works fine right out of the box. However, when your blog becomes popular, you’ll find it can be a hog, generating timeouts, consuming massive CPU cycles and server resources. Eventually, your web host will complain, probably threatening to shut you down if something doesn’t change. Usually, they will suggest that you could buy more server space, a bigger server, or go to a dedicated host. But before you spend the big dollars, consider optimizing WordPress so it runs lean – and inexpensively.
This is part three of a three-part collection on WordPress optimization. Getting Started with WordPress Optimization describes how to prepare yourself for success. Easy WordPress Optimization provides a selection of easy things to do that will produce a faster, leaner WordPress installation. Advanced WordPress Optimization describes further tactics that useful, but require stepping outside the confines of WordPress to edit the configuration of your website.
In the first installment of this three-part series, I mentioned the importance of learning how to obtain and understand the statistics used by web hosts. If you’re going to improve WordPress performance, you need to understand what you are improving, and be able to gauge your success. In the second installment, we discussed the easy things to do – but there are more things you can look at. Unfortunately, it means stepping outside of the warm confines of WordPress and going directly into the guts of the server, including changes to configuration files. A general rule of thumb is that if you are going to make changes to a file, keep a clean copy so you can restore functionality to a broken site. Make small changes, then test the results. If you make five major changes, then realize one of them broke your WordPress installation, you have a lot of difficult backtracking to do.
When I back up files, I make a copy on the server or download to my local computer, then rename it with a prefix of “bup_date_filename”. For example, I have a few files named “bup_oct23_wp-settings.php” – I can always go back to a previous version if I’ve messed something up. Don’t omit this important step – the first time you need it, you’ll understand why.
Limit Search Engines:
The website statistics for one WordPress installation I was optimizing indicated that a full 20% of impressions were nothing more than spiders and search engines. They were going everywhere, they were searching every ten seconds, and many of them I had never heard of before. It was like an infestation of sumo wrestlers at an all-you-can-eat sushi bar, and I was paying for the sushi.
Please understand, impressions are good, and search engines drive impressions. But impressions from search engines are a cost – not a benefit. They don’t convert into sales, and they are frequently redundant and wasteful. If your content is only updated every few hours or days, it makes no sense to have a search engine making requests every ten seconds.
The first thing to improve the situation is to make sure you have a robots.txt file properly built and installed. There are lots of good resources on the internet that can help you with this. I would suggest three things:
First, shut out spiders that you don’t recognize, or that aren’t going to deliver impressions you are interested in. If you don’t have any content of interest to someone in China, then it’s a waste of your resources to let Baidu.com index your site. You can specify this in robots.txt.
Second, be sure that spiders are only indexing content of interest. In one of the sites I work with, we experiment with different concepts. These experiments are located on the server, but are of no interest to our readers. Yet I discovered that spiders were indexing this content. It was not only a waste of my bandwidth, but it was also something that I really didn’t want appearing on search engine results. Again, this was easy to block out in robots.txt.
Third, control the frequency of their activity. You’ll run into the term “crawl-delay” which will limit how often a spider makes a request to your site. This command isn’t respected by all web crawlers, but for those that do, it can significantly reduce their load on your resources.
Of special note is google, yahoo and bing. These are the 800 pound gorillas of the search world, so although they require some special handling, they are worth it. Google and Bing supply webmaster tools (google here, bing here) that control the crawl rate and depth of crawl. You’ll need to sign up for an account and learn some of the tools available – but in the process will also gain some insight into Search Engine Optimization. Yahoo has a specific way they like to see their entry in robots.txt – and recommend that you look for “slurp” instead of “yahoo”.
Thankfully, these special exceptions have been clearly outlined by the big three. Google’s comments are here, Yahoo’s are here, and Bing’s are here.
Reduce the Auto Save Frequency:
When looking that the “most frequented URL’s” I discovered that a WordPress internal page – admin-ajax.php – was the top of the list for most used entry point. There isn’t any information on this page that would be interesting to any reader – so why was it so popular?
It turns out that WordPress has an auto-save feature. When you are editing a post, a copy is saved every sixty seconds. Which means that if I work on a post, then leave that page open while I go eat lunch, WordPress has been pounding on my system resources that entire time. Multiply that by the number of editors and it’s no wonder this is the top page.
Auto-save is nice, but seems to be overdone in this case. I dialed back the frequency by adding a line to the end of wp-config.php, just before the final “?>” tag. Here’s what I added…
define(‘AUTOSAVE_INTERVAL’, 300 );
A warning. I mentioned that this is the advanced optimization section. Here’s where that really starts. If you mess up your wp-config.php, you’ll be unhappy. Be proactive, make a backup before you start fooling around with this one.
The above command will change the auto-save frequency to every five minutes. The value is in seconds so 60 seconds times 5 minutes equals 300 seconds. Tweak it to a compromise between your system load and the needs of your editors.
Optimize the WordPress database:
Imagine you are a librarian, and you have the complete Library of Congress at your disposal. A patron walks in, and asks you for the name of the author of “War and Peace.” That book is stored on the back shelf of the third warehouse, and it takes you fifteen minutes round-trip to find the book, write down the author’s name, and return to the front desk. Five minutes later, another library patron comes in and asks the very same question.
If you are a smart librarian, you build a smaller library with books you actually need, so you don’t have to search through a bunch of data you’ll never use. That’s what you do when you optimize a database – get rid of the trash, so the useful information is easier to get at.
There are several WordPress plug-ins that can assist with this, in particular they remove files marked as revisions. Search the WordPress Plugin Directory for “database optimization” for several suggestions. I’ve used WP Database Optimizer and WP-Optimize to reduce databases to 50% of the original size.
Use .htaccess or php.ini instead of a plug-in solution:
These two files are used to configure the performance of the Apache Web Server and the PHP engine. Messing around here is advanced stuff – but if you can make changes here, they will be faster and lighter than doing the same with a plug-in.
In my case, a plug-in was handling 404 redirects – the result of trying to access a missing webpage. I removed the plug-in, and added lines to .htaccess that prevented WordPress from trying to handle the pages I knew were going to be missing. Not a huge improvement, but still significant.
Use Firebug, Google Pagespeed or YSlow.
These are tools that are installed in your browser that will give you advanced information about the stream of information coming from your website. It will tell you if Javascripts are broken, image files are bloated, adservers are sluggish and resources are being wasted. The more you learn about these tools, the more useful they are – but this is definitely in the advanced territory – especially when you start installing tools like FirePHP, which can be used to optimize the php being used by your version of WordPress.
Build your own CDN:
CDN (Content Delivery Network) was mentioned in section two of this discussion, and there are plug-ins that make some aspects easier. However, the adept webmaster will find ways to implement this for resources particular to their website.
The concept behind CDN is rather than serve a static resource, such as a CSS file, from your website, direct the browser to download it from somewhere else. It can be done asynchronously and doesn’t consume your bandwidth. It’s simple to do, assuming you can control the URL written into the html being served.
The best way to do this is to examine your theme files. Any URL’s that point to an unchanging CSS, Javascript, image or animation are good candidates for CDN.
There are services that can be used for this. Images can be served from Picasa or Flickr. Other files can be served from dropbox, box.net or Microsoft Skydrive. Simply upload the image or file to one of these locations, obtain the public access URL, then substitute that into your HTML. Be careful that you don’t copy a URL that is somehow password protected – that will quickly bring things to a crashing halt.
This is the end of the third segment on WordPress optimization. There are some fairly advanced concepts – but with research and diligence, they will make sense, and make your WordPress site a leaner, meaner publishing machine.