Determining Which Plugins Are Slowing Your Site Down

Dave Clements of shared his experience with a plugin that’s new to me called P3 Plugin Performance Profiler. After performing an automatic scan on the WPTavern website, the profiler provided me a pie chart along with other metrics that allowed me to easily tell which plugins were capable of slowing the site down. Here are some of the metrics after running the scan on

The scan consisted of 15 random page visits. I have 25 Active Plugins. Those plugins accounted for 51% of the page load time. There was an average of 38 MySQL queries per visit. The plugin load time was 0.233 seconds per visit. Within this scan, Ajax Edit Comments was the slowest plugin out of the bunch at 21% and 0.0491 seconds while Yet Another Related Posts Plugin took second place with 17% and 0.0408 seconds. Meanwhile, Woopra consistently was within the top three for slowest performers.

P3 Profile Scan

After the scan is completed, you have a few different options of drilling into the data. The detailed breakdown tab will show you a bar chart that displays the worst offenders. There are other means of figuring out the data as well such as viewing the simple timeline tab or the advanced metrics tab.

Here are the advanced metrics for the scan I performed at 6 A.M. this morning.

At the time this scan was conducted, it took less than 1 second to load the entire website. Plugins only accounted for 0.2331 seconds on average. I’m sure I could figure out how to decrease that amount of time but when the numbers are this small, is it worth the trouble to shrink them anymore? Perhaps on a grand scale but for the average website? Also, what do you think of the number for “Number of plugin function calls: 4,835 average“. Does that seem like a lot to you?

I couldn’t help but notice the GoDaddy image at the bottom of the plugin screen. Sure enough, they were one of the contributors behind this plugin so I give them props for doing something legitimately cool with WordPress. I recommend running a number of auto scans during a 7 day period at different times of the day to get a good feel for which plugins are really the culprits for slowing down your site. After that, it’s your call on whether you want a faster website, or the functionality that the plugin provides.

Thanks Dave for the hat tip.


