Apr 05 2008
Wordpress Optimisation Part 1 - The Obvious
As promised, this is the first instalment to a 3-part Wordpress optimisation guide.
Part 1 - The Obvious
This article deals with common and easily done tweakings that don’t require root/super user access to your webserver. This article mainly targets bloggers in a shared hosting environment.
1. Deactivate those nonsense plug-ins
Poorly written plug-ins could add as much as 20 SQL queries a page. If your MySQL server is hosted on a different server, 20 queries could mean a wait of eternity! Plug-ins also slow down page rendering, increasing the CPU cycle required to completely render a page. Some fancy plug-ins might bog down your webserver and this very very very bad when your site is being slashdotted or digged.
For this blog, I have disabled all plug-ins because I don’t see any necessity to enable them with the advent of Wordpress 2.5.
If you’re handy with PHP, try hacking the theme pages or Wordpress itself.
2. “Staticise” your theme
Themes were designed to be plug and play capable. But if your blog has already found its theme of a life time, why still let all those CPU crunching codes lying around? “Staticise” as much as possible!
Here’s a non-exhaustive list of variables that most probably will not change:
<?php bloginfo(’name’); ?> — The name of your blog
<?php bloginfo(’stylesheet_url’); ?> — Link to your blog’s stylesheet
<?php bloginfo(’siteurl’); ?> — The fully qualified URL to your blog WITHOUT trailing slash
<?php _e(’something‘); ?> — is equivalent to something. Period. Totally pointless wasting CPU cycles if you’re not making use of WP’s multilingual interface thingie.
3. Avoid giving out too much (useless) information
Frankly speaking I don’t see any reason why you should include post counts beside your categories or monthly archive links (ie, News (100), January 2008 (120) ). I don’t think anyone would be interested in knowing that because obviously these numbers don’t mean anything to casual readers.
If you have 100 categories, imaging how long it would take Wordpress to loop through all 100 categories. Then as an active blogger, you have been blogging for the past 4 years, then thats another 48 more loops! (4 x 12 months = 48 months).
Here’s how to throw that CPU hogger away:
Edit your sidebar.php, locate something that look like following lines
<?php wp_list_cats(’optioncount=1&hierarchical=1′); ?>
<?php wp_get_archives(’type=monthly&format=option&show_post_count=1′); ?>
Change them to:
<?php wp_list_cats(’optioncount=0&hierarchical=1′); ?>
<?php wp_get_archives(’type=monthly&format=option&show_post_count=0′); ?>
Not everyone blogs about their life or something. So why even show monthly archives on your side bar?! Delete it!
By removing category post counts and dumping the monthly archive links, my index page rendering time was cut by 250%. Your mileage might vary.
4. Oh my beloved object cache
Guys from Wordpress thought the object cache introduced since WP2.0 is dead because WP2.5 had so much performance improvements, so they conveniently dropped it. But for high traffic sites, every little cache is god sent.
To re-enable file system based object caching in Wordpress 2.5, read this article:
http://www.thebits.info/wordpress/wp25-object-cache-38.htm
If you have a very fast and optimally tweaked MySQL backend, object caching might not bring about significant performance gains. In a site I consulted with, the client reduced his SQL queries of the index page from 25 to a dazzling 4 but rendering time merely decreased by ~7%. A quick check on MySQL’s status revealed why:
The MySQL query cache hit rate was exceptionally high: over 60% !
Obviously the file system cache didn’t help much because MySQL has already cached most of the query results in memory. In some cases, using file system based caching might even be detrimental on webservers with huge numbers of connections (leading to disk thrashing, insufficiently file descriptors etc).
To calculate your MySQL query cache hit rate:
Enter the mysql command line client in SSH:
mysql> SHOW status LIKE 'Qcache_hits';SHOW status LIKE 'Questions';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Qcache_hits | 85731 |
+---------------+-------+
1 row in set (0.00 sec)
+---------------+--------+
| Variable_name | Value |
+---------------+--------+
| Questions | 206102 |
+---------------+--------+
1 row in set (0.00 sec)
Cache hit rate
= Qcache_hits/Questions x 100%
= 85731/206102 x 100%
= 41.6 % (which is rather encouraging)
Though file system based caching is the easiest to implement, it is generally not recommended for dedicated server or VPS users. I will explain why in Part 2 of this series.
5. Let others handle your feeds
There are millions of reasons why you should outsource your feeds to 3rd party websites like Feedburner and Google. The obvious reason is because they have big fat server farms that will handle almost any amout of punishment while your meagre webserver might not. So instead of thousands of RSS aggregators swarming your webserver for feeds, let Feedburner fetch the feeds from your webserver and let the thousands of readers punish Feedburner’s servers instead.
6. Upgrade to Wordpress 2.5, duh!
In addition to a cleaner, sleaker and faster administration interface, Wordpress 2.5 has brought about so much front-end performance improvements from previous versions that they should have named it Wordpress 3.0 instead.
Unfortunately, their rendering system in my honest opinion is still underperforming, so I have resorted to rewriting its presentation layer.
Part 2 - Backend Optimisation, comming soon…