Plugin audit · Beginner · 5 min each
How to install WordPress plugins safely — Every Plugin Is Code on the Request Path
You need the feature, and you need to know what it costs on every request before it becomes something nobody dares remove.
The short answer
Activate one plugin at a time and re-measure between each. Take TTFB, the query count from Query Monitor and the size of your autoloaded options before you start, then again after every activation. A plugin whose cost you measured is a plugin you can argue about later.
Vetting comes first and takes two minutes: last updated date, tested-up-to version, the ratio of open support threads to installs, and whether the changelog shows real maintenance or a version bump. Abandoned code is the risk, and those four fields predict it better than the star rating does.
By the HostingFast team · Reviewed 24 August 2026
Beginner
Skill floor
5
Stages start to end
Free
Support, every tier
Proven
Run on the live stack
You need dashboard access, and Query Monitor installed as your measurement tool. Five minutes per plugin if you actually measure, which is the whole point.
Everything here is reversible — deactivate and delete — with the caveat that most plugins leave their database rows behind. That is covered below rather than discovered later.
Four fields that predict abandonment
On the plugin's directory page, look at the last updated date, the tested-up-to WordPress version, the support forum's resolved-versus-open ratio, and the changelog. A plugin last updated eighteen months ago against a WordPress version two majors behind is code you are adopting, not software you are installing.
Active installs matter less than people think. A plugin with fifty thousand installs and an absent author is a bigger liability than one with two thousand installs and a maintainer who answers threads, because the first one will break on a PHP upgrade and nobody will fix it.
Where plugins actually cost you
Three places, and none of them is disk space. The autoloaded options table is loaded in full on every single request, so a plugin writing large serialised blobs there taxes every page view — check it with SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'. Anything much past a few hundred kilobytes deserves investigation.
The second is queries: Query Monitor shows you the count, the slowest ones and which plugin fired them. The third is admin-ajax and WP-Cron. A plugin polling admin-ajax every thirty seconds costs you a full PHP request per poll per open tab, and none of it appears in a front-end speed test.
One at a time, with a measurement between each
Activating six plugins and then noticing the site is slower tells you nothing about which one did it. Activate, measure, record, move on. It feels pedantic for about ten minutes and then it saves you an afternoon of bisecting under pressure.
On the Nitro tiers, PHP X-Ray on CloudLinux Pro will point at the slow function rather than making you infer it, which turns this from detective work into reading. Wherever you are, the discipline is the same: one change, one measurement.
The cull, and what deactivation leaves behind
Go through the roster every few months and remove anything you cannot describe a current use for. Deactivating stops the code running; deleting removes the files. Neither removes the plugin's tables, its autoloaded options or its scheduled cron events, which is why a long-lived site accumulates weight nobody can account for.
So after deleting, check wp_options for orphaned rows with the plugin's prefix, look at wp cron event list for orphaned schedules, and re-measure. A cull that does not reduce a number was not a cull, it was tidying.
Fast platforms make for short guides
Every walkthrough here is run against the platform we operate — cPanel, LiteSpeed in front of NVMe, Softaculous, WP-CLI over SSH — so the field names in the instructions are the field names on your screen.
Every plan includes an SSL certificate that reissues itself before expiry, so the padlock is never something you have to diarise.
- One activation, one measurement, in order
- Autoload size and query count named
- Deactivation debris cleared, not ignored
- Engineers on support at any hour
Why HostingFast
Standard on every plan
Cost measured, not guessed
TTFB, query count and autoload size give you three numbers per plugin, so a decision to keep it is evidence rather than habit.
Abandonment predicted
Four fields on the directory page tell you more about future breakage than the star rating ever will, and the page names them.
The real costs located
Autoloaded options, query count and admin-ajax polling are where plugins are expensive, and none of them shows up in a front-end test.
5 steps, no padding
Five actions, each producing a number, and the discipline of one activation at a time made explicit.
Debris cleared
The page covers what deactivation and deletion leave behind, which is why long-lived installs get heavy without anyone adding anything.
Engineers on call
If a plugin takes the site down at an inconvenient hour, support answers and can get you back to a working state.
Quick Start
From order to online
- 1
Take the baseline: TTFB, queries and autoload size
Record the median of five curl runs for time to first byte, the query count from Query Monitor on a typical page, and SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'. Three numbers, thirty seconds, and every later decision refers back to them.
- 2
Vet the candidate on four fields
Last updated date, tested-up-to version, open-to-resolved ratio in the support forum, and whether the changelog shows maintenance or version bumps. Fail any of them badly and stop; there is usually a maintained alternative.
- 3
Install from the dashboard, never from a zip somebody sent you
Search and install from within WordPress so updates arrive through the normal channel. A zip from an email or a forum has no update path and no provenance, and it is the standard delivery mechanism for a backdoor.
- 4
Activate one, configure it, then re-measure
Activate a single plugin, work through its settings immediately while you still know why you installed it, then take the same three measurements again and note the delta. Only then move to the next one.
- 5
Cull quarterly, then clear what it left
Delete anything you cannot justify, then check wp_options for orphaned rows carrying its prefix and wp cron event list for orphaned schedules. Re-measure afterwards; if no number moved, the plugin was not the problem.
Built In
Loaded onto every plan
- Staging environments for testing before you ship
- Daily backups with self-service restores from the panel
- SSH with Git and Composer on the developer plans
- WordPress Toolkit, with updates applied for you
- Per-site PHP version switching in the control panel
- LiteSpeed caching in the server, not bolted on by plugin
- NVMe storage on every tier, not only the expensive ones
- Support staffed by humans, every hour of the day
- Money back: 30 days on hosting, 7 on reseller
- A renewal price identical to the one you signed up at
Frequently Asked
What people ask us most often
How do I find which plugin is slowing the site down?
Query Monitor is the first stop: it attributes queries, hooks and HTTP requests to the plugin that fired them, on the actual page you are looking at. If that is not conclusive, bisect — deactivate half, measure, repeat — which is quick if you already have a baseline. On the Nitro tiers, PHP X-Ray on CloudLinux Pro traces the slow function directly and removes the guesswork.
Does deactivating a plugin remove its database rows?
No, and neither does deleting it in most cases. Uninstall routines are optional and many authors do not write one, so tables, autoloaded options and scheduled cron events survive. That is how a five-year-old install ends up with an autoload payload nobody can explain. After deleting, search wp_options for the plugin's prefix and check wp cron event list for orphaned schedules.
Is a large autoloaded options table genuinely a problem?
Yes, because autoloaded options are read in full on every request, including AJAX calls and cron runs, whether the page needs them or not. Run SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes' and then look at the largest individual rows. Plugins caching serialised data there are the usual culprits, and moving that data out or flipping the rows to autoload off is often the single cheapest win on an old site.
Is the plugin count a useful number at all?
Not on its own, no. Twenty small, well-written plugins can cost less on every request than one that loads a framework and polls admin-ajax in the background. The numbers that carry information are TTFB, query count and autoload size, because those are what a visitor actually pays. If a plugin cannot be shown to cost any of the three and it does something you need, its existence is not the problem.
Keep reading
How to Speed Up WordPress
Measure, change one thing, measure again — the loop that separates a real gain from a moved score.
How to Clean Up the WordPress Database
Clear the autoloaded rows, transients and revisions that a long-lived install accumulates.
Best Wix vs WordPress
A hosted builder against self-hosted WordPress, compared on control, cost and what you can measure.
Dedicated Servers
Dedicated servers when the workload has outgrown a shared account entirely.
WordPress Hosting
Managed WordPress on NVMe with LiteSpeed in front and Redis object caching available.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Run the plugins on faster hardware.
NVMe behind a LiteSpeed cache, staging copies for testing, free SSL and migration, and a price that never moves on you.
View WordPress Hosting plans