23 responses to “Determining Which Plugins Are Slowing Your Site Down”

  1. I was curious whether there would be any issues running it on a localhost, but there weren’t.

    I have 29 plugins on at the moment. P3 itself took almost half the runtime.

    It is [ahem] instructive to compare my ‘dirt-bag’ desktop localhost server performance numbers to the professional server resources that WPTavern runs on. I had been wondering if it might be worth buying a new if modest-end server-configured box … looks like it’s time to move on to piggy-bank assault & battery operations now.

  2. Also, what do you think of the number for “Number of plugin function calls: 4,835 average“. Does that seem like a lot to you?

    Every value in the WPTavern Advanced Metrics reports is labeled “avg.“. So is every value for my home-box server … tho my base performance numbers are 10-20 times slower.

    Curiously, my Theme Load Time pushes 10 times faster (2011 Child w Dark out-call). My Number of Plugin Function Calls is 1/4th. I suspect my plugin inventory is mostly pretty low-ball stuff, compared to what WPTavern is running.

  3. This is potentially useful, but only partial information. This plugin measures page generation time (or more specifically, page generation time attributable to plugins, mostly). That is very different than page load time, or what a user on your site will experience. This alone isn’t a bad thing, but it does mean that you can’t assume a direct relationship between what the profiler plugin tells you is slow and what is slowing down your site.

    To take an extreme example, a script could very quickly load huge static assets. The time to generate the page could be low while the time (for your user) to load the page could be quite high. Here’s an example of a totally useless, very slow plugin that the profiler would not do a good job of measuring: (DO NOT INSTALL THIS ON A REAL SITE YOU CARE ABOUT).

    If you install that, the profiler will think it’s very fast, and it’s sort of correct because the server can process all the code in that plugin nearly instantly. But it will make your site unusably slow because your users will need to download megabytes of images and wait for useless javascript.

    This doesn’t mean that the profiler plugin does’t work, or even that it doesn’t do a good job, but it’s important to understand what it actually does, which is only partially-related to how fast people think your site is.

  4. Useful!
    Worst culprit GD Star rating – 30% of total time (no surprises)
    Followed by Permalink Editor (19% – could probably do some .htaccess rewrite rules and dispense with this one) followed by
    Quick Cache at 12% (hmmm) and JetPack (11%)
    Will be interesting to see results for client’s and my other wordpress sites.
    No GoDaddy links – yet!

  5. @Michael

    Unlike others I think it’s a shame that elephant murdering Go Daddy is sponsoring the plugin.

    Ok … let’s take a look at why GoDaddy would decide to get into the plugin game.

    Maybe because they hate Freedom, and want to choke off all that Free Expression people are doing on the Internet? Why might they want to do that? Perhaps because they are in the business of selling connection to and bandwidth for unfettered expression on the Internet … and have an inexplicable need to damage their own interests?

    Put into plain words, that doesn’t sound too likely.

    How about, GoDaddy is in the web-hosting business and (uh-oh), they monitor the loads their clients are subjecting their servers to; they see people putting these WordPress websites online, loading them to the gunwales with keen plugins (until, literally, folks at home can see their blog slowing the entire GoDaddy server-farm to a crawl) … and they figure that maybe by handing out tools for measuring the loads imposed by plugins, and fostering an interest in the topic of load-monitoring, they might contribute to … yeah, their own interests as a web server rental business.

    Just spelled right out like that, it sounds kind of obvious.

  6. This seem to be a very cool piece of apps. It just goes to say no matter how big you are you sometime become vulnerable. I suppose this is a way to ensure that the many site that GoDaddy host does not unduly over burden their servers at the same time keeping them in the loop

  7. I tried the plugin out.

    The only plugin that stood out from the rest was Gravity Forms. Interestingly, I’m also running the Grunion Contact Form plugin on the same site, and it wasn’t even shown in the pie graph alongside the giant wedge for Gravity Forms. So I guess if you want optimal performance then use Grunion, not Gravity Forms …. well, assuming the plugin is measuring things accurately, which it may or may not be.

  8. @drew – Yep. Found the same on the site I tested. Expect it to be the same on the others. Way heavy, with YARPP coming in a distant second, but it is in spikes on the timelines. Still getting my head around those different reports and what they actually mean for real performance.

  9. Out of a total of 20 plugins (including YARP, GravityForms, Syntax HLE, WordPress SEO), W3TC ranked #1 by a long-shot, weighing it at nearly 74% on every test I ran. For comparison, I installed WPSC to see how big the difference would be and it came in at only 7%.

    Not sure how accurate the details are, as I’ve not really dove into the plugin or done much more than the basic test, but that’s a pretty heavy hit from such popular plugin versus such a light hit from one that’s equally popular. I know W3TC has a little bit more integrated with the minification, CDN, etc, though still, does that really make up the 67% difference?

  10. Potential Issue with P3 Profiler

    I install plugins that seem interesting, play with them for awhile, and then move them to a /plugins-archive directory. I regularly rename directories, and Update my archive.

    Recently, I butter-fingered the clean-out operation. Normally, I Deactivate All Plugins, log out, move plugin subdirectories between directories as desired, log back in, and Activate All Plugins. In the midst of the routine, I ‘spaced out’ and performed a spurious Deactivate Plugins, while they were all deactivated.

    Next thing I know, I have a white screen, bearing the message:

    Warning: Unknown: failed to open stream: No such file or directory in Unknown on line 0

    Fatal error: Unknown: Failed opening required ‘C:\wamp\www\wp3\wp-content\plugins\p3-profiler\start-profile.php’ (include_path=’.;C:\php5\pear’) in Unknown on line 0

    I then could not bring up my site at all, getting only the white-screen msg.

    Research yields references to (among other things) the .htaccess file. That’s an easy thing to check (on my WAMP Server localhost), esp. since I do nothing with htaccess. Oh – it contains:

    # BEGIN p3-profiler
    php_value auto_prepend_file “C:\wamp\www\wp3\wp-content\plugins\p3-profiler\start-profile.php”
    # END p3-profiler

    Just those 3 lines in htaccess. After deleting them my page came up normally, no errror msg, and I logged into Admin ok. Everything appears to be fine.

    If this incident seems of interest or importance, I will try to recreate/document it.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: