Last updated: September 23, 2026 · Skill level: intermediate.
A WordPress plugin performance test is useful only when the environment, workload and limits are visible. In our clean WordPress 7.1.2 activation test, most of 20 popular plugins stayed close to the 449.0 ms baseline. The widest median gaps appeared for Redirection, Really Simple Security and Duplicate Post, but these results are diagnostic clues, not universal verdicts.
Key result: 13 of 20 plugins finished within 40 ms of the baseline median in this controlled activation-only test.
What did this WordPress plugin performance test measure?
This benchmark measured server response time for the default homepage after activating one plugin on a fresh WordPress 7.1.2 site. Each run used PHP 8.3 in WordPress Playground, warmed the page, then recorded nine requests. We report the median, the 90th percentile and the HTML response size.
- Fresh WordPress 7.1.2 environment for every plugin.
- One plugin active at a time with default settings.
- Nine warmed homepage requests after activation.
- Median and 90th-percentile request time, plus HTML bytes.
- Official WordPress.org packages and version metadata.
The test isolates activation overhead on one simple page. It does not measure a configured shop, form submission, scan, backup, page-builder layout, cache hit, admin screen or real network latency. WordPress Playground runs in WebAssembly, so absolute times should not be compared with a production host.
What were the results for all 20 plugins?
The median results ranged from 439.6 ms to 570.8 ms against a 449.0 ms baseline. Small negative deltas are normal run-to-run variation. Read every number as a result for this exact setup and plugin version.
| Plugin | Version | Median | vs. baseline | P90 |
|---|---|---|---|---|
| Akismet | 5.7.2 | 441.6 ms | -7.4 ms | 665.9 ms |
| Classic Editor | 1.7.0 | 468.2 ms | +19.2 ms | 604.4 ms |
| Contact Form 7 | 6.1.7 | 513.4 ms | +64.4 ms | 579.8 ms |
| WooCommerce | 11.1.2 | 454.2 ms | +5.2 ms | 611.7 ms |
| Elementor | 4.3.0 | 439.6 ms | -9.4 ms | 596.4 ms |
| Yoast SEO | 28.5 | 475.5 ms | +26.5 ms | 680.9 ms |
| WPForms Lite | 2.0.2.1 | 449.1 ms | +0.1 ms | 602.8 ms |
| Wordfence | 9.0.1 | 450.8 ms | +1.8 ms | 624.7 ms |
| UpdraftPlus | 1.26.8 | 457.1 ms | +8.1 ms | 601.9 ms |
| LiteSpeed Cache | 7.9.1 | 503.1 ms | +54.1 ms | 611.4 ms |
| Site Kit by Google | 1.188.0 | 441.2 ms | -7.8 ms | 611.1 ms |
| Jetpack | 16.2 | 448.7 ms | -0.3 ms | 602.6 ms |
| Rank Math SEO | 1.0.279 | 482.7 ms | +33.7 ms | 634.8 ms |
| All in One SEO | 5.0.1.1 | 458.0 ms | +9.0 ms | 608.4 ms |
| W3 Total Cache | 2.10.6 | 455.7 ms | +6.7 ms | 603.8 ms |
| Autoptimize | 3.1.15.1 | 488.8 ms | +39.8 ms | 638.2 ms |
| Redirection | 5.10.1 | 570.8 ms | +121.8 ms | 1670.5 ms |
| Duplicate Post | 4.7 | 522.1 ms | +73.1 ms | 820.4 ms |
| Mailchimp for WordPress | 4.14.1 | 465.9 ms | +16.9 ms | 685.6 ms |
| Really Simple Security | 9.8.3 | 565.3 ms | +116.3 ms | 1325.7 ms |
Which results deserve a closer look?
Redirection recorded a 570.8 ms median and 1,670.5 ms P90, Really Simple Security recorded 565.3 ms and 1,325.7 ms, and Duplicate Post recorded 522.1 ms and 820.4 ms. Contact Form 7 and LiteSpeed Cache also crossed 500 ms at the median. A second environment and feature-level test should come before any recommendation.
Several plugins landed at or below the measured baseline, including Elementor, Site Kit, Akismet and Jetpack. That does not prove they have zero cost. Their heavier work may happen on other routes, in the editor, during scheduled jobs, after configuration or through front-end assets absent from the default page.
Why does plugin count fail as a performance metric?
Ten focused plugins can be lighter than one plugin that performs expensive database queries or contacts several remote services. The work executed on a request matters. A plugin installed for admin-only tools may barely affect a public page, while a small add-on can enqueue blocking assets everywhere.
- Database queries: quantity, indexes and repeated option lookups.
- Front-end assets: JavaScript and CSS loaded on pages that do not need them.
- Remote calls: APIs, fonts, ads, analytics and license checks.
- Background work: cron jobs, scans, backups and imports.
- Cache behavior: whether output can be cached and whether activation changes cache rules.
For a broader speed checklist, use our WordPress performance optimization guide. If images dominate your page weight, compare the options in our image optimization plugin guide.
How can you repeat the test on your own site?
Use staging and change one variable at a time. A production site has real content, logged-in users, cache layers and third-party services that this laboratory test intentionally removes.
- Create a staging copy and match production PHP, WordPress, theme and plugin versions.
- Record a baseline for representative URLs: homepage, article, archive, search, login and any checkout or member page.
- Warm the cache consistently, then collect at least nine runs per URL.
- Activate or deactivate one plugin, repeat the same requests, and compare medians rather than the single fastest run.
- Use Query Monitor or your host’s profiler to trace slow queries and hooks.
- Run Lighthouse or WebPageTest to catch browser-side JavaScript, CSS, image and layout costs.
- Repeat with the plugin’s real configuration and its main feature exercised.
What is the practical decision rule?
Keep a plugin when its value exceeds its measured cost and no simpler option delivers the same outcome. Replace or reconfigure it when profiling shows repeatable overhead on important user journeys. Removing a useful plugin solely because of one synthetic result can trade a small speed gain for lost functionality or weaker operations.
For plugins that overlap in purpose, compare the actual workflow as well as speed. Our Yoast SEO vs Rank Math comparison and WP Rocket vs LiteSpeed Cache comparison cover feature and deployment differences that a homepage timing cannot capture.
How much timing difference is meaningful?
A difference of a few milliseconds in this environment is not a reliable product distinction. Operating-system scheduling, warm-up behavior and the runtime itself introduce variation. That is why the table reports medians and P90 values. A result becomes actionable when it repeats across runs, pages and a second environment, then maps to a traceable query, hook or remote call.
Set a site-level budget before choosing a threshold. A content site may care most about cached article delivery and editor responsiveness. A store should add product, cart, checkout and account flows. An agency dashboard may prioritize logged-in administration. The relevant budget follows the user’s task, not a generic homepage score.
Why can two plugins behave differently together?
Single-plugin tests cannot reveal interaction costs. Two plugins may enqueue the same library, compete for a hook, duplicate image processing or generate cache variations. A security plugin and a cache plugin may also behave differently after rules and exclusions are configured. Test the final stack after individual screening.
Database growth changes the picture too. An activation-only run has almost no orders, submissions, redirects or logs. A production plugin may remain light at first and slow down as its tables or autoloaded options expand. Include a representative database and long-running scheduled work in a pre-launch test.
What should plugin authors measure?
Plugin teams should publish a small, repeatable performance budget with each release. Measure important hooks, query counts, memory, REST responses and front-end assets against a previous stable version. A release check catches regressions earlier than customer reports and gives maintainers evidence for optimization work.
- No assets on pages where the feature is absent.
- No uncached remote request in a normal front-end response.
- Bounded queries for large datasets and indexed lookup columns.
- Scheduled tasks that avoid stampedes and expose failure logs.
- Compatibility tests for current WordPress and supported PHP versions.
What are the limits of this benchmark?
The largest limit is scope. We measured one public route, one plugin at a time, default settings and a synthetic local runtime. We did not measure browser rendering, logged-in screens, memory, database queries, background jobs or feature completion. Versions also change. The table is a dated reproducible snapshot that helps form better questions.
That limitation is deliberate. A narrow test can be repeated and audited. A broad score that mixes hosting, design, cache, traffic and configuration may look more realistic while making cause impossible to identify. Use this table for initial screening, then profile the real site before changing a production stack.
Frequently asked questions
Do more WordPress plugins always make a site slower?
No. Plugin count is a weak predictor by itself. Code quality, database work, remote requests, loaded assets, configuration, hosting and whether a feature runs on the tested page matter more than the raw number of active plugins.
Which plugin was fastest in this test?
This test cannot name a universal fastest plugin because the products perform different jobs. Several runs landed within normal timing noise of the 449.0 ms baseline. The useful result is the measured delta for this controlled setup, not a universal league table.
Should I delete a plugin because it scored poorly here?
No. Retest the plugin on a staging copy of your own site with its real settings and features in use. A plugin that adds business value can justify overhead, and caching, queries, third-party calls or page-specific assets may dominate the result.
How should I test WordPress plugin performance?
Clone the site to staging, record a baseline, activate or deactivate one plugin at a time, warm caches, run repeated front-end and admin tests, and compare medians. Also inspect queries, JavaScript, CSS, network calls and Core Web Vitals.
Sources and methodology
Test data was collected by WPPRES on September 23, 2026. Plugin versions and active-install counts came from the WordPress.org Plugin Directory. The test runner used the official WordPress Playground CLI. Performance interpretation follows the web.dev Core Web Vitals guidance.
Leave a Reply