A Simple Solution To Running Lots Of WordPress Plugins Without Sacrificing Blog Performance

blog-performance

What makes the difference between blogs that make money... and those which don't? Find out how blog monetization REALLY works in 2017... and how it has everything to do with getting traffic. Pick your date and time for this free blog monetization workshop.

 

Being forced to pick and choose which plug-ins you’re going to keep on your blog and which you’re going to sacrifice is annoying.

But, many are made to face these decisions because their blog is running kinda slow. And we know that site speed is most definitely a factor when it comes to SEO.

Not only that, when you’re using your blog to sell, it really will screw up your conversion rates if people feel like your blog is slow. 40% of people will abandon a website which takes more than 3 seconds to load.

When it comes to WordPress blog performance, one of the most common suggestions is to limit the number of plug-ins you’re running. But, that isn’t necessarily welcome advice when you really LIKE the plug-ins you’re running.

[Tweet “Plugins are one of the best features of WordPress! Why be forced to disable them?”]

The Reason Plug-ins Harm Blog Performance

The advice to limit your plug-ins is based on solid fundamentals. It comes down to two main factors:

  1. Every plug-in you tack onto WordPress means more code that has to be executed by your web server every time a page is loaded.
  2. The way most plug-ins work, any of their “payload” is tacked onto every page of the blog.

Now, how much those two factors impact the blog’s performance comes down to the nature of the plug-in. If the plug-in is designed to do something on the front-end of your blog (as in, your visitor will SEE it), then typically the plug-in will be coded to hook into common elements of the theme. The header and footer sections of the theme are the most common places that plug-ins like to dump code.

For instance, let’s take OptimizePress. A very popular marketing system for WordPress. It can run as either a theme or a plug-in. Personally, I use it as a plug-in because I really like my custom theme (powered by Genesis). But, here’s the problem with OptimizePress…

To support the look and feel of any OptimizePress page, there are a bunch of stylesheet (CSS) and javascript files which have to be pulled into the theme. OptimizePress pulls those things in by hooking into the header section of the blog. If you view the HTML source code of the page, you’ll see a number of OptimizePress CSS and JS files being pulled in.

Problem is, they’re even being pulled in if you’re not even using OptimizePress on that particular page.

It is completely unnecessary to load in all the overhead of the OptimizePress plug-in on a page which isn’t even using OptimizePress styling.

And this same thing happens with other plug-ins, too. Most plug-in developers don’t know where you’re going to be using their plug-in, so they will dump any support files (CSS and JS) into your common site header. And there they are… being pulled in whether they’re needed or not.

Needless server processing. Needless bulk to the blog. And it slows things down… for no reason.

How To Enable or Disable Plug-ins On A Per-Page Basis

I was getting really close to dumping OptimizePress. Not because I didn’t like it (I actually think it is an incredible platform), but because I was weighing out the excess overhead of all those support files being pulled in on the other 99% of pages on this blog where I wasn’t using OptimizePress.

But, then I found a solution via a Facebook conversation.

It is called, simply, Plugin Organizer.

It seems to be a little heralded plug-in kinda buried in the plug-in directory… but honestly, I wish this was functionality they had baked right in.

It does this:

  • Change the order that your plug-ins are loaded.
  • Enable or disable plug-ins based on post type or URL matching.
  • Group plug-ins together and enable or disable them collectively.

What you’ll get is an interface like this:

plugin-organizer

You’ll get this so you can set global rules, then you’ll have it on each post and page so you can set up custom settings for each one.

For instance, as you can see in the above screenshot, I have OptimizePress disabled by default. However, on any page where I am using OptimizePress (on a sales page, for instance), I simply turn it back on. And like magic, OptimizePress works fully just like it is supposed to.

It could be used for any other plug-in which tends to load stuff into your site even when it isn’t necessary.

It could also be used to resolve plug-in conflicts on certain pages.

While I hesitate to say this, in theory I don’t see why you couldn’t run 7o+ plug-ins on your blog and have things still function fine… if you’re using Plugin Organizer effectively. Especially if you have solid web hosting for your blog.

Plugin Organizer is completely free – and it’s a great solution if you’re trying to increase your blog’s performance without sacrificing some of those plug-ins you love.

