Sometimes I take on the maintenance of existing WordPress-based websites, and obviously part of my initial work is to assess a site’s performance, stability, extent of customisation, etc. It all boils down to getting to know what I’ve taken on so that I can find the easiest ways to maintain it in the future.
One thing I often find is that a site has a very large number of plugins (20 or more), but that quite a few of them are very small and have no admin interface – that is, you just install them and they do their job. That’s fine – if only all plugins were as focussed and easy to use!
But – every plugin you add to a WordPress site will cause the site to slow down. Only a tiny bit in most cases, but the performance hit is there. For each plugin, WordPress has to find and read at least one extra file, and check the site database for settings.
Let’s think about how you can avoid a certain proportion of this performance hit.
Every WordPress theme has a file called functions.php, and the contents of this file are run each time a WordPress page is loaded. If you have some simple plugins installed (for instance, a plugin that removes certain items from the page header, or changes a post’s content in some way when the post is displayed), why not just put their code into your functions file and remove the plugin? The more plugins you can migrate to the functions file, the faster your site will be. Granted, we’re probably talking no more than 1 or 2%, but every little helps.
Two of my own plugins can easily be placed into the functions file in this way – ZigPress Clean Head and ZigPress Hide Update. Just take the entire contents of each plugin file and paste it at the end of functions.php.
Some plugins offer a slightly customised version of one of the standard WordPress widgets, or they offer new widget functionality which is nevertheless very simple. Maybe you code simple plugins yourself, and you find yourself writing lots of similar widgets that do quite simple things. If you’re into PHP a bit, one way of ditching still more plugins is to install the PHP Code Widget. This little beauty works just like the text widget, except that you can insert PHP code as well. And with careful use of the PHP global command, you can access almost any WordPress data. Ideal for widgets containing customised lists of tags, categories or posts.
With the first method, you are effectively killing all forms of update warning or process for each plugin that you put in the functions file. So think about whether this might affect your site if you upgrade to a new WordPress version. If your plugin doesn’t access the site database, it’s less likely to be a problem, but you never know.
This is less likely to be a problem with the second method, because in that case you’re probably familiar enough with PHP to figure things out if something goes wrong.
Reducing the number of plugins is of course just one way to get a WordPress site to run faster – others include reducing the number of HTTP requests, caching, and minimising the number of files that are called from remote domains. I’ll talk about those sometime soon.