The best and worst thing about self-hosted WordPress is that you can install any plugin you like.
Having worked with WordPress functionality for over five years, I have seen all sorts of use and abuse with plugins on sites large and small. Plugins should be selected carefully to ensure security and resources are optimal for any given site. Performance problems are destructive to any site.
Choose the right plugins for the job
What makes a plugin’s features and functions acceptable? There is no standard answer. This threshold is in the minds of the administrators with their personal experiences, requirements, and budgets. Acceptability notwithstanding, there are standards to determine whether a plugin operates optimally for what it does, including the following:
- Minimize features to just what is required
- Minimize memory and CPU usage and database queries
- Minimize PHP notices and warnings that can clog up log files
- Minimize serialization of larger data objects, set these to autoload=no
- Enqueue javascript libraries so that they do not load extras already included by the theme or other plugins
- Self cache data for reasonable periods, giving the developer control over caching thresholds rather than forcing it with caching plugins
- Replace basic plugins with custom content types/toolkits where content can actually represent what may otherwise require functionality to construct, even without caching plugins
- Choose products that are actively maintained and supported by the community or developer(s), because problems will arise and they should be vetted and dealt with head-on
Understand the roles of design, content, and functionality
You cannot tell if a plugin is good just by looking at the code, but poor-looking code can be an indication of bigger problems. Code cleanliness makes a plugin efficient to work on—akin to having a clean, roomy engine compartment in a car. Whether a plugin works well is far more difficult to determine. This begins with having ongoing and dedicated development efforts that include functional testing, in critical cases even load testing. If the plugin you are considering does not come from a source with this strong dedication, find a better plugin to add the functionality to your site.
Following the car analogy, metrics for plugin functionality performance could be compared to safety, fuel efficiency, smog, and horsepower. A car is a whole package much like a whole website. A plugin can be thought of as a single mechanical component such as the engine, transmission, or power accessory that can be tested and replaced as a unit by a qualified technician. WordPress itself can be thought of as the frame, tubing, wiring, structure, and branding of a car. The paint, vinyl, chrome, bumper stickers, user adjustments, and radio settings could represent the theme, content, and administrative settings.
It is vital to separate these areas of responsibility for plugins, themes, content, and configurations, and to police each component to ensure it doesn’t go outside of its bounds. By doing so we keep plugins manageable as individual components that operate cooperatively with one another and the selected theme. The highest quality functionality will be “built to the core”, in other words utilizing core data structures as much as possible for maximum interoperability.
Understanding environments
Plugin performance can only be measured in an environment that suits the operations taking place. With so many hosting options out there, your production environment must be carefully chosen to meet your growth needs. You also need a test environment for such experiments. This test environment should either match production or be a scaled version that leaves full-scale testing for a separate staging environment.
Another environmental issue is caching. Caching is no panacea. However, many hosts either recommend or enforce it mercilessly. Caching can prevent plugins from getting real-time data, accessing cookies, or using PHP sessions. Caching can improve performance under a load using a variety of techniques that minimize server operations, but with the cost of low traffic degradation and compatibility problems. One cannot make good PHP logic when that logic is usurped by a caching engine. I recommend testing with specific caching configurations off and then on to compare the differences with the same user journey. With good plugins installed you may be better off without most forms of caching enforcement. Caching can oftentimes cover a mess without cleaning things up. Some forms of caching can be appropriate, especially in high traffic environments.
Finally, always develop and test plugins with DEBUG mode turned ON so you can see what notices, warnings, and errors get thrown by PHP during functional testing. Normally programmers test with DEBUG mode ON and testers typically test a system like a user with DEBUG mode OFF to catch potential problems from either vantage.
Pre-launch qualification
One approach that we like in determining if a plugin is problematic is when you activate it you notice a slowdown in the administrative area or the front end of your site. This may indicate excessive database queries or slow queries. It can also indicate that the plugin hooks into inefficient triggers. A popular plugin called Plugin Performance Profiler can help provide some high-level analysis.
Test each major operation of the plugin that is important to you, following all user stories that make sense for your audience. It’s a good idea to follow this up with negative testing to ensure the plugin manages invalid inputs in a user-friendly fashion. Ask yourself whether the functions will make sense to your audience, or whether it would be expecting people to fill in blanks on their own.
Load testing is necessary whenever you expect traffic spikes. Performance can vary dramatically when you have multiple users stacked on top of one another, especially when the server resources do not support real-time scaling. Shared hosts often times throttle processes that push memory and CPU resources in order for them to maintain a larger grid of low-cost accounts. VPS servers have fixed resource settings that normally work very well up to a medium point. Cloud environments can be made to scale pooled resources according to real-time requests.
With load testing one can conclude whether an acceptable amount of traffic faces an acceptable amount of waiting times without crashing the given server resources. With more advanced tools this practice can help developers and system administrators pinpoint problem areas in the code or server configurations for adjustments and retesting.
Post-launch monitoring
After plugin code is launched one cannot play around with the production code itself. The production environment though does offer far more log data than you could ever hope to simulate on a test site. It is important to run diagnostic utilities in production to track problems that visitors do and don’t complain about as they do things you didn’t anticipate.
Having monitoring tools is extremely useful to track database tuning, slow queries, memory, CPU, file system and other resources. I often hear about the tools: NewRelic, Longview, and Munin. The SSH command line itself offers resource monitoring if you need to keep things extra simple.
Custom-built plugins
A custom plugin is required when there is nothing in the market that meets your requirements, quality standards or budget. Often times these are highly specific business rules or API integrations that haven’t yet been introduced into the WordPress ecosystem.
A custom plugin should not itself become a monster, rather be broken into modular, roughly single value pieces. Plugins may include internal templates but should rely on one’s theme, theme framework, CSS override, or child theme to apply the design. For example, back when we were building a custom integration plugin for one of our clients, instead of allowing the plugin to grow too large, we broke the project into a core plugin, a developer tools plugin, a library plugin, sever user interface plugins, and templating plugins. That project grew into our Association Engine suite of plugins.
There are risks with building a custom plugin. It can be difficult to plan, build, and support if you are not prepared. Relying on one individual developer can also be a problem. So can launching code that isn’t properly tested or vetted. Thus, critical applications requiring custom plugins should only have them built by seasoned professional developers.
Conclusions
One must choose their plugins carefully to ensure optimal security, performance, and user experience. I have provided some guidelines to choose, build, test, and monitor your plugins. I have also provided advice about server environments, caching, functional testing, load testing, monitoring and custom building. Since there is so much that goes into vetting plugins, please do not let this difficulty cause you to compromise beyond your level of comfort. You may be better off waiting for a quality plugin than launching faulty functionality on your site!