BOOTED From The Internet pt2 – WordPress Plugin Apocalypse!

A couple of posts back I wrote about the problem of my site using too many resources on my host’s shared server. While the ultimate solution was revealed in that post, I’m going to share some tips that helped me improve this site’s performance by almost 100%, even though they weren’t the cause of the original issue.

Previously, on Hypertransitory.com…

As I wrote in my last post on my webhosting problems, because of my site’s performance issues, my host (Site5.com) wanted me to either fix it or move to a higher-tier plan that would cost me about $72.00/month (much higher than my normal $13.95/month).

The ultimate cause of the problem was misbehaving search engine bots hitting the site over and over. They were spiking my CPU usage and consuming enormous amounts of bandwidth, slowing down everyone on my server.

I didn’t realize this at first, though. Initially I figured it was just my WordPress install running slowly, so that’s what I worked on fixing at the start.

Even before I got the message from my host, I had observed that my site was moving slower and slower. I let it go on too long, and now it was time to fix it or die trying shutter the site (I love this site, but I ain’t dying for it!).

MASSIVE fail fail fail

The first thing I did was check my site over using the YSlow and Google PageSpeed browser plugins.

If you’re not familiar with these plugins, what they do is load up whatever page you’re on, analyze them for speed and efficiency, then assign an overall grade based on the average scores you receive on many individual tests.

When I saw my scores, I was shocked. Pretty much “F’s” across the board.

Damn. Really?

I knew it was bad, but I didn’t think my site was running that badly. Yet, the scores didn’t lie. Almost every page I went to was an F. A few pages got D’s, and my contact page received a C, but that was the highest it ever went. Holy crap, I had a lot of work to do.

So, what was gumming up the works?

WORDPRESS PLUGIN APOCALYPSE: The Passion of the Plugin!

Problem 1A – Plugin Overload

The biggest site-slowing issue my site faced came from the plugins I was using.

When I began digging into the problems, my site was using a whopping 67 plugins! Almost every one of those plugins were performing some seemingly small task on every page load, so even though many were small, the cumulative hit was getting to be very “expensive” in terms of bandwidth and CPU power.

How did it get this bad? Well, over the years I was adding plugins that performed various task better left to a template tag or a function. I did it many times, especially at the beginning when I didn’t quite understand the WordPress theming setup.

1. For example – I was using a plugin to provide “Next Article” and “Previous Article” functionality, when really all I needed to do was add in the Next and Previous Links template tag from the WordPress Codex.
2. Another example – I was using various image widget plugins that were completely unnecessary. I could have just used a plain old text widget and dropped in the HTML image tag, but I wanted a fancy plugin. My site paid the price for this laziness by sacrificing its performance speed.
3. Final Example – I have a lot of custom image sizes on this site. Meaning that I don’t rely on the default “thumbnail”, “medium” and “large” size that WordPress creates for each image at upload time.
   
   Since I wanted to have WordPress create images at different specific sizes, I decided to use the Simple Image Sizes plugin as I couldn’t be bothered to add the necessary code to the functions file of my theme.
   
   Now this is a great plugin, and it wasn’t causing any problems, but I didn’t actually need it, since I had long ago learned how to add my own image sizes to the functions file. I was just lazy.
   
   So this plugin was a prime candidate for removal. Oh, and how’s this for a great plugin? – It also provides you the PHP code for just this situation, where you want to delete the plugin and just use the code. All I had to do was copy the code the plugin generated and paste it into the functions file. Then I deleted the plugin and my site didn’t miss a beat. Nice!

And that’s how it went down the line. When you look in your dashboard and you see 67 active plugins (oh, I should mention there were 16 plugins deactivated – that means their were 83 plugins total installed on my site!), it becomes a scary proposition to start turning things off. Especially if you don’t really remember why all those plugins are there.

As a rule, when I’m working on a client’s site, I keep a log of which plugin I’m installing and the date of install, also why I’m installing it, and if it’s supposed to be working on a specific page/post, etc.

I’ll admit that sometimes it seems silly and useless (the plugin says in it’s description what it does, right?), and the vast majority of the time I never look back at those logs, but it can save your life when you haven’t touched a site for 6 months and you just don’t remember what that one plugin is doing.

