How I Test WordPress Plugins

Every review, comparison and “best of” list on The WP Ninja comes from plugins I installed and measured on my own test site. I don’t rewrite other people’s reviews, and I don’t publish a number I didn’t measure myself or read from a primary source like the plugin’s own pricing page.

This page explains the method once, so each article can get straight to the results.

Last updated: 19 October 2026

My test site

All testing happens on a local copy of WordPress running on my own computer, not on a live site. It’s built with DDEV, a free tool that runs WordPress inside Docker containers, so I can wipe it and rebuild it in minutes.

WordPress7.1.2 (I note the exact version in every article)
PHP8.3
DatabaseMySQL 8.0
Web servernginx
ThemeKadence (free), same settings on every run
Other pluginsKadence Blocks only
ComputerHP Z1 G5 desktop, 22 GB RAM

Step 1: a clean baseline, proved

Before I install anything, I measure the empty site and save a snapshot of its database. That’s the baseline every plugin gets compared against.

Between plugins I restore that snapshot, then measure again. If the numbers don’t match the first baseline exactly, I stop and find out why before going further. This is how I know a plugin’s leftovers from the last test aren’t hiding inside the next one’s results.

I also check the WordPress version at the start and at the end of each session. WordPress once auto-updated itself halfway through a test, and the restore check is what caught it.

Step 2: install it like you would

I activate every plugin in the browser and click through its setup wizard, the way a beginner would. Activating from the command line skips all of that, and the wizard is where the surprises live. WPForms Lite’s wizard, for example, comes with a data-sharing opt-in that’s already ticked, and I’d never have seen it any other way.

Then I set each plugin up to do the same job. For a form plugin that’s the same contact form; for an SEO plugin it’s the same titles and descriptions. And I check the result actually works on the page, because a plugin that’s light because it’s doing nothing isn’t a win.

Step 3: what I measure

The same script runs for every plugin, so the numbers are comparable from one article to the next:

  • Page speed (TTFB): how long the server takes to start sending a page. I take the median of 15 requests, for both a front-end post and the WordPress dashboard, with no page cache.
  • Page weight: the size of a post’s HTML, and how many CSS and JavaScript files the plugin adds to it.
  • Database footprint: new database tables, new rows in the options table, and how much data loads on every single page view (“autoloaded” options).
  • Background tasks: how many scheduled jobs (WP-Cron events) the plugin adds.
  • Structured data: how many schema blocks show up in the page source.

One honest caveat: the autoloaded-data number drifts between identical runs (I’ve seen it move by about 3 KB, from 64.7 KB to 67.6 KB, with nothing installed). When a plugin’s difference is that small, I say so and don’t publish it as a result.

Step 4: delete it and look for leftovers

When I’m done, I delete the plugin from the Plugins screen, which is what you’d do. That runs the plugin’s own clean-up code. Then I measure again and report anything it left behind: tables, options or scheduled tasks.

Extra steps for some categories

  • Backup plugins: I damage the test site the same way for every plugin: delete 5 posts and 20 images, switch the theme and turn off a plugin. Then I restore from the plugin’s backup and compare every database table against a fingerprint I took before the damage.
  • Security plugins: I send the firewall fake attack requests (a path-traversal probe, a scanner user agent) to see what it blocks, and measure how much it adds to every page load.
  • “Best of” lists: I write the scoring rules and their weights down, with a date, before I test the first plugin. Each list publishes its own scoring table. If I change a rule afterwards, the article says so and explains why.
  • Prices: I take them from each vendor’s own pricing page and note the date, because prices change.

What my tests can’t tell you

My numbers come from one quiet local site with no real visitors. On your host, every plugin will be faster or slower in absolute terms. What carries over is the difference between plugins, and what each one adds to your database.

I also test each plugin on the version available on the date in the article. If a plugin has had a big update since then, my results may be out of date. When I re-test, I update the article and its date.

Who’s behind the tests

The WP Ninja is run by the team behind anwp.pro, where we make WordPress plugins for sports and league sites. When one of our plugins is relevant to an article, it’s named as ours and measured the same way as everything else. More on that on the About page.