Chykalophia Docs
Performance

How plugins affect speed

How WordPress plugins can slow down your site, which types tend to be heaviest, and how to tell if a plugin is causing a performance problem.

Difficulty
Beginner

Plugins are one of WordPress's greatest strengths — they let you add almost any feature without custom development. But they come with a real performance tradeoff. This guide explains honestly how plugins affect speed, what to watch for, and when to be concerned.

Quick summary

The number of plugins matters less than their quality and what they load. A few poorly coded plugins can slow your site more than twenty lightweight ones. The biggest culprits are plugins that load extra JavaScript and CSS on every page, even when not needed.

Why plugins can slow sites down

Every active plugin runs code. Some of that code runs when pages load for visitors. Plugins can slow your site in several ways:

  • Loading extra CSS and JavaScript on pages where they are not needed (a contact form plugin loading its scripts on every page, not just the contact page)
  • Making extra database queries to look up data on every page load
  • Running code on every request even when the plugin's feature is not being used
  • Conflicting with caching and preventing pages from being served from cache
  • Using poorly optimized code that is slower than it needs to be

The key insight: a plugin's impact depends much more on how it was written than on its feature set or popularity.

Plugin types that tend to be heavier

Not all plugins are equal. Some categories are more likely to affect performance:

Plugin typeWhy it can be heavy
Page builders (Elementor, Divi, Beaver Builder)Add their own CSS and JavaScript to every page they build
Sliders / carouselsOften load large libraries even on pages without a slider
Social media share buttonsLoad scripts from an external server; Google lists social button widgets among the embeds worth loading only on click
Live chat widgetsPull in a third-party service on every page load, whether or not anyone opens the chat
Form buildersLoad form libraries on every page, not just the ones with forms
Backup pluginsCan run intensive processes during backups
SEO pluginsGenerally lightweight, but some load scripts on the front end

Good plugins are aware of this problem

Well-maintained plugins load their scripts only on pages where they are actually used. When evaluating a plugin, check recent reviews and the plugin's support forum for performance complaints.

The honest truth about plugin count

You will read advice saying "keep your plugins under X." There is no magic number, and no official one: a site running a long list of lightweight, well-coded plugins can outperform a site running a handful of heavy, poorly coded ones.

That said, plugin sprawl is a real phenomenon. Over time, sites accumulate:

  • Plugins installed for a one-time task, never removed
  • Duplicate plugins doing similar things
  • Plugins that were recommended years ago but have not been updated
  • Plugins installed by someone who has since left the organization

A periodic audit — reviewing what is installed and why — is a healthy maintenance practice.

How to tell if a plugin is causing a problem

The most reliable method is to test before and after. But you do not need to do this yourself — this is something we can do as part of a performance audit.

If you want to investigate yourself, the process is:

Test your speed before making any changes. Use PageSpeed Insights or GTmetrix and note the scores.

Deactivate one plugin at a time (starting with suspects: page builders, sliders, form plugins, chat widgets). Do this on a staging site, not your live site, if possible.

Re-test after each deactivation. If a specific plugin's removal caused a significant improvement, that is your culprit.

Always test on staging first

Deactivating plugins on a live site can break functionality for visitors. Use a staging environment to test. Ask us if you need help setting one up.

Caching plugins: the exception to the rule

Caching plugins are generally a net positive for speed, even though they are "another plugin." WordPress's own performance documentation sends people to caching first, calling it the biggest benefit for the smallest hassle: a page cache serves a ready-made copy instead of rebuilding the page and re-running database queries on every visit. WP Rocket and LiteSpeed Cache are two commonly used options.

Two caveats. Page caching in WordPress depends on a single shared file, advanced-cache.php, so two page-caching plugins cannot both run — plugin authors say so explicitly. And if your managed hosting already caches at the server (WP Engine's EverCache, Flywheel's FlyCache, Kinsta's own caching), a separate caching plugin may duplicate or fight with it. Check with us before installing one.

Common questions

Should I delete plugins I'm not using?

Yes. A deactivated plugin does not run its front-end code, so it is not slowing your pages down. It is still a security risk, because its files are still on the server and an unmaintained plugin can carry known vulnerabilities. WordPress's own hardening guide puts it plainly: keep your plugins updated, and "if you are not using a specific plugin, delete it from the system."

Is Elementor slow?

Elementor loads more CSS and JavaScript than a lean theme does. The gap has narrowed as Elementor has added performance features of its own — its Improved Asset Loading, for example, is described as "speeding up each page by only loading the functionalities needed for that page" — but a page builder still carries more overhead than a plain theme. The difference is manageable with good hosting, caching, and image optimization. For clients who need Elementor's editing capabilities, the tradeoff is usually worth it. See also Elementor & page speed.

What about security plugins?

Security plugins (Wordfence and Solid Security are two common ones) run checks that use server resources, so they can affect speed. The security benefit usually outweighs that cost, and some have settings that reduce what they load on the front end. Note that Solid Security is the current name for the plugin formerly sold as iThemes Security, so older articles may use the old name.

Need a hand?

If you're stuck, email support@chykalophia.com and we'll help. Include your website address and a screenshot if you can.

Learn more

Last updated

On this page