Super Speedy Performance Analysis
Find which plugin is actually making your site slow, with proof
Most performance tools tell you the site is slow. This one names the plugin, the page and the milliseconds, then proves it by measuring again with that plugin switched off for its own test requests. Free, no licence key, and your visitors always get the complete site.
Every profiler gives you another list. This one proves the cause.
See the slow page, the plugin responsible and the measured difference when that plugin is removed from the test request.
The category page takes seconds to load, the dashboard crawls, and someone has emailed to say the checkout hung. Something on the site is doing it, and you have dozens of plugins active.
So you do what every guide says. Build a staging clone, install a profiler, sort the queries by time, then switch plugins off one at a time and reload. An afternoon later you have a suspect and no proof, because the clone holds a fraction of the products and none of the traffic. Doing it on the live site instead is not an option on a shop taking orders.
Super Speedy Performance Analysis runs the experiment on the real site. It profiles the key pages, names the plugin and its cost in milliseconds, then re-runs the same page with that plugin removed from its own test request only. The result is a measured before-and-after figure you can use to fix the problem, challenge the plugin author or remove the plugin with confidence. Visitors always get the complete site, and no plugin is ever really deactivated.
Free
GPLv3, no licence key, updates included
Zero
per-query overhead on ordinary visitor traffic
3
measured samples per page, medians reported
30ms
noise floor, below which nothing is claimed
What Performance Analysis gives you back
- A name, not a suspicion. Every finding says which plugin or theme is responsible, on which page, and what it costs in milliseconds.
- Proof you can act on. Measured impact comes from disabling the plugin and re-measuring, so it survives an argument with the plugin’s author.
- The checkout nobody has ever watched. A real purchase timed step by step, split at the moment the money is taken, then the order screen afterwards.
- The slow save explained. WordPress saves over ajax and reloads, so a slow save hides in a request nothing watches. This profiles the write itself.
- Plugins that make the site faster, credited. A plugin that saves time is reported as a saving rather than written off as no impact.
- Permission to cache for logged-in customers. The cookies and nonces blocking a shared cache, named, with ranked candidates for what sets each one.
- An answer on a cached site. Every profiling request is signed and cache-busted, so a page cache cannot answer it and fake a good result.
- Honesty about what it could not measure. A page a cache served is reported as unmeasured, and SQL time it could not capture is stored as unknown rather than zero.
- A site that is never changed by being measured. Suspects are disabled for the test requests only, activation routines are silenced, and destructive statements are refused during a measurement.
- Something to hand to a developer. Any result exports as one privacy-safe Markdown document with the SQL literals and identifiers stripped out.
What you have at the end of a run
A named plugin, a named page, and a number in milliseconds that came from measuring the page with that plugin in and then with it out. The queries behind it, and what the database says is wrong with each one. The function inside the plugin that spent the time. A note of anything the run could not measure, rather than a gap you have to take on trust. Enough to open a ticket with the plugin’s author, or to make the call yourself.
What it measures that other tools do not
Plugin Impact Analysis
Each plugin’s true cost, per page, measured by taking it out and re-measuring in every cache mode. Attribution says who ran the query; this says what actually changes when the plugin is not there.
Checkout and order flow
One real WooCommerce purchase, timed at every step and split at the payment boundary, then opening the order and marking it completed. A pre-flight lists exactly what the run will trigger before anything is created.
Update and save profiling
The administrator’s real save on a post, page, product or WooCommerce order, profiled as the write request itself, with the editor reload excluded so a slow save hook cannot hide inside it.
Function-level detail
With the free excimer extension installed, every profile gains a by-function breakdown with self and inclusive time, attributed to its plugin or theme, including inside theme template files.
Shared libraries attributed correctly
When two plugins bundle the same library, PHP loads one copy and the owner on disk is decided by autoloader order. Other tools charge that plugin. This one follows the call chain to whoever actually called in.
Query plans and rows examined
Slow queries come with what EXPLAIN says: no usable index, a temporary table, a filesort. Where MySQL allows it, the analysis compares rows examined against rows returned and catches full scans nothing else sees.
Where the flat cost goes
The answer to “every page is slow but nothing shows up”. Each page is broken into phases that sum to its generation time, with every plugin’s own boot cost and the slowest hook callbacks named.
Drivable by an agent
Every analysis runs from WP-CLI with JSON output, and from the WordPress Abilities API on WordPress 6.9 and later. An AI agent can measure, read the findings, change something and measure again.
Inert until asked
The capture layer is a conditional drop-in that returns before WordPress builds its database object. Without a signed profiling token the per-query overhead is nil, and both helpers are removed on deactivation.
Trust the result, even when plugins share code
Plugins bundle the same libraries as each other all the time. Freemius, Action Scheduler, Guzzle and anything else that lands in a vendor directory. PHP loads exactly one copy, and which plugin owns that copy on disk is decided by load order rather than by whose work it is. Attribute by file path, as profilers generally do, and one unlucky plugin gets charged for every other plugin’s use of that library.
Performance Analysis records the whole chain of components behind every query, walks past the shared library and charges the plugin that called in, while still naming the library so you can see where the work happened. A plugin using its own bundled library is still charged for it, and an ordinary call into another plugin’s API still resolves to whoever owns that API.
It matters less than it looks, and that is worth saying plainly. The headline number on the Plugins tab comes from disabling a plugin and re-measuring, which is immune to the whole question. Attribution is a hypothesis. Measured impact is the experiment.
Key features
- Site score out of 100 with the findings that matter most, each naming the component responsible.
- Analyse this page from the admin bar, on the front end or in wp-admin, with the result stored and re-openable.
- Two attribution views, whose code ran and who asked for the work, switchable with nothing re-profiled.
- Queries in loops named properly, including when one plugin’s queries run inside another plugin’s code.
- Query shapes that hurt: postmeta scans, SQL_CALC_FOUND_ROWS, ORDER BY rand(), leading-wildcard LIKE and nested taxonomy joins.
- Autoloaded options that no profiled page read, with copy-and-paste SQL to switch them off.
- Blocking HTTP calls during render, with the host and the plugin that made them.
- Object cache modes: each plugin measured with the cache off, priming and warm, so you can see who depends on it.
- Theme cost, measured by swapping to a stock theme for the test requests only.
- Dependency groups: plugins that cannot run without another are measured together rather than skipped.
- Browser transport for sites where a firewall or Basic Auth stops the server fetching its own pages.
- History of score, findings and median generation time across runs, so you can watch the site get slower as it grows.
- The measurement path disclosed, including whether the request passed through Cloudflare, because a loopback can bypass a CDN.
- Server capability detection that writes the exact install commands for your operating system, PHP version and package manager, and installs nothing itself.
- Opt-in community results at superspeedy.org, anonymised, with the payload shown to you before anything is sent.
Why choose Super Speedy Performance Analysis
Measured
not inferred from a single request
Checkout
and order handling, timed end to end
Live-safe
nothing is ever really deactivated
CLI + MCP
every analysis drivable without the GUI
Documentation and development
Super Speedy Performance Analysis Knowledge Base
View full Knowledge Base →What's new in Super Speedy Performance Analysis?
View full changelog →0.18.0 (12th August 2026)
- Shared analyses now describe what kind of site this is – an online shop, a jobs board, a publisher, or honestly more than one of them – with the signals that led to the label, so superspeedy.org can compare your results against sites genuinely like yours instead of a single average.
- Site sizes are shared as bands and never exact counts, and now cover pages, total orders, orders in the last 30 days, comments and how many plugins are active, alongside the posts, products, users and database size already sent. Order counts use safe routes only: total orders come from WooCommerce's own order table estimate or WordPress's maintained count, and from nothing at all on a posts table too large to count cheaply, while the 30-day figure is a real count of that window and stays accurate however busy your shop is.
- A checkout analysis now shares your order-management time – opening the order and marking it completed – as its own record with its own total. It was measured but discarded on the way out before. Customer checkout totals are unchanged and still contain no admin time.
- A management sequence that was blocked by a security plugin, or that only got half way, is shared as blocked or partial rather than quietly left out.
- The Share tab now describes all of this in plain terms: what the bands mean, and that checkout and order management travel separately.
0.17.4 (12th August 2026)
- When a plugin reacts to another being excluded for measurement – trying to switch a plugin on or off, or to run a destructive database statement – you are now told, with an admin notice naming the plugin that reacted and the plugin it reacted to. Every attempt was already refused; now you find out even if the analysis finished while you were elsewhere.
- Reactions get their own block on the Overview tab instead of competing for a top-five slot they always lost, and read as plain English ("Rank Math Pro tried to deactivate a plugin while Rank Math was excluded for measurement") rather than a rule name.
- Shared analyses now carry which plugin was excluded alongside which plugin reacted, so these pairs can build a community dependency map. The refused statement itself is still never shared, only its fingerprint.
- Fixed the SEO plugin slug in the bundled rules (Rank Math installs as seo-by-rank-math), so a Rank Math site is correctly spotted when a second SEO plugin is also active.
Questions
Is it really free?
Yes. GPLv3, no licence key, and updates are included. The download is also published on GitHub, ungated.
Will measuring slow down my visitors?
No. The capture layer only wakes for requests carrying a signed profiling token. On ordinary traffic the drop-in returns before WordPress builds its database object, so the per-query overhead is nil.
Is it safe to run on a live site?
Yes, and that is the reason it exists. A suspect plugin is disabled for the analysis’s own test requests only. No activation or deactivation routine fires, destructive database statements are refused during a measurement, and visitors get the complete site throughout.
How is this different from Query Monitor?
Query Monitor shows what happened on one page load and leaves the interpretation to you. This profiles your key pages repeatedly, attributes the cost to individual plugins, then proves each attribution by re-measuring with that plugin disabled. Inference versus measurement. Query Monitor is not a dependency, and if it already owns the database drop-in, Performance Analysis says so and offers a temporary swap rather than overwriting it.
What does it need from my server?
WordPress 6.2 or later, PHP 7.4 or later, working loopback requests and a writable wp-content. The excimer extension and MySQL performance_schema are optional and add depth. The Tools tab writes the exact install commands for your server and never installs anything itself. Where an optional extra is missing, nothing is estimated in its place; that finding simply does not appear.
My site is behind a cache or a firewall. Will it still work?
Yes. Profiling requests are signed and cache-busted so a page cache cannot answer them, and where a firewall or Basic Auth stops the server fetching its own pages the analysis runs through your own browser instead. Anything it still could not measure is reported as unmeasured rather than counted as fast.
Does the checkout analysis place a real order?
Yes, one, and it is the only run type that does. It buys a hidden product rather than anything from your catalogue, sends the order emails so your mail server’s own time is measured, then cancels and deletes the order and restores stock. A pre-flight lists every email, webhook and plugin the run will trigger before anything is created.
Will it blame the wrong plugin?
It is built specifically not to. Where two plugins bundle the same library, the cost is charged to the plugin that called into it rather than the one that happens to host the copy on disk. More to the point, the headline figure comes from disabling a plugin and re-measuring the page, which does not depend on attribution at all.
What if one plugin depends on another?
Plugins named in another plugin’s
Requires Plugins header, and fragile security plugins, are not excluded. If an isolated test still produces a fatal response, the run treats that as dependency evidence, splits the test group and continues rather than presenting the failed request as a performance result.Does it work with WooCommerce HPOS?
Yes, including the HPOS order editor for update and save profiling. Checkout analysis supports both the block checkout and the classic shortcode checkout.
Does it share my data?
Only if you opt in, and the Share tab shows the exact payload before anything is sent. Your domain, your URLs, raw SQL, emails and customer data are never included, and the site is identified by a random ID.
What happens to my data if I remove it?
Deactivating removes the two helper files and stops all scheduled work. Deleting leaves your stored analyses alone unless you switch on “Delete all SSPA data when the plugin is deleted” on the History tab first.
Where do I read more before installing?
The documentation wiki covers what each measurement shows, how the numbers are made, and the full WP-CLI reference.
Get it Free
Free download. Install in seconds.
Be the first to review “Super Speedy Performance Analysis”
Reviews
There are no reviews yet.