Points to consider before installing a new wordpress plugin

Installing a new plugin is very easy in wordpress. All you need to do is to search for your plugin, select it, install and activate. If you do not find it suitable to your needs, just deactivate, delete it and move on.

However not many people realise what a plugin does in the background once it gets activated and assume that once a plugin is deleted its all gone which is really not true in most cases. A deleted plugin mostly leaves quite a few traces in your system. Depending upon the plugin these traces can severely affect the performance of your system if you try too many plugins without checking what it does in the background

Many plugin developers do not follow WordPress coding standards. They do not provide an unintall function for the plugin. This means you need to manually clean up all the traces of the plugin after it is deactivated and deleted.

I am currently not experiencing any performance issue with my site

Although your site may be performing well currently, if you do not consider cleaning your system then soon a badly developed plugin can cause wordpress queries to slow down. Once the system starts slowing down it will be difficult to clean the system as by then you won’t be sure which tables are currently in use and which records in the database are unnecessary as it is quite easy to forget which plugins you tried in the past.

e.g. Some plugins developers are not quite efficient in their coding. They save each setting as a separate row in the wp_options table. Ideally all settings could be stored in a single row if setting are stored in an array. I remember a plugin which created 300 rows in the wp_options table to store settings with autoload set to yes which means the rows get selected on every Dashboard page load.

WordPress gets all the rows on each Dashboard page. If the table size grows bigger it will definately slow down the sytem.

Points to consider before installing a new wordpress plugin

First of all Install, activate and configure the plugin on your test environment or localhost

Check the source code both on Dashboard and your website: Check how many CSS and JS calls the plugin is making, whether it adds any inline CSS and other extra code.

Some plugins developers do this quite efficiently. They provide a settings screen and ask you on which Posts Types you want the plugin to run which means plugin related CSS or JS files only appear on those Post Types.

Are the queries optimised: Check if your new plugin is executing any queries which can slow down your system. To monitor such slow queries make use of Query Monitor plugin. Here are some examples how to make use of Query Monitor plugin to increase performance of your WordPress site and to detect slow queries hampering your system.

Does it create new tables: Check if the plugin creates any new tables. If yes make a note of those tables somewhere. Check what data it adds to those tables and if the tables are really necessary or the plugin developer could have used WordPress inbuit tables. This will give you an idea if the plugin developer has thought about optimising the code. Additional tables are ok but to use wordpress inbuilt tables would be ideal as wordpress has already optimised queries for those tables.

If you have a multisite, most probably the plugin would create extra tables for all your sites.

What does it add to wp_options table: Some plugin authors add _tansient records to this table. e.g. a plugin used for related links would add related links for each post in this table. So for 20k posts there would be 20k records in this table. These records get selected on every dashboard page load. This would slow down the dashboard to a great extent.

wp_options table is generally used to store plugin settings. Some plugin authors store each setting in a separate row. Ideally all settings should be stored in a single row in an arrow form.

Does the plugin provide an uninstall function: A good plugin developer provides an uninstall function which deletes the tables, capabilities, entries in wp_option table etc once the plugin is deactivated.

 

How to tackle WordPress slow queries

How to tackle WordPress slow queries

859241997_aaa015e54c_z
Photo credit – elisfanclub859241997

Here are some wordpress slow queries i.e. queries which take more than 0.05s. It really depends on your wordpress site i.e. how big is the database, plugins and your site configuration. However if you are facing performance issues related to the Dashboard then it is more likely to be due to the slow wordpress dashboard queries.

Query Monitor is good plugin to check/analyse your slow queries.

Some WordPress Slow queries

Below query auto populates the custom fields drop down box.

For large tables this query can take lot of time like 2secs or so. If you do not need custom fields it is very easy to turn them off using below function.

For more information read this interesting post on CSS Tricks

Below query runs on every Dashboard page so it is important that your wp_options table is optimised.

Depending upon the plugins you have installed, the wp_options table size can grow rapidly. Some plugins use this table to store _transient options. These _transient options are objects stored in cache. For e.g. a plugin called as Manual Related Posts stores related links per post in separate rows as _transient options. So if you have 50K posts there would be 50K rows in this table. The size of the table can also grow rapidly because each row would atleast be 1M in size.

The table structure is also not optimised properly for e.g. option_id column is defined as bigint type, autoload is set to var. It should have been set as boolean or enum. Depending upon the table size and other configurations it can even take 8secs to run above query which is quite alarming.

Few tips to optimize wp_options table

  1. Check for _transient entries and if possible replace the plugins which create lot of _transient entries. Please note that although the purpose of these entries is for caching, since this table runs crucial queries on all Dashboard pages, it defeats the purpose for large wordpress installations. The table structure also does not help the cause.
  2. If it is not possible to replace the plugins creating lot of _transient entries then use the Transient Cleaner plugin which will delete the expired transient entries and will automatically do the housekeeping for you.
  3. Change the table structure a bit. Add autoload column to the list of indexes, change the option_id to int (12)