Unfortunately, I did not do this with my own site. For some reason, I’m willing to risk my own site in ways I would never risk a client site. I work on mine while it’s live, without making a backup, or let it go for months without backing up, just install anything without researching it or testing it, and make changes to the theme without documenting anything.

That won’t be happening anymore, but at the time I had really screwed myself. I was left with the unenviable task of putting the site into maintenance mode, then turning off plugins I thought I didn’t need and checking the site to see what happened.

You do not want to be in this position. After some harrowing adventures, I managed to deactivate a ton of them, and ended up with 28 plugins total (all active). That’s still a lot. I read the results of one of those WordPress surveys and I believe 10 plugins is the average number. There’s still work to do but it helped a bunch.

Problem 1B – A$$hole Plugins

Not only the sheer number of them, but the types of plugins were very important. Some are just humming along doing their jobs, but some of them are just jerks.

So what’s the number one type of plugin slowing down my site (and likely yours)??

SOCIAL MEDIA PLUGINS

Gah. I can’t stand these things. I had two running – one for the “share” buttons, and one for my “follow me” buttons.

Some of them have fancy icons with glossy sheen effects, and cool javascript rollovers. Those can become a problem if not handled correctly, but the biggest problem is those API calls.

Calling all those external services on every page load can be a huge performance hit. The very worst one is Twitter. It’s always Twitter, it’s the last one to load, and it holds up everything.

This isn’t necessarily anything the plugin can do anything about, but some plugins do perform better than others, so the developers must be able to mitigate this somehow.

For my own site, I went in search of the lightest, fastest social media plugin I could find and I discovered Social Media Feather.

As the name suggests, it’s very lightweight and doesn’t use Javascript. Sure, you won’t see any fancy hover animations, but that’s fine with me. Those kinds of things aren’t making or breaking this site (or really any site) I ended up replacing the default images with some icons I found elsewhere on the web, but aside from that it worked like a charm right out of the box.

When it came to my “follow” buttons, I removed the one I was using and replaced it with a simple text widget. Then I added plain old HTML image and link code. Rock bottom simple stuff and no crazy javascript.

I don’t dislike javascript, but I’d prefer to avoid it if I can. It’s an integral part of the web, so it can be necessary at times. Still, if I can get away without using it, I’m going to always choose to go that route.

Problem 1C – Mo’ Badder Plugins

There are other types of plugins that can really put a strain on your shared hosting server. Of course, I was using a few pretty bad ones here:

1. Broken Link Checker – constantly scanning the site over and over
2. Google XML Sitemaps – I was running this in parallel with Yoast’s WordPress SEO – YIKES!
3. WordPress Related Posts – apparently putting a huge strain on my database

I used a great article on WordPress plugins from WP Engine as a starting point to brutally and mercilessly cull the weak and the sick from my plugin herd.

My site isn’t hosted with WPEngine, but I do manage several client sites with them. I have a lot of respect for those guys, and take their recommendations seriously.

Why am I not hosted there? Well, it was a bit expensive for me, and I don’t think Hypertransitory.com is at a level where managed hosting like that is necessary (yet). I always recommend them to most businesses, though.

However, I see that WP Engine recently introduced a “Personal” tier of service for $29/month. If I ever do get booted off Site5, or if they want me to move to the $72/month VPS solution, I’ll likely jump to WP Engine and go for that option.

Check those plugins!

You can test which WordPress plugins are performing poorly by using a plugin called P3 (Plugin Performance Profiler).

This one was recommended by my webhost in their WordPress Optimization Tips knowledgebase article.

When I installed it and ran it, the social media plugins I was using were the biggest culprits. After having read through the Site5 and WP Engine tips pages, I wasn’t surprised by anything I saw there. If you’re having a problem, you might do well to install it and give it a run through.

After I was done with it, I uninstalled the P3 plugin. It wasn’t necessary anymore, but it also was throwing some database errors every time it ran. I knew I didn’t need it at all times so I uninstalled it and deleted it.

Another plugin you can use for site speed testing is the GTmetrix for WordPress. This plugin uses the Google PageSpeed and YSlow services to test your site, so you might not need it if you already use those browser extensions (remember to keep the plugin number down if you can).

You’d need to sign up for an API key at GTmetrix.com. It’s free, but you’ve only got so many “API credits” to run tests with the free version. You can upgrade to the pro service if you need to do a lot of consistent website testing.