Now, as much as this plug-in is a great tool in your blog performance arsenal, it doesn’t make up for crappy hosting. If you’re hosting your blog on a crappy host where your blog isn’t allocated very much horsepower with which to run, this plug-in isn’t going to magically save you. It’ll help, but it isn’t a cure-all.

I host this blog on WPEngine. These guys specialize in WordPress hosting and they tweak the bejeezus out of their systems so that your blog will be snappy. And you don’t have to worry about any of the geekery usually involved with WordPress performance tweaking… because they just have it all baked in. Couple WPEngine with Plugin Organizer and your blog will be definitely fast enough to fuel your business.

Either way, if you’re going to use a big beefy plug-in like OptimizePress, DEFINITELY use Plugin Organizer.

Comments on A Simple Solution To Running Lots Of WordPress Plugins Without Sacrificing Blog Performance

  1. Steven Davis says:

    Huge thank you! Hadn’t heard of this plugin.

    I was just talking with a colleague about how I wished WordPress would static content at runtime from pages that need to be live.

    1. David Risley says:

      Well, if you run caching, it is essentially the same thing as a static page delivery. Not totally, but close enough for most people. 🙂

  2. Nice share, David.

    I am the developer of the plugin WP Performance Score Booster which helps to speed-up page load times and improve performance scores in services like PageSpeed, YSlow, Pingdom and GTmetrix.

  3. Asif says:

    Great find,
    There are so many great plugins available to enhance the blog function but on the cost of the blog speed, this will help for sure.
    Thanks David.

  4. PJ Brunet says:

    There’s a lot of bad advice out there. People say PHP is slow but PHP is rarely the bottleneck unless the code is outrageously bad. Almost always the bottleneck is MySQL: the number of database queries, the complexity of the queries, can the queries be cached, does the database have enough memory? Likewise, almost always your run-of-the-mill web host will oversell MySQL. But every scenario is unique. Many plugin authors do not have experience designing efficient queries and efficient algorithms to make those efficient queries. That’s not even a problem till a blog starts to scale. They just never anticipated you would have 10,000 categories or a million posts, etc.

    1. David Risley says:

      That’s true. There are a lot of factors that go into blog performance, and a lot of it has to do with server setup as well as how well plug-in authors code. Some coding is just clumsy.

      I’ve not heard the claim that PHP is slow. Its actually pretty fast, and so is MySQL. But, crap code will execute like crap, regardless of the language. 🙂

  5. Amit Ahuja says:

    That’s pretty helpful and simple to implement.I always had a mess of plugins that look weird at that plugin root. I also read one of your post to promote the new blog which was a good read.
    David, I really appreciate the way you are writing with a clean interface and impressive.

  6. it is imp that wordpress would be static content at runtime from pages that need to be live. it can help load our page faster.

  7. Alessio Blog says:

    Hello David,
    I was undecided whether to make a blog in wordpress but after this article I decided and started its construction.

    Thank You,
    surely follow your future articles!

    Greetings from Italy

    Alessio

    1. David Risley says:

      Yeah, WordPress has a lot of flexibility. And, love Italy. 🙂

  8. I actually quit using OP2 for that very reason. I have all my stuff on ClickFunnels now, however, this is a great find. Thanks bro.

  9. Erron says:

    The only problem I can see with this is that you might not know every page you needed the plug-ins code on. I know I wouldn’t, not without doing a fair bit of research.

    1. David Risley says:

      Yeah, but you probably only need to use it for the “big” plugins that carry a heavy footprint. For instance, I keep OptimizePress turned off globally and only enable it when I create a page which uses it. Or, you can control things by post type, so for instance, I have WP Courseware disabled on all of my blog posts (which saves several support files from being loaded up).

  10. Siddaiah says:

    Hi David,

    I use a lot of plugins on my WordPress blog, sometimes I feel I am using a lot and delete some of the plugins, every month it happens to me.

    Whenever I read some good information about one plugin I will install it on my blog, later I will delete it because it is slowing my blog.

    This Plugin Organizer is looking very useful to me, I will try it on my blog to increase my blog speed without compromising on plugins, thank you very much for sharing such an informative post

  11. Bill says:

    Thanks so much David. I am always struggling with functionality vs. speed and I think that the plugin organizer will help a lot. I also use OptimizePress as a plugin and this should help

Leave a Reply

Your email address will not be published. Required fields are marked *