Use a Caching Plugin

The two that come to mind are wp-super-cache and w3-total–cache (w3tc). W3tc does quite a bit more than simply caching content so that gives it the edge, at least in my opinion. Most WordPress optimization guides start…and end with implementing a caching plugin, but this is just the first step.

Homepage Caching

The most resource intensive page to generate on a wordpress install is usually the homepage and it is also the most viewed page. By hard caching the homepage every minute via cron and using .htaccess to direct visitors to this static copy, server load can be reduced pretty significantly. Caching plugins do provide some remedy as far as front page generation and delivery but this is a better solution because it does not even involve starting up php or processing any logic, aside from evaluating a redirect rule.

Header/Footer/Sidebar Caching

Some content on a site rarely changes (header, footer, sidebar) so the same strategy described above for the index page can also be employed for other content. Using cron to regularly grab and store this content and then changing the other templates to include sidebar.inc instead of sidebar.php means generating every page on your side instantly becomes more efficient. The same works for header.php and footer.php, although keep in mind that the page title should remain dynamic and key actions like wp_head and wp_footer have to be accommodated.

Minimize Plugins

Plugins provide many necessary functions and add on features to WordPress. They also introduce overhead. The key is to decide what plugins you absolutely need and what features you can either live without or handle with direct code in the templates. Plugins aren’t bad and should be used as required. Just don’t use too many. Always keep them up to date and remove unused templates from your server.

Avoid Widgets

Widgets are fun. You drag items around and they appear on your blog. You can download new ones and re-position them at will. They make things easy but also introduce overhead. Widget compatible themes add function calls and widget positions and content are stored in the database which equals extra database reads. For this reason, I never use widgets and always strongly recommend against them. The problem isn’t the features provided by the widgets but the overhead that comes with them – all of which could easily be avoided by simply coding the feature directly in your templates.

Avoid Frameworks

There are some incredible theme frameworks out there. Developers have spent a tremendous amount of time developing a codebase that runs on top of WordPress and provides a huge amount of additional functionality. Then they can easily put together a theme that runs on top of the framework.

Many of the themes are gorgeous and coding a theme on a framework, once past the learning curve, can be faster and easier because the framework already has so many features built right in. They also usually provide a very slick administration panel which provides easy ways for a user to change the header image and set a myriad of options that control how the site works.

These are very useful features but it comes at a high cost. Frameworks add an entire layer of codebase, action hooks and database reads between your theme and WordPress. For lower traffic sites, this overhead might not be noticeable, but high traffic sites are going to pay for the convenience the framework provides. I always advise against using framework based themes.

Use Clean Templates

There are a myriad of ways to reduce function calls and database usage when coding a template. The biggest one is to figure out when a WordPress call like bloginfo() is giving you a static result and either store the result in a variable or even hard code it into the template. Granted, this does makes a theme less portable but this post is concerned with optimization, not portability.

Eliminate widget code if you are not using widgets (which you shouldn’t be), and avoid unnecessary include statements. Special loops that find recent or related items can bring in plenty of overhead. If possible, eliminate them. If not, find a way to make them faster or cache the results periodically. I realize this section is very broad and is requires advanced php and WordPress experience. Yet it had to be included because a clean set of templates is critical in order to serve content efficiently and quickly.

Implement a Hybrid Webserver Solution

Apache is a full featured webserver and does a good job processing php. Nginx is a svelte minimalist webserver that does a really good job delivering static content. Picture Apache as a 4WD vehicle with big tires and a V8 engine, and Nginx as a Toyota Prius. You want to use the 4WD to drive up into the mountains, but it would be wasteful to drive it for a local shopping trip – take the Prius instead. Using Apache to deliver simple static content like stylesheets, javascript and images is the same kind of waste because Apache’s overhead is always there, whether you are rendering a complicated page via php or delivering a plaintext stylesheet.

I’ve effectively employed both servers in a hybrid solution which leverages the strength of Apache as needed but utilizes Nginx for the easy stuff. It works like this: Nginx listens on port 80 (the standard http port) and then a set of rules helps it decide if it should deliver the request itself (js, html, css, images) or pass it on to Apache. Apache listens on port 8080 and can quickly respond to requests for dynamic WordPress content.

It is pretty normal for a single page to have between 10 and 30 static items which must also be read. Think how happy Apache would be if the number of requests was reduced by 90%? Granted, this only removes the easy requests, but it still dramatically reduces the overall load. And using low footprint Nginx to deliver a stylesheet instead of Apache with all its overhead is going to improve speed and reduce server load.

Use a CDN

CDN stands for content delivery network. It is a service that can store and deliver your static content (images, stylesheets, javascript) on demand. A good CDN delivers those items very quickly which speeds up pageloads for your site and simultaneously reduces the number of requests your server has to deal with. There are plugins (like w3tc) which make using a CDN pretty seamless to you and to your visitors. This is a huge bang for the buck option – highly recommended.

Dedicated server

Shared hosting is great when you are starting out because it is a cheap option and usually does a good job with a low traffic WordPress site. However, as your design becomes more complicated and your hit count rises, you may notice really slow loadtimes and the admin interface may become almost unusable. You are also potentially at the mercy of the other sites on the same server. If one of them is behaving badly or gets a boatload of traffic, your performance can suffer through no fault of your own. A dedicated server is an expensive option (comparatively) but makes you less dependent on the actions of other users on a shared service. However, It is not a magic bullet – having a dedicated server does not mean you can ignore all other optimization options described here.

Dedicated database server

A dedicated server is great, but it still has to act as a webserver and also as a database server. By adding a second dedicated server to handle the database side of things, your webserver is now single purpose and can focus on generating and delivering pages as quickly as possible. For high traffic sites using WordPress, this is a great (but even more expensive) way to go.

Multiple Load-Balanced Servers

Supersites have to use this simply to handle all the requests. I have worked with WordPress sites which handle huge amounts of traffic but are still extremely fast. They employ almost every option above and also employ multiple load-balanced servers. If you ever get that big, you will have to spend the big bucks and go this route also.