Again, I used this but then uninstalled it. Mostly because I realized it didn’t do much more that run YSlow and PageSpeed, but also because I didn’t want unnecessary plugins installed and cluttering up the joint.

The Chopping Block

At the time of this writing, my site is getting A’s and B’s on most pages, so it’s zipping along pretty quickly.

I’m still not done, though. If you recall, I’m using 28 plugins, and I’m trying to winnow it down even more. Unfortunately, the easy work is all done, and the ones left over may be harder to remove without consequence.

At this time, here’s what I’m up against:

1. Advanced Custom Fields – This is a very powerful plugin that lets you add extra fields to your WordPress dashboard, and then place the contents of those fields wherever you like in your theme. I wrote about Advanced Custom Fields a while back on this site.
   
   While it’s an awesome plugin that I use on many client sites, there was really zero reason for me to use here. All I was using it for was placing featured images here and there, and I could have done that using the regular old WordPress code. I was just enamored with the plugin, and pretty soon there were different featured image fields everywhere.
   
   Now I have to sift through the site and make sure I didn’t place one in a critical spot, because as I mentioned before I didn’t keep good notes on this…aargh.
2. FD Feedburner Plugin – I’ve been using this one from jump street here on this blog. It seems harmless enough, but can I redirect this feed without a plugin? I have to look more into this one, but if it’s possible I’ll likely try to do it myself and remove it.
3. Redirection – I’ve made extensive use of this plugin over the years, mostly to clean up 404 errors and such that I’ve found in Google’s Webmaster Tools.
   
   If you have a large number of redirects that get requested a lot, it can result in a hit to your database, especially if you are logging all the requests, too.
   
   So if you use this plugin, make sure to check the “wp_redirection_logs” table in your database. If left alone, it can quickly grow out of control. Mine was up over 55mb by the time I got in there to clean things out. Wow! In the Redirection options, you can uncheck “log redirected requests” and “log 404 Not Found requests” to reduce the load. You can also set the number of days before the log expires if you still want to keep a log, but don’t want it growing out of control.
   
   I read recently that Yoast’s SEO plugin will start handling redirects, so it may make more sense to let that plugin handle it and remove this one. I’ll have to see how easy it is to port all of my existing redirects over, though.
4. Smart Youtube PRO – Another one I’ve used for years to provide video support to this site. All you do is paste in the YouTube video URL and add a “v” after the “http” so it reads “httpv://”. It really works great, but now that WordPress has native oEmbed, I thought maybe I should just be using that instead.
   
   However, I found it to be a bit annoying to control the width of the videos on a post by post basis. You can set the WordPress $content_width yourself (see the linked article), but it may be more difficult to customize the video display on a case by case basis. I haven’t researched much more on this one, but I’ll get around to it soon.
   
   Another annoyance is that I’d have to do a search and replace on my database to find all my previous Smart Youtube PRO links to remove the “v” from them so they all work. It would be nice if WordPress would somehow recognize the Smart Youtube PRO links to facilitate easier switching.

And that’s just the top four of the 28 plugins still left here. My goal is to whittle them down to 10 or less, so there will be more dust flying around here for awhile as renovations continue.

The Wrap Up

In this post, I wanted to go over all the plugin drama I went through on this site, but there’s still more to come. Plugins were only the first front I tackled, and just dealing with those doesn’t take you from an “F” to an “A” in YSlow or PageSpeed.

In part 3 of this series, I’ll go through some of the javascript, database and theme issues I discovered that were slowing down my site. Also, I’ll go over the addition of the W3 Total Cache plugin into the mix. I know this post was about plugins, but W3TC actually helps with many of the javascript and theme issues I encountered, so I’ll write it up with those.

Finally, here’s some screenshots of the YSlow score of my home page and an article on my site. You can see they both got A’s (or if you have YSlow or PageSpeed installed, just run them on my site instead). Some of my older pages are getting B’s, and I want to get those bumped up to A’s as well.

So with a little hard work and tiny bit of sacrifice, you can get your site cranked up to extremely fast speeds, plus you will potentially spare your wallet, since you won’t be forced to move into a higher hosting bracket. Stay tuned for next week’s post, my friends – and I’ll see you all next time!