WordPress is the dominate player among content management systems powering websites large and small in 2019. WordPress enjoys over 10 times the market share of its nearest competitor with over half a billion websites running WordPress. It has grown to this position since its inception in 2003 because it is very easy to learn, easy to implement and easy to extend. It allows anyone to setup a website in a few minutes with respectable SEO out of the box. Plus an ever-growing catalog of plugins from Automattic, the company behind WordPress, and other third parties provide just about any functionality a website could possibly need. Many of these plugins are free or modestly priced. With its famous 5-minute install, WordPress is incredibly easy to setup. You can get started, learn the basics and have a functioning site in less than an hour.
Agencies and independent web designers like WordPress because WordPress allows the creation of unique sites including web commerce, forums, content delivery behind pay walls, etc. When most people think of WordPress they think blogging and it is an awesome blogging platform but because it is a platform and a framework it offers so much more than just blogging.
The dark side of that power is it’s also very easy to end up with a bloated and under-performing site.
If you have an under-performing site running WordPress, I can almost guarantee you I know what is dragging it down without ever even visiting your site, looking at your Google Analytics data or even logging into your admin dashboard. One or more plugins are not playing nicely, and your site and its SEO score are paying the price.
Sure, there are other possible performance bottlenecks but assuming you aren’t running on under-powered hardware or an over-sold shared hosting environment, using a really bad theme or still trying to limp along on some version of PHP5 it’s an almost certainty the root cause involves a plugin or two … or more. It’s also very likely you will want to pull your hair out while trying to figure out which one or magic combination of plugins causes all the trouble.
I’ve used WordPress since it first came out in 2003 and I have spent my fair share of time of disabling all plugins and re-enabling them one by one to find out which one is the likely culprit. If you have ever faced this situation you know why I say likely because a poorly written plugin can cause other plugins to look like they are the problem. As I have learned more about the WordPress plugin architecture and how it works, I have developed a regimented process to look at new plugins for any of my sites or my clients. You can read about my process for Evaluating WordPress Plugins if you are interested. I don’t claim it is foolproof, but it works for me and definitely helps mitigate the risks associated with plugin use.
In some cases, the number of plugins used causes the trouble. Every single plugin you have activated loads during the bootstrapping of every single call to the server. This can easily cause a memory fault requiring adjustments to the PHP environment. You have no real control over the order the in which the plugins load, and they can step on each other during this loading process. You can request your hooks, filters, actions and events run ‘last’ but if more than one plugin does that on the same thing, you have no guarantee you really will be the last one to run. It is a fragile process needing the author of any non-trivial plugin to understand the plugin process inside and out.
As the complexity of a plugin increases so does the risk of conflict with other plugins and resources. It only takes one or two complex plugins, like WooCommerce, to make life difficult for any other plugins in use. As a best practice, I try to avoid multiple complex plugins running on the same site. If WooCommerce is loaded, I’d probably put the forum a client requests on a sub-domain and handle single signons between the two. It just makes things simpler, more robust, and easier to diagnose when problems arise.
I’ve written my share of plugins and it is not always easy to carry out what you need to do without affecting and being affected by all the other plugins activated on a site. Using accepted best practices certainly helps but no matter how well you plan, architect, and carefully code your plugin you are still at the mercy of every other activated plugin on the site. When I write plugins now, I try to have as little code in the actual plugin as I can. I am always on the lookout for ways to refactor and remove code from plugins I write because I want my plugins to have the smallest footprint possible to avoid causing any problems.
I do this by using WordPress for what it does best. I let WordPress handle the presentation and access control but offload all business logic and often even forms and views. For example, I have a client who has a large amount of data stored in MSSqlServer which they needed to use on their website. They moved from an ASP.NET website to WordPress but still needed to make this legacy data available to the members of their site. But they wanted the presentation of this legacy data embedded in the site. Having a user go to another site was not an option. To do this, I wrote a few very lightweight plugins to add shortcodes in WordPress. They are extremely basic and do little more than call out to an API to present a form to the user so they can search the legacy data. Then it sends another call out to the API with the search criteria. Lastly it scrubs the returning HTML before presenting it to the user. Authentication to the API is handled via JWT tokens and the API sits behind the firewall with no public access. It’s only called from the webserver within the datacenter.
Yes, I could have done this all within WordPress, but it would need a lot more code in the plugin and that additional code could drag down performance during complex searches. This way, everything is clean and well isolated. They can have hundreds or even thousands of simultaneous searches and the API, written in NodeJS can scale horizontally or vertically if needed. However, all the data to date shows we will have to worry about scaling the WordPress side long before we have any need to scale on the NodeJS side.
The take away for plugin authors is, think about how you can have the least impact on the entire system and still reach your goal. You don’t want to be the source of performance issues or the infamous white screen of death. Additionally, you want to future-proof your plugin. The less you do within the plugin itself, the less likely future changes and upgrades will affect you.
The take away for those using plugins is, don’t rely on any plugin written by a Level One author if you have any other reasonable alternative. If you are hiring someone to write a custom plugin for your site, ask them how they prevent the problems I’ve written about here. Lastly, if you hire based solely on price you are risking more than you might realize. The added costs you will pay to use a poorly written plugin can quickly mount and you could have those costs for a long time.