I was recently asked how I judge the performance and relative “weight” of plugins when I am testing them for Tidy Repo. I wish I had a one stop solution for determining this, but it’s a little more complex than that—so I thought I might detail my process here.
General Testing Setup
For my local dev environment I use Vagrant, and 10up’s wonderful Varying Vagrant Vagrants box. This works for most plugins, but some need to be on a live install for one reason or another, so I have a site set up on my server as well. These are kept at the latest stable version of WordPress, and are set to debug mode. Often when a plugin is first installed, this will throw up a couple of errors, but I’ll get to that a little later.
I use WP Test to populate the install with content. WP Test creates multiple users, a bunch of posts, galleries, images and lots and lots of fringe cases (long titles, awkward menus, etc.), which helps with testing plugins out in the wild, in a variety of situations.
I also run P3 Plugin Profiler whenever I install a new plugin. This gives me an overview of just how much time the plugin drains from both the back-end and front-end loading times of these sites. Of course it’s just a guideline and every plugin needs to be taken in context, but if I find a plugin is really dragging a site down, it usually doesn’t make the cut.
From there, I evaluate plugins based on their functionality. In general, this breaks down into two categories: the Front-End and the Back-End.
Evaluating the Front-End
“Weight,” in this scenario, is determined by how much is actually added to the front-end, whether or not that is worth it, and if it is done responsibly. I use Helpful Information and Debug Bar in order to check front-end output. Let me break this down a bit.
wp_enqueue_script instead of injecting it in the header or footer. I also like to check that variables and class names are prefixed or specific to the plugin so as not to conflict with other classes. And most importantly, scripts should be conditionally loaded on pages where they are required and only on these pages. When testing plugins, I will visit a page that does not rely on the plugin at all to check this.
Evaluating the Back-End
On the back-end, things are a little different. Performance means something different when it comes to server-side code. This can mean admin plugins like custom fields, white labels, or tools. However, this can also include server-side plugins like search enhancements, user areas, or shortcode generators. There are really two things that I look for here: proper use of the WordPress API and a functional, structured code.
Right off the bat, WordPress debug mode can throw up a few red flags. It will tell me if the plugin is not following PHP strict standards, or if there is a stray undefined variable. If I run into a Notice or Warning, I will check up on it in the code base. It could just be a small error that conflicts with the requirements of the most recent version of PHP, which WordPress now requires. But if I get an error, that usually means something is wrong with the plugin that needs fixing.
Next up, I make sure that a plugin uses the WordPress API correctly. Does it ever use the global $post object? If it does, it better have a good reason. Does it use enqueue functions to bring in external files? Does it use filters and hooks to modify front-end output instead of straight injection? WordPress provides functions for just about any use-case, so make sure that a plugin is taking full advantage. And this isn’t just a semantic concern. If WordPress functions aren’t used properly, it can cause major conflicts with other plugins and themes, and break caching, or cause major performance problems with unwieldy queries.
If a plugin exists entirely in the admin panel, and has no effect on front-end output, you will still want to make sure that it makes proper use of the WordPress API, but you also want to make sure that the admin set-up is functional. Does it take advantage of custom post types to organize its posts? Does it use a familiar look and feel that mirrors the existing WordPress admin? Does it use the default media uploader when dealing with uploads? Does it use filter and hooks to modify admin output? Though these won’t have a noticeable effect on the performance of your site, they can severely slow down how you interact with a plugin, so keep your eye out for that.
This might all sound like a lot, but most plugin developers are well within these bounds. There are, of course, no hard and fast rules here, but attention to detail is paramount. If you have experience with PHP development, it’s easy to spot these problems. If you are wondering how a plugin should be set up, you can always take a look at Tom McFarlin’s plugin boilerplate for a great example of how plugin code should be structured.
Keep in mind, many plugins will have a healthy mix of front-end and back-end functionality. Make sure to check a plugin all the way through to ensure that it is doing the responsible thing. And if a plugin is affecting your theme, make sure to evaluate it in context. In other words, don’t just check how much weight a plugin is adding, check that a plugin is adding weight that matters.
How do you judge the weight and performance of your plugins?
Jay Hoffmann is a WordPress developer hailing from NYC. In the strictest sense of the word, he is a WordPress enthusiast with an eye for front-end development and design. He has been working with WordPress since 2006 and currently works for a popular children’s media company. This year, Jay started Tidy Repo, a curated list of the best and most reliable plugins from around the web. You can also follow Jay on Twitter.