WordPress plugin speed test
Every plugin on a page ranked by what it loads, the ones loading where they are not used, and the one thing to fix first.
Enter any public WordPress page. You’ll get every plugin ranked by how much it loads here, which ones load without being used, and what to do about the worst one.
Why plugins slow WordPress down
A plugin can only affect visitors through what it puts on the page: scripts, stylesheets, fonts, and requests those files make. WordPress’s default is to load a plugin’s files on every page, because the plugin cannot know which pages will use it. Most plugin authors never narrow that. So a site with a form on the contact page, a slider on the home page and a table on one article loads all three plugins’ CSS and JavaScript on all of its pages.
This check shows exactly that, per page: which plugin, how many files, how many kilobytes, and whether the page even uses it. The fix is nearly always the same — load the files only where they are needed — and the guide gives the code.
What it checks
- Every
<script src>and stylesheet<link>in the page, grouped by the plugin, theme or third party that owns it. - The transfer size of each file, as the server reports it.
- Which files are render-blocking — scripts in the head without
defer/async, and stylesheets that are not print-only. - Whether each plugin is referenced anywhere in the page’s markup — the “probably not used here” flag.
- A handful of well-known specifics: render-blocking jQuery, WooCommerce cart fragments on non-shop pages, whole-set Font Awesome, reCAPTCHA on pages without a form, the emoji script.
What it does not do
It does not measure time — for that, run the same page through the Core Web Vitals check, which uses a real Lighthouse run and shows where the seconds go. It does not see server-side cost: a plugin that makes twenty database queries and ships no files is invisible here, and shows up as a slow server in the speed check instead. And it reads a single page; test the home page, a post, and a product page separately, because the answer differs.
Common questions
How can you tell which plugin a file belongs to?
WordPress puts every plugin's front-end files under /wp-content/plugins/<plugin-name>/, and every theme's under /wp-content/themes/<theme-name>/. The URL of each script and stylesheet names its owner. That is all this check reads — the page's HTML and the size of each file it references. It never logs in, and it does not need the plugin list from your admin.
What does 'probably not used on this page' mean?
The plugin loads scripts or styles here, but nothing in the page's own markup — no class, id or data attribute the plugin uses — references it. A contact-form plugin's CSS on a page with no form is the classic case. It is a heuristic: some plugins work invisibly and the check exempts the obvious ones (caching, SEO, security). Confirm on the page before removing anything.
Does the number of plugins matter?
No — what they load on the front end does. Thirty plugins that only run in the admin cost visitors nothing. Two that each ship 300 KB of CSS on every page cost a lot. That is why this ranks by weight per page, not by count.
Why doesn't it show load time?
Weight and time are different measurements. This check tells you which plugin is responsible for the bytes; the Core Web Vitals check tells you which part of the load those bytes actually delay, using a real Lighthouse run. Use this to find the plugin, that to confirm it mattered.
Should I just deactivate the plugins it flags?
Only if you don't need them at all. Usually you need the plugin on some pages and not others — that is what dequeuing per page or a script manager is for. The guide linked from the result walks through both.