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
Just to be clear, by front-end, I mean plugins that render on the pages that users actually see, meaning they edit or add to the HTML markup, CSS style sheets and Javascript files of your theme. Think sliders, comments, widgets, etc.
“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.
Oftentimes, plugins will have to load in a few external files (CSS and JavaScript) or edit existing markup. For these external files, I check to make sure they are necessary. Does the script depend on external libraries, like jQuery? Does it use these libraries to save valuable lines of code, or merely out of convenience? Is the code minified? It’s also important that the code is minified and as compact as possible. Also, I check if it is being included in a modularized way, that allows inheritance from theme styles while also being flexible enough to fit into responsive/fluid designs and across different themes.
Of course, you have to weigh this against the benefit the plugin provides. Some plugins may need a hundred lines of Javascript or more to ensure that the slider is responsive, or that the data table is sortable. Some amount of CSS layout classes may be necessary, or jQuery polyfills might be the best way to offer cross-browser support. If you find that a plugin is using a lot of code, which may be for good reason, always qualify your assumptions. I’d rather have a plugin that loads hundreds of lines of necessary code, then ten lines of useless spaghetti.
Last up, make sure that external code and markup is loaded in responsibly. This means that only one JavaScript file and one CSS file is used. Scripts should be concatenated into one file, with almost no exceptions, as multiple HTTP requests can have the biggest impact on performance. If jQuery is used, then it should load in the WordPress version using 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.
Wrap-Up
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.
7 Comments