There are slightly less than 60,000 plugins available for download in WordPress’s official plugin directory. They are its “secret sauce” and the reason for its dominance as a CMS. Needless to say, plugins are beloved.

But they’re also a security risk and they can slow down your website. That’s why you should follow these three essential tips for using plugins in WordPress.

Some plugins merely tweak some WordPress settings, but others add completely new capabilities. They are able to do that because they’re given enormous access to your website and its data, which means they are an inherent security risk and an attractive target for hackers.

According to Sophos, about 13,000 WordPress websites are hacked every day. More importantly, according to Sucuri, 92% of those hacks were committed via outdated or poorly coded plugins. Plugins are one of the biggest vectors hackers use to try to gain access to your website.

The biggest thing you as a WordPress user can do to minimize your vulnerability to these hacks is simply to keep your plugins updated, as well as WordPress core.

Since WordPress is open source, discovered vulnerabilities are a matter of public information. That makes it very easy for a hacker to quickly write an exploit for one once a vulnerability is found. Even if the vulnerability is just as quickly patched by the plugin developer, that won’t matter for users who haven’t installed that particular update. 

If security is important to you, it is important to treat a plug-in update notification as a high priority action item. Most WordPress users think, “I’ll get around to that later.” With 2,800 attacks on WordPress every second, later may be too late.

Too many plugins aren’t just a security risk, but they can also slow down your website. This is especially true if your site runs on a shared server at a discount web hosting company. Excessive server calls or HTTP requests translate to slower page load times and lower SEO scores.

The problem is, no one can really agree on how many plugins a website should have. WordPress itself has no official stance: it doesn’t limit how many plugins a site can run. 

There appears to be consensus, however, that over 30 plugins is probably too many, and that a number to shoot for is under 20. Rather than think in those absolute terms, however, start by assessing which plugins your site needs.

Quite often, a plugin will be used for a specific purpose and for a finite period of time, and afterwards it just hangs around. For instance, a template plugin isn’t needed past the design stage of your site, so it’s a good candidate for removal.

If you perform an audit of your plugins, you will likely find additional candidates for plugins your site no longer needs.

Plugin developers want you to consider their plugin “essential”, and so they add on features just to give that impression. Audit your plugins for services your site needs, and also that you actually use, and reduce the fluff that way as well.

Also audit for multiple plugins that perform more or less the same function. Don’t just make this comparison amongst plugins, though: compare the functionality of your plugins with services your web host offers as well.

For instance, if your web host provides a good, free backup solution, there’s little reason to use a plugin that duplicates this effort. You’ll just be using up resources and slowing down your site unnecessarily. Plus, a backup solution running independently on your server will almost assuredly be better than a backup plugin running from the Cron or invoked from the WordPress backend.

Analytics is another area to look at. Your web host may be collecting analytics just as detailed as a Google Analytics plugin would. Below is a screenshot of the analytics provided by Hostinger. 

There may be other compelling reasons to have Google Analytics installed, however. 

All of the services provided by your web host can be accessed by your website’s control panel, accessible from your web host’s site. The control panel is called cPanel for most web hosts. Hostinger calls its modernized (and arguably, improved) version hPanel. 

There are so many free plugins available, and installing them is so darn easy, that no one can blame someone for overindulging from time to time. When you’re done with a plugin, though, make sure you remove it the correct way.

There are at least a couple of ways of removing a plugin: one method is to simply remove its folder, which resides in wp-content/plugins, using an FTP client like FileZilla or CyberDuck. The most common method, however, is to deactivate the plugin and then remove it via the Installed Plugins screen of the WordPress dashboard. 

The second option above seems to be the responsible plugin removal method, right? Unfortunately, neither of those methods will completely remove a plugin in most cases, because they omit one important step.

The problem is that many plugins make changes to the WordPress database in multiple locations. They add new tables and insert rows into existing tables, changes that can number in the hundreds.

When you deactivate and remove a plugin or simply delete its folder, all of those database entries remain. This is ostensibly for a good reason: if you want to reinstall the plugin in the future, those database entries mean you won’t have to reconfigure it; your original settings will have been preserved.

Over time, though, these extraneous database entries add up to detritus that can bloat your database and slow down your website. 

For instance, see the below alert from the Health Check & Troubleshooting plugin that shows how leftover database entries had bloated my website’s wp_options table far beyond the WordPress-recommended size of 800kb. This plugin “litter” slowed down every page of my website. 

This is the kind of issue that you will eventually have to deal with if you don’t delete plugins completely.

So, what is the correct way to remove a plugin? Unfortunately, it varies from plugin to plugin. However, it involves selecting an option in the plugin’s settings related to its removal and the WordPress database.

Below is this setting for the All in one SEO plugin, which reads, “Check this if you would like to remove ALL AIOSEO data upon plugin deletion. All settings and SEO data will be unrecoverable.” It is found in the plugin’s General Settings under the Advanced tab. It is turned off by default.

Below is another example of this setting, from the WP-Optimize plugin. The option, accessible via WP-Optimize | Settings in the WordPress sidebar, is a button called “Wipe Settings.” There is a notation reading, “This button will delete all of WP-Optimize’s settings. You will then need to enter all of your settings again. You can also do this before deactivating/desinstalling WP-Optimize if you wish.”

Unfortunately, there’s no standard implementation for the removal of database entries; they vary from plugin to plugin. There’s also no requirement by WordPress that plugin developers include such a setting (although there should be).

However, responsible plugin developers tend to include the option, and it’s one reason to choose All In One SEO over the equally capable Yoast SEO, which doesn’t provide the option to have it clean up after itself.

When questioned about the omission, Yoast referred me to a page on their site with instructions for the manual removal of these database entries, and suggested I submit a new feature request in their bug tracking database. Consider it done.

Ideally, WordPress would include a prompt when removing a plugin that reads, “Would you like to remove this plugin’s data as well?” That’s another worthy feature request that I will endeavor to get implemented.

Right now, though, such a WordPress prompt doesn’t exist, so users will need to hunt for an option in a plugin’s settings prior to removing it.

Since this option also doesn’t always exist, the alternative is to manually remove entries and tables from your WordPress database (always back up your database first), or use a plugin to assist with that process (WP-Optimize is a good option, and is a good candidate for removal after use in accordance with Tip #2 above).