What a Plugin Costs You in Load Time

How the count grows

Every plugin was installed for a reason. A contact form, a gallery, a booking tool, a cookie notice, something a supplier added, something trialled and never removed.

None of them was a bad decision at the time.

What nobody does is remove one. Deactivating something feels risky, deleting it feels riskier, and nothing prompts the review.

So the number only goes up, and after a few years a small business site is running twenty or thirty of them.

What each one costs

• Files loaded on every page, frequently including pages that do not use it.
• Database work, where a plugin queries on each page load.
• Its own dependencies, such as a script library it brings with it.
• Update maintenance, which is time rather than speed.
• Security surface, since each is code somebody else wrote.
• Conflicts, which are difficult to diagnose in proportion to the count.

The first is the one that matters for speed and the one most people do not realise. A booking plugin used on one page frequently loads its files on all forty.

A worked example

A small hotel site with thirty-one active plugins.

Going through them: four were doing something the business relied on. Six were doing something minor that could be replaced with a few lines in the theme. Eleven were superseded, duplicated by something else, or from features no longer used.

The remaining ten nobody could account for at all, including two from an agency relationship that ended in 2017.

They removed twenty-one over an afternoon, testing after each few, with a backup taken first.

The homepage went from around ninety requests to about forty, and from six seconds to just over two.

Nothing broke that anybody noticed. Two small visual details changed and were fixed in the theme.

The audit

1. List every plugin with what it does, in one sentence.
2. Mark the ones you cannot explain.
3. Mark the ones doing something the theme could do.
4. Mark duplicates, where two do overlapping jobs.
5. Check the last update date on each.
6. Take a backup, then remove in small groups, testing between.

The second category is usually the largest and the easiest to act on. Anything nobody in the business can explain is a candidate by definition.

The fifth matters separately from speed. A plugin last updated three years ago is a security question as much as a performance one.

Deactivate before deleting

The practical safety measure.

Deactivating stops the plugin running while leaving its settings intact, so reversing is immediate if something breaks.

Leave it deactivated for a fortnight, then delete. That gives time for somebody to notice a missing feature that nobody thought about during the audit.

What not to do is leave things deactivated indefinitely. An inactive plugin still sits on the server and still needs updating for security, so the tidying is not finished until it is deleted.

The counter-case

Where plugins are the right answer and removing them is not.

Anything doing genuine work: taking payments, managing bookings, handling forms, running a shop. Replacing those with custom code is expensive and usually worse.

Security and backup plugins, which are earning their weight by definition.

And anything where the alternative is paying a developer more than the performance is worth, which for a small business is frequently the case.

The target is the ones doing nothing, rather than the ones doing something. A site with eight useful plugins is in considerably better shape than one with three and a pile of custom code nobody can maintain.

Loading them only where needed

The next step once the removals are done.

Several tools let you control which pages a plugin loads on, so a booking widget loads on the booking page and nowhere else.

On a site where most visitors land on a service page, that removes most of the cost without removing the capability.

It requires knowing which pages use what, which the audit has already told you, so the two jobs go together naturally.

Themes count too

An easy thing to overlook when counting plugins.

Inactive themes sit on the server, need updating for security, and occasionally contain their own plugins bundled in.

Most sites carry two or three defaults nobody has removed since installation, plus whichever one was tried and rejected.

Keep the active theme, keep one default as a fallback for troubleshooting, and delete the rest.

The fallback matters: when something breaks and you need to know whether the theme is responsible, switching to a simple default is the fastest test available.

Choosing new ones

Since the count will grow again.

Before installing anything, ask whether the theme already does it, whether a few lines would do it, and whether the problem is worth solving at all.

Check when it was last updated and how many sites use it, both of which indicate whether it will still be maintained in two years.

And note why you installed it somewhere, so the next audit does not produce another entry nobody can explain.

That single habit prevents most of the accumulation, and almost nobody does it, which is why every site eventually needs this audit.

Finding the one that is slow

Sometimes a single plugin is responsible for most of the problem, and identifying it saves removing twenty.

The method is unglamorous: deactivate everything, measure, then reactivate in groups, measuring after each, until the slow one appears.

That takes an hour on a staging copy and is not something to do on a live site during business hours.

What it frequently finds is one plugin doing something expensive on every page load, such as a slider querying the database or a security tool scanning on each request.

Replacing that one is a far smaller job than a general tidy, and it delivers most of the improvement.

If you have a staging area, this is what it is for. If you do not, it is a reasonable argument for having one.

What to expect from the result

Modest and worthwhile, rather than transformative.

Removing unused plugins typically takes a meaningful fraction off page weight and request count, and occasionally fixes a mysterious slowness nobody could locate.

It also reduces the ongoing update burden and the chance of a conflict breaking something at an inconvenient moment, which is worth as much as the speed.

What it will not do is fix a site whose images are four megabytes each, which remains the first thing to address on most small business sites.

The request count this affects is covered in how many things a page loads.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.