Sat 21 Oct 2006
Turbo charging WordPress - or how I made my WordPress blog 1000% faster …
If you are using WordPress to power your blog and happen to be on a slow shared hosting server , ( also referred as virtual hosting) , serving times for complicated and large pages can reach up to 20 seconds or more. This is especially true for pages containing many blocks of plugin-generated content like forums - live feeds and random content plugins. Having a slow and un-responsive site is very frustrating and visitors usually do not wait for such a long time, for a page to load and simply browse away.
In this post I will describe the steps I took to decrease average page loading times from 20sec to 0.2 sec using a combination of caching techniques and some "dirty tricks" to avoid loosing site interactivity.
Excessive loading times can be also observed even on not so slow servers , if you are facing a incoming 'visitor wave' , usually when a link to a page of your blog is published on a high traffic site like digg or slashdot. In the latter , high-traffic , case your web site might even 'hang' your web server , causing your hosting provider to temporarily disable your shared hosting account to avoid bringing down all the other co-hosted web-sites.
A great tool to check your web site loading time is Website Speed Test . Enter the URLs of some key pages of your site and if the test results characterize them as slow (as mine were) or average then you must go on reading this.
Note: I am referring here to page generation time and not generation+download times. The download time depends on your connection Internet speed and is smaller for broadband users and larger for PSTN / POTS modem users but the page generation time depends only on your server current load and speed.
WordPress core code is reasonably fast and usually the slow down is caused by either improperly written or 'computational expensive' plugins. Each plugin usually adds a set of 'filters' and 'actions' PHP 'hook' functions to modify or simply pass through pieces of content and to perform certain actions in response to certain user actions like publishing a post or leaving the comment. Since each plugin performs a different function they add various and some times variable as well delays.
The first step to speeding up your web site is to remove all unnecessary plugins and disable additional / optional plugin functions you do not use or intent to do on the future. If you are unsure if you are going to need a certain plugin or you do not use it very often just disable from the plugins page of your WorPress Dashboard and leave it there - it causes no significant server slow-down in the disabled state.
Doing that for my site decreased page average loading time from 20 to 10 secs. Not so bad but still unacceptable.
Since I am currently running a local mirror copy of my site on my local LAN using XAMMP I knew that the same pages needed ~4 sec to load on a lightly loaded P2.4 /512 MB RAM Win XP server and I suspected that something wasn't going very well with my remotely hosted site. Experience has taught me that the first thing one has to check when facing 'strange' or otherwise hard to explain problems on linux remotely hosted web sites , is folder and files permissions. Sometimes Apache / PHP (the web server software) fails to write on pages folders due to incorrectly set permissions and returns errors or slows down depending on used script error recovery strategy.
WordPress doesn't need write access to many of its folders except its file upload folder and /wp-content/cache subdirectory. Uploads were working fine so I needed to check /wp-content/cache. I knew WordPress was writing to this folder since on my winXP server it gets filled with randomly named folders/files. The permissions were right (read/write/list from all) but no files were generated.
Time to go bug-hunting …
After searching / stepping through PHP source code and searching for various WordPress configuration settings I found that I needed to add the following line in my wp-config.php file to enable caching:
Pages: 1 2
No Translations


























Print This Post
November 11th, 2006 at 07:12 am
um .. about enabling cache, is it safe to enable that ? btw try opening this page for more info regarding the cache vulnerabilities on wp
November 11th, 2006 at 20:08 pm
Thanks for the link & the info.
The specific attack mentioned in the page has been solved from v2.0.3 and upwards. (I am currently using WordPress 2.0.5)
To tell the truth, I never feel safe with any PHP scripts and always plan for the worst.(The "Worst-Case" check engineering habit)
My personal motto is that new exploits will always keep appearing - The only truly safe server is the disconnected one
By not allowing users to register and having automated off-site daily backups and "tripwire" hash file checks I hope
that my hacking detection , response and recovery time would be less than a week!
I do not keep user/customer data/emails on this site, neither important data/passwords - risking financial loss or legal action - the worst an attacker can do is vandalize my content / deface the site. But no-one is safe : www.ngtech.gr has been defaced once , a year ago , leaving me wondering why someone would waste valuable time to hack a personal homepage / blog with 20 visitors /month (back then)!