Performance Glossary
Plugins: Measured in Milliseconds, Not Features
Thirty-two plugins are active, the site got slower over two years, and nobody can say which of them is responsible for what.
The short answer
A plugin is third-party code that runs inside your application with your application's permissions, and on WordPress every active one is loaded on every request whether the page in front of the visitor needs it or not.
That is why plugin count is a weak proxy and profiling is the real answer. Twenty light plugins can cost less than one that queries the database on every page load, and only a measurement distinguishes them.
By the HostingFast team · Reviewed 12 August 2026
100+
Terms, measured not asserted
2 min
To read one entry
Plain
Commands you can run
24/7
Engineers on shift
The marketplace is simultaneously WordPress's strongest asset and its widest attack surface. Vetting before installation and deleting what you no longer use are security work rather than housekeeping, because the code runs with your permissions either way.
Quality is wildly uneven. A plugin with a recent release and a support forum that gets replies is a feature; an abandoned one with an identical description is next year's incident with the date not yet filled in.
Profiling instead of counting
Install a query monitoring plugin on staging and load a representative page. It attributes time and query count per plugin, and the distribution is nearly always lopsided — one or two owning the bulk of the milliseconds while the rest are noise.
Take the reading on a page that matters, not the homepage. A slider plugin costs nothing on your article template and everything on the landing page it runs on, and the average across both tells you neither.
Assets loaded where they are not needed
The classic waste is a plugin enqueueing its stylesheet and script site-wide when its shortcode appears on one page. Open the Network panel on a page that does not use the feature and look for its files loading anyway — that is bytes and connections spent on nothing.
Conditional loading fixes it where the plugin supports it, and where it does not, dequeueing selectively in the theme does. Either way, re-measure afterwards: this change is easy to make and easy to make wrongly, and a missing stylesheet is more visible than a slow one.
The cost you cannot see in a page load
Some plugins are cheap on the front end and expensive elsewhere: an admin-ajax poller running every thirty seconds for every logged-in editor, a cron job importing on a five-minute schedule, a table growing by a row per page view. None of that shows up in a front-end profile.
Check the cron list and the largest tables alongside the request profile. A plugin that adds nothing to your page time while filling the database is still going to cost you, just on a longer timescale and with a less obvious cause.
Deactivating is not uninstalling
The files of a deactivated plugin are still on disk and still reachable over HTTP. A known vulnerability in one of them is exploitable whether the plugin is switched on or off, which makes 'deactivated' a state with all the risk and none of the benefit.
The rule is binary: active and needed, or deleted. Where you might want it back, keep the download, not the directory. Then verify the removal actually happened — a leftover folder under wp-content is the failure this advice exists to prevent.
Third-party code, weighed properly
Where a decision is usually made by counting things, these entries give you the measurement that replaces the count.
Staging on the plans that carry it gives you somewhere to profile without touching live, and WordPress Toolkit keeps what you do keep updated.
- Profiled per plugin, not counted
- Assets checked on pages that do not need them
- Background cost included
- Removal verified on disk
Why HostingFast
Standard on every plan
Measurement over headcount
Why the number of active plugins predicts almost nothing, and what to profile instead.
The right page to test
Profiling a page that matters rather than a homepage, because plugin cost is per-template.
Wasted assets located
Finding stylesheets and scripts loading on pages that never use the feature they belong to.
Background work counted
Cron entries, ajax pollers and growing tables — costs a front-end profile will never show you.
A binary rule on removal
Why a deactivated plugin carries its full vulnerability surface and what to do about it.
Vetting made quick
The four signals worth checking before installing, none of which take more than a minute.
Quick Start
From order to online
- 1
Profile on a page that earns
Run the query monitor on a landing page or a product page, not the homepage. Plugin cost is per-template and averages hide it.
- 2
Look for assets on the wrong pages
Open the Network panel where the feature is not used and search for the plugin's files. Anything loading there is pure waste.
- 3
Delete rather than deactivate
Remove the directory, then confirm it is gone from wp-content. A switched-off plugin is still code an attacker can reach.
Built In
Loaded onto every plan
- Staging you can clone, break and throw away before anything reaches live
- WordPress Toolkit handling core and plugin updates for you
- LiteSpeed compiled into the server, not a caching plugin bolted on afterwards
- NVMe on every tier — the entry plan runs the same drives as the top one
- PHP version selectable per site, switched from the control panel in seconds
- Daily backups with a self-service restore you run yourself from the panel
- SSH, Git and Composer on the developer-focused plans
- Free SSL on every plan, reissued automatically well before it can expire
- A human on support at any hour, including for the awkward questions
- Free migration by our own engineers, normally inside 24 hours
Frequently Asked
What people ask us most often
Is there a sensible upper limit on plugin count?
No, because the number does not predict the cost. Profile instead: load a representative page with a query monitor and read the per-plugin timings. You will usually find one or two owning most of the milliseconds and a long tail contributing almost nothing measurable.
How do I judge a plugin before installing it?
Four checks, under a minute: date of the last release, active install count, whether support threads get replies, and whether the changelog shows a pulse. Then keep it updated, because the judgement is continuous rather than a one-off at install time.
Is staging an add-on, or part of the plan?
Part of it, on the plans that carry it. Clone the live site, do the work on the clone, then push it live once it behaves. That is the whole difference between hoping an update survives contact with production and knowing it does before a visitor ever meets it.
What does support actually cover at three in the morning?
A human reply at any hour, with a scope that includes the practical jobs: DNS records, mailbox setup, a restore, a WordPress site that has stopped answering. Send a hard technical question in before you buy — the reply you get is a fair preview of the standard afterwards.
Keep reading
CMS (Content Management System)
The editing layer over your content, and what it costs per request to render.
WooCommerce
A storefront inside WordPress, and the uncacheable pages it introduces.
Best LiteSpeed Hosting
LiteSpeed hosts compared on cache behaviour rather than on the badge in the footer.
Ecommerce Hosting
Storefront hosting built around the pages a cache cannot touch: basket and checkout.
WooCommerce Hosting
Store hosting with Redis caching and headroom reserved for checkout.
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.
Profile it on a clone, then decide.
One-click staging, LiteSpeed caching, per-site PHP control and WordPress Toolkit keeping the survivors up to date.
View Ecommerce Hosting plans