Speed up WordPress by Disabling Plugins

I’ve known for a long time that WordPress plugins extend load times of both the front-end site and the administrative interface on the back-end. Each one has numerous sets of PHP calls and, since each page is loaded dynamically, every plugin has to be called and checked to see if it is included or not. WordPress leaves nothing out, so the more plugins you have, the slower it becomes as it has to check more and more.

What’s worse, if you have inefficient plugins, they can slow your site down to a crawl. The fault isn’t WordPress’s, your web host, or an overly-large image, but rather is due to poor javascript execution, logic loops, redundant code, or other culprits of Programming Gone Wild™. In these cases, the only options are to rewrite the plugin to make it more efficient or ditch it altogether.

Tired of my administrative interface taking forever to load and switch pages, I decided to test each plugin I use individually to discover the culprit and expunge it from my WordPress installation. Some of the instigators were surprising, but they’re all gone now.


I love this little tracking utility because it allows me to see people live when they hit my site. I can see when they came in, what they’re looking at, where they are in the world, and watch the ping away as they leave. It’s just very cool, but it’s also very bloated. It violates the common wisdom of tracking technologies hosted off-server, which is, “Since all the work is being done by our servers, rather than yours, it should have next to no impact on your site performance.” Google Analytics and WordPress Stats also operate in this fashion, where my web server isn’t doing the tracking or analysis so my performance shouldn’t take a hit.

Unfortunately, Woopra (or at least the Woopra plugin for WordPress) often hangs with javascript errors, leading to very long load times on all pages, be they front- or back-end. I had to disable Woopra on our wiki at work because of how much it was slowing things down (which was not using the plugin, by the way, just the stock code), but I hung onto it for my personal site because I like the utility so much. Unfortunately, I just can’t put up with it any more.

WordPress Mobile Edition

I’ve gone back and forth on mobile browsing so many times it’s like a worn out joke that just won’t go away. While I like the idea of providing improved functionality for mobile users, this plugin added at least half a second to all page load times, and often the lag was more than that. Half a second doesn’t sound like much until you’re waiting over and over again for what we have come to expect as instant. That functionality simply isn’t worth the lag to me.


This plugin allows you to manage your database through the WordPress administrative interface, and in the meantime automates some nice routine maintenance matters. However, it also slowed down my site, and since I don’t actively use it often, I went ahead and disabled WP-DBManager. I can still re-enable it if I want to do a quick backup or optimization, but most of the time it will sit dormant now.

WP Greet Box

This plugin pops up a box at the top of each post when someone comes from Google, Facebook, et. al. saying, “Welcome! You should consider subscribing!” Though generally annoying, I felt that WP Greet Box did this in a more polished, unobtrusive manner, so I’ve been using it for a while. Unfortunately, it was right behind Woopra in causing my site to slow down, so it had to go.

Total Gains

Though each of these only accounted for 0.4-1 second each of lag, between them they were doubling the load time of everything on my site, from 1-3 seconds to 4-7 seconds (approximately). In addition, now that I don’t have to worry about a mobile edition of my site, I can turn WP Super Cache up to full blast and cache/compress all my pages, decreasing load times further.

Though I’m sorry to see some of these plugins go (I’ve been using Woopra for well over a year now), it’s hard to justify negatively impacting load time across the entire site for both myself and visitors for a few minor conveniences. We must always balance functionality against speed (and security, and a slew of other things for that matter), and in this case speed won out.

For the other 26 plugins I will continue to actively use, they do slow my site down some, but all of them together only impact site times by 1-2 seconds. In those cases, the loss of speed is well worth the gain in functionality.

Which plugins do you keep even though they slow things down a bit? And which is more important to you: Speed, Functionality, or Security?

Scrolling code display boxes of doom

Why can’t anything ever work as advertised?

So, I’ve written a couple of tech articles for the next couple of weeks (scheduled to publish on the next two Tuesdays) and they had a few code snippets in them. Therefore, I thought I’d find a nice way to display that code, maybe put it in a box that preserved its formatting, and if the line was too long would present a horizontal scrollbar instead of breaking the right margin or wrapping the code.

I first tried the IG:Syntax Hiliter (it frustrates me to no end that it’s not spelled “Highlighter”), which is supposed to be the first, greatest, most original plugin for WordPress that is intended for this purpose. But when I used it, it refused to present my code in a visually accurate fashion. Or, rather, it was too accurate: it converted my symbols to their ASCII equivalent and displayed boldly that this was Plain Text mode.

You could click on Plain Text and change it to HTML, which made it look nicer, but I wanted it to default to HTML. What’s more, it didn’t behave regularly; sometimes, the code would be accepted and displayed, and other times it would be stripped out and deleted. This isn’t an issue with the plugin so much as it’s an issue with WordPress, which strips PHP from blog posts as a security measure. However, when I’m trying to post PHP to give an example, that’s pretty damned annoying.

I then tried WP-CodeBox, an off-shoot of the “Hiliter” (every time I see the word spelled that way, I think it says “Hitler”) but one that seems to be preferred by a lot of people. Unfortunately, its author’s website is in Chinese or something, has major faults on it that kick me to a partial TinyMCE window, and the plugin failed completely. I couldn’t get it to do anything.

I tried 1-2 others before finally giving up. What irked me the most is that I had it looking just fine before using pre-tags and/or blockquotes, and these plugins (even when they semi-worked) looked worse. If I included code as a regular part of this blog, I would definitely find a solution (and I suspect I’d just develop it in-house using CSS, which seems far more reliable than the plugins geared towards this task), but I just don’t care anymore.

Bugger it.