visnum

When you are on a shared server, you don’t need to pay attention to how much server resources your WordPress installation utilizes. Your hosting company pays attention to that and notifies you when some code go berserk and ends up eating too much cpu or something like that. However, on a cloud computing environment like media temple’s grid server, you have to be careful with how your WordPress installation uses server resources. Your hosting company won’t notify you until the resource consumption goes abnormally high. That’s not bad, so you don’t want to be notified everytime you use more cpu than normal because we are in the year 2008 and we may need server resources for many of the applications we use.

On the other hand, when time passes and your blog starts to get extraordinary attention, you may want to learn tips and tricks on how to optimize your wordpress installation and how to minimize resources it uses. Here are tips and tricks about just that.

First and foremost, you must use caching. WP-Super Cache is the best option for that. WP Super Cache caches your posts and pages as beautiful pure html files so your server doesn’t use resources for php output. Other caching plugins don’t do that (at least I don’t know of any other). Others usually just caches the content and continues to use php cycles to deliver output.

The second important thing you have to keep in mind is that WordPress’ custom 404 (page not found thingie) handler uses too much cpu cycles. This isn’t unique to WordPress. Any other CMS like Drupal, TextPattern, etc. who uses custom 404 handling also uses more cpu cycles than any normal, usual 404 page. What to do about that? Use Google Site Maps plugin in order to inform Google faster when you have deleted a post. This plugin automatically generates a Google compliant site map and submits that to Google everytime you make a change in your content. Apart from that, there are also urls that are seeked by robots and they also can generate 404 error codes when not found. One example in my mind now is the favicon.ico file. Favicons are used by many web sites for bookmarking urls. You have to place one in your root directory because every robot I know looks at your root directory for that file. Moreover, not only robots look for favicon.ico but also many browsers look for it when users want to bookmark your blog. Many modern browsers also look for it because they display it in the tab. The best practice is, go create one and place it in your root folder. Favicon.cc is my favorite place for creating favicons and downloading them into my computer and then put them on my host. It’s very practical and free.

Same holds true for your feeds. Use Feedburner for distributing your feeds. Since your feeds will be distributed by feedburner and not by your server, you will have this load minimized too. Your domain.com/feed will be checked (almost) only by Feedburner and this is at most once or twice a day.

There may be other examples for would be 404 files that don’t come with your WordPress installation. You can make up your own examples too. Either way, you have to find a way to create them or handle them. So far, I don’t know of any plugin which handles that issue. Maybe it’s a good idea to build one. It should check for common known urls on your blog which may be requested often by robots, search engines, and like, and maybe creates them for you.

Third, comment spam also puts another weight on your WordPress installation and that eats your valuable CPU cycles too. Akismet is NOT a solution for this because a comment or a trackback or a pingback will hit your server and be recorded for evaluation anyway. WP Spam Free solves this problem by not allowing comments from agents which are not a browser. Since many bots who works for dropping spam comments and trackbacks to WordPress blogs do not recognize and use JavaScript, this plugin checks whether comment owner’s agent can recognize javascript. It’s a wise solution. It also informs normal users who turned javascript off so that they don’t get surprised when they are not able to post comments.

Those three factors are what I have experienced so far with my grid server. I think this can be the first post in a series because as time goes by I would experience new cpu cycle hungry factors and find solutions about them. So I’ll post them too. One thing I am not sure about is wp-cron.php and admin-ajax.php files. It looks weird but it seems like they eat more cpu cycles when you don’t post frequently. But this is just a guess. I’ll post about that too when I am sure of them. So, please subscribe to my RSS feed if you find this post useful, there are more to come.