Some might say that it is a rather unusual headline coming from someone who builds entire blog around benefits of WordPress and making it into a true Web 2.0 platform. But as everything else in this world WordPress is far from perfect and dealing with my recent issues I have discovered 2 things that I had no clue about.

What is even worth – presence of these 2 problems severely impacts your WordPress blog performance and slows down your blog. But as always I will not just stop on describing the problem but also provide you with a guide to turn this problem to your advantage and get ahead of 99% of other bloggers using WordPress.

In light of work I have done recently to resolve the problem with extremely sluggish performance of my blog I had to dig through and address several problems that have direct impact on how fast my blog loads. What I have also discovered is that NOTHING impacts it more then bloated database! Due to several unfortunate factors one of the tables on my database “wp_options” managed to grow over 22MB and my blog was brought down to its knees! While it was not a problem directly contributed by WordPress but rather several things coming together to create one huge problem – it forced me to go through entire table in text format and remove all the extra entries – OVER 3 hours of cleaning by hand.

But what it also did is forced me to look at bigger issue as in process of cleaning I have discovered that all plugins I have ever installed and even couple themes managed to leave entries in very same table contributing to the total size and slow load times. Which brings me to …

2 Things I Hate About WordPress

• Problem number 1: All the plugins and even some themes use wp_options to set its setting and as such contribute to the size of the table. It is very same table used by WordPress to store ALL settings related to your blog and every time you open any page it has to be read and processed. So the bigger size of this table – longer it takes to process it and as your blog becomes older and you try new plugins and even themes – it continues to grow and contribute to progressively slower load times.

• Problem number 2: Directly contributes to problem number one and I simply can’t believe it hasn’t been addressed by developers! When you deactivate plugin or decide to switch theme (assuming it stored its settings in wp_options) – it NEVER cleans behind itself. While at this point I can’t say for a 100% that every plugin author is guilty of not creating code that would clean table after it was deactivated I had spend another hour today removing setting for old themes and few plugins I no longer use on this blog.

While you might think that what I have described above is not a big deal – I have managed to remove 275 records today that were left behind by couple old themes that I have tested on my site at some point and plugins that I decided to no longer use. As result in my page load speed tests after cleaning I went from average 2.9 seconds to 1.8 – 2.2 seconds. And my blog is only 3 month old! Can you imagine how these extra records can affect a blog that is couple years old? Which brings us to second part of this article …

How To Turn Them Into Your Advantage

I can guarantee you that most of the bloggers will NEVER even look at decreasing size of this table and cleaning old records from wp_option as method to optimize load speed of their WordPress blog. And you can use it to your advantage!

It is no secret that slow loading page is one of the major reasons people never come back to the site or blog. By improving your blog load times you get a better chance to retain visitors and turning them into readers and perhaps into subscribers to your blog.

I do have to make one statement: If you are not very comfortable working with database using phpMyAdmin, then perhaps you first read details on it before attempting any steps outlined below. I have no intentions to teach it here. Also any changes done directly on database can have drastic impact on your blog if done incorrectly and kill your blog.

• Step 1. Backup your database. Do yourself a favor and before even touching any tables – create a backup and test it by restoring, to make sure that you can do it at any time. Use this detailed Guide to Backing up and restoring your database.

• Step 2. Login to your phpMyAdmin and open database for your blog. First do a visual scan and generally table names are fairly easily associated with plugins that you use or perhaps used before and they didn’t get removed. If you find some tables left behind by plugins you no longer use – delete them. But that will only reduce the size of your database and not have big impact on performance since they are not referenced and simply contribute to total size of the db.

• Step 3. Click on Browse action for wp_options table and go through it record by record. Identify any records that were left behind by old plugins or themes and delete them. Hint: in my case I found that every record was easily associated with a plugins I no longer use and couple themes since it either included a complete name of plugin or its abbreviation.

In my case, by doing what I have described above I managed to reduce number of records in wp_options from 603 to 328. This is almost twice less records and while obviously my tests were subjective I have seen an improvement in load speed and as I have mentioned in beginning of the article speed tests confirmed my personal experience.

One thing to remember about the speed tests I performed using this tool is that many factors make it possibly invalid, such as change in internet performance as a whole and limited numbers of tests. Only tests done over period of time and with consistency can be counted but still – good housekeeping never hurts and cleaning stale records from your database will only help you, when done properly.

And finally some thoughts on the subject that come from experience of working with other CMS’s and some basic programming experience. While I’m not able to really program I can read the code and to this date have seen enough of it to know that what I’m about to suggest is not that hard of a solution.

I simply can’t understand why plugin authors don’t add a simple line of code to remove setting added by their plugin to wp_options table when it’s deactivated. It is simple enough and I have seen it as standard feature of Typo3 CMS. Or perhaps an option I have seen in PHP-Nuke – each plugin stores its settings in its own table and called for when required. Later these tables can be easily dropped (deleted) when you decide to no longer use it. Although I haven’t used Nuke for about 3 years – it was present when I last worked with it and seems like a valid option even though not as sound as one present in Typo3.

Let me know what you think and if you find this post interesting, perhaps you want to read about other options to speed up load time of your blog in my post:

• Dialup VS Web 2.0 Portals

If you're new here, you may want to subscribe to my RSS feed. Or click here to learn What is RSS And Why You Should Subscribe. Thanks for visiting!

Related posts

• Write Blog Headlines To Explode Article Views And Create Stampede Of Targeted Traffic (11)
• WordPress Wish List (5)
• Wordpress Web-Design for Web 2.0 (13)
• WordPress Web 2.0 Spot-Er Contest (23)
• WordPress Web 2.0 Guide Looking For Guest Bloggers (10)
• WordPress Web 2.0 Guide Announcement (4)
• WordPress Web 2.0 “How-To” Spot-Er MyBlogLog Community Highlight (8)
• WordPress Stats That Actually Matter (4)
• WordPress Static Front Page Options to Consider (5)
• WordPress Security Guide (3)