# What your WordPress plugins cost visitors (and the heavy ones)

> See what each WordPress plugin adds to your pages in kilobytes and requests, which ones do the same job twice or are abandoned, and what to remove, replace or load only where needed.

Updated 2026-09-25 · WordPress & WooCommerce · HTML version: https://getreport.app/guides/wordpress-plugin-cost

A WordPress plugin is installed once and then paid for on every page view. The visitor pays in kilobytes and waiting; you pay in updates and security risk. The number of plugins matters less than what each one does: 30 small plugins can be lighter than one slider. This guide shows how to see the cost of each plugin on a real page, how to decide what to remove, replace or restrict, and how to spot the ones that are no longer maintained. Plan an hour for the first audit.

## Quick answer

- Run the [WordPress plugin detector](https://getreport.app/tools/wordpress-plugin-checker) on the home page and on your most important template (a product, a post, the checkout).
- Anything over **150 KB on one page** is worth a look; that is where getReport raises the warning.
- Plugin not used on this page? Load it only where it is needed (Perfmatters, Asset CleanUp, or the plugin's own setting).
- Plugin not used at all? Deactivate and delete it.
- Two plugins for one job (two caches, two SEO plugins)? Keep one.
- Not updated in 2 years, or closed on wordpress.org? Replace it, starting with the closed ones.

## Why plugin cost matters

WordPress lets any active plugin add files to the page through `wp_enqueue_script` and `wp_enqueue_style`. Most plugins enqueue on every page because they cannot know in advance where you will use them. The contact form's script loads on the blog; the slider's 200 KB of JavaScript loads on the checkout; the popup builder's styles load on pages without a popup. Each file is a request, and scripts in the head block the page from drawing until they arrive. On a mid-range phone on 4G, an extra 300 KB of JavaScript is easily half a second of waiting plus the time to run it, which is exactly what Largest Contentful Paint and the other Core Web Vitals measure.

Front-end files are the part visitors see. Plugins also cost on the server: database queries on every request, options loaded on every page, calls to external services (a licence check, a remote font, a map API) that the server or the browser waits for. That part shows up as a slow first byte rather than as heavy files.

The second cost is maintenance. Each plugin is code from a different author that has to keep up with WordPress, PHP and security fixes. Plugins that stop doing so are the most common way WordPress sites get compromised.

## How getReport checks it

> **Free tool:** [WordPress plugin detector and plugin cost](https://getreport.app/tools/wordpress-plugin-checker): See which plugins, theme and page builder a WordPress site uses, what each plugin costs in kilobytes and requests on the page, which ones do the same job twice, and which are abandoned or closed on wordpress.org.

The detector works only from what the page reveals. Plugins are identified from asset URLs under `/wp-content/plugins/<slug>/` (the version comes from `?ver=`), and from the HTML comments and headers that SEO and caching plugins leave, such as Yoast's "This site is optimized with the Yoast SEO plugin" comment or LiteSpeed's `x-litespeed-cache` header. Nothing is guessed: plugins that add nothing to the front end do not appear.

The page is then loaded in Chromium, and every network request whose URL contains `/wp-content/plugins/<slug>/` is added to that plugin's total: bytes transferred (compressed, as the visitor downloads them), number of files and network time. Each detected slug is looked up in the wordpress.org plugin directory (cached for a day) for the latest version, the last update date and whether the plugin was closed.

![The detected plugins table: plugin name and slug, installed version with the latest version beside it when they differ, cost on this page in KB and number of files, and the wordpress.org status with warnings for closed and abandoned plugins](https://getreport.app/guides/img/wordpress-plugin-cost/plugins.webp "Heaviest plugin first; amber cost cells are above 150 KB, and the last column shows what wordpress.org knows about each plugin.")

> **Check: WordPress plugin weight.** Every active plugin can add scripts and styles to every page, whether the page uses them or not. A slider or a form builder can weigh more than the rest of the site together.
>
> 1. Deactivate plugins the site does not use; for the heavy ones in the table, check whether a lighter alternative exists.
> 2. Load plugin assets only where needed with a performance plugin (Perfmatters, Asset CleanUp) or the plugin's own "load on demand" setting.

> **Check: One caching layer is active.** Two caching or optimisation plugins fight over the same files: double minification breaks scripts, and stale pages are served from whichever cache wins.
>
> 1. Keep one caching plugin (the one your host recommends) and deactivate the other.
> 2. If the host provides server-side caching, use only its plugin and a separate image optimiser if needed.

> **Check: Every detected plugin has a recent update.** A plugin nobody maintains will not get security fixes and eventually breaks with a WordPress update. Two years without a release is the usual sign that it is abandoned.
>
> 1. Look for a maintained alternative with the same feature and replace the plugin; test on staging first.
> 2. If it is essential and small, consider paying a developer to take it over.

> **Check: No detected plugin has been closed on wordpress.org.** wordpress.org closes plugins for unfixed security issues or guideline violations. A closed plugin gets no updates and often has a known vulnerability.
>
> 1. Replace the plugin now; the reason shown by wordpress.org tells you how urgent it is.
> 2. Until then, keep the site behind a firewall plugin and check the vulnerability databases for the plugin name.

> **Check: Technology stack.** Knowing the CMS, framework, CDN and analytics behind a page helps you and your developer find the right settings for the fixes in this report.
>
> 1. Nothing to fix; use this list to find the right settings panel for the other findings.

Three limits of the table are worth knowing. It measures one page, so a plugin that loads only on the shop shows "none" on the home page. The version column is whatever `?ver=` says, and some plugins put the WordPress version there instead of their own. Premium plugins are not in the directory, so they show "not in directory" with no update date; that does not mean they are unsafe, only that getReport cannot tell.

## Step by step

### 1. Make an inventory

Open Plugins → Installed Plugins and note every active plugin with one line on what it does for the site. Then run the detector on three pages: the home page, a typical content page, and the page that earns money. Side by side you now have what is installed, what the visitor downloads, and where.

### 2. Sort each plugin into one of four piles

| Pile | Signal | Action |
| --- | --- | --- |
| Unused | Nobody can say what it does, or it did a one-off job (an import, a migration) | Deactivate, wait a week, delete |
| Used, but not here | Heavy on pages that do not use it | Load only where needed (step 4) |
| Used, heavy everywhere | Large on every page and genuinely needed | Look for a lighter alternative (step 5) |
| Fine | Small, maintained, used | Leave it |

Deactivating is reversible; deleting removes the files but usually keeps settings in the database. Try it on a staging copy if the plugin is part of checkout or forms.

### 3. Remove duplicates

Two caching plugins both minify, combine and cache the same pages. Double minification breaks scripts, and pages go stale because one cache is purged while the other is not. The fix is to keep the one your host recommends (LiteSpeed Cache on LiteSpeed servers, SiteGround Optimizer on SiteGround) and deactivate the other. The same goes for SEO plugins: two of them print two titles, two canonicals and two sets of schema. getReport flags duplicate SEO plugins in the SEO module; import the settings into the one you keep before deactivating the other (Yoast and Rank Math both have an import tool). The [duplicate plugins](https://getreport.app/learn/wordpress-duplicate-plugins) learn page lists the pairs we see most.

### 4. Load plugin files only where they are used

Three ways, from least to most technical.

**The plugin's own setting.** Many form, slider and gallery plugins have a "load assets only on pages that use the shortcode/block" option. Check its settings first.

**A performance plugin.** Perfmatters (Script Manager) and Asset CleanUp let you switch off each script and stylesheet per page, per post type or everywhere except chosen URLs, from a screen in wp-admin. Start with the heaviest plugin in the table, disable its files everywhere except where it is used, and check that page still works.

**A few lines of code.** WordPress prints each stylesheet with an id of `<handle>-css` and each script with `<handle>-js`, so the page source tells you the handles. This keeps Contact Form 7 on the contact page only:

```php
<?php
// wp-content/mu-plugins/load-cf7-only-on-contact.php
add_action('wp_enqueue_scripts', function () {
    if (is_page('contact')) {
        return;
    }
    wp_dequeue_script('contact-form-7');
    wp_dequeue_style('contact-form-7');
}, 20);
```

Files in `wp-content/mu-plugins/` load automatically and survive theme changes. Priority 20 runs after the plugin has enqueued its files at the default priority.

Scripts that must load everywhere can often be deferred so they no longer block drawing. Most caching plugins have a "delay JavaScript" or "defer JavaScript" option; turn it on and test menus, forms and the cart, which are what usually break.

### 5. Replace the heavy ones

The usual suspects are sliders, page builders, all-in-one "addon packs", social share buttons and popup builders. Often the lighter replacement is WordPress itself: a Cover block or a static hero image instead of a slider, core blocks instead of an addon pack, plain share links instead of a share-button script. Where you need a plugin, compare two candidates by installing each on staging and running the detector again: the table gives you the number to compare.

### 6. Replace abandoned and closed plugins

wordpress.org closes a plugin when it has an unfixed security issue, breaks the directory guidelines, or the author asks for it. A closed plugin receives no updates through wp-admin, and the reason is shown in the table. Replace closed plugins first, and until then check the plugin name in a vulnerability database and keep a firewall in front of the site.

A plugin with no release in two years is not necessarily broken, but it is not keeping up with PHP and WordPress releases, and nobody will ship the next security fix. Our [abandoned plugins](https://getreport.app/learn/wordpress-abandoned-plugins) page explains how to judge a replacement: recent releases, active installs and support threads that get answers.

### 7. Look at the server side

A plugin can cost nothing in the table and still slow the site if it runs heavy queries on every request. The free Query Monitor plugin shows database queries and time per plugin for the page you are looking at, while logged in. If the report shows a slow server response rather than heavy files, read [what a slow server looks like](https://getreport.app/guides/ttfb-what-a-slow-server-looks-like) next.

## Platform notes

### WooCommerce

WooCommerce's own scripts, and on some themes the cart fragments script, load on many pages, and every extension adds its own. Measure a product page and the cart, not only the home page; that is where the extensions pile up. Do not unload WooCommerce scripts on the cart or checkout.

### Page builders

Elementor, Divi and WPBakery load their framework on every page built with them, so they appear heavy in the table by design. Their performance settings (improved asset loading, dynamic CSS) reduce the cost. Replacing a builder is a redesign, not a plugin swap; plan it as a project.

## Verify

- Run the detector again on the same pages. The heavy plugin's cost reads "none" where you unloaded it, and the finding reads "No plugin loads more than 150 KB on this page" once none is above the line.
- Open the pages where the plugin should still work (the contact form submits, the slider slides, the cart updates).
- Compare the report's speed module before and after; [reading a speed test](https://getreport.app/guides/reading-a-website-speed-test) explains which numbers to watch.

## Common mistakes

- **Counting plugins instead of measuring them.** Removing five tiny plugins changes nothing a visitor feels; restricting one 250 KB slider does. Work from the cost column.
- **Unloading a script the page needs.** The page looks fine until someone uses the form. Test the interactive parts on every page type after each change.
- **Adding a speed plugin next to the host's cache.** That is two caches again. Use the host's plugin, and add a script manager only if it does not cache.
- **Deactivating a closed plugin without a replacement.** The feature disappears from the live site. Install and configure the replacement on staging, then switch.
- **Trusting the version column blindly.** If a plugin shows the same version as WordPress core, it is printing the core version. Check Plugins → Installed Plugins for the real one.

The launch settings that sit next to these plugins, from "Discourage search engines" to the "admin" user, are covered in [the 8 WordPress rookie mistakes](https://getreport.app/guides/wordpress-rookie-mistakes).