Every active plugin that runs on page load adds PHP execution time, and the hardware gap between hosts widens as the plugin count grows. A fast CPU executes each plugin's PHP faster; a slow CPU lets each plugin extend the queue. This study tracks TTFB across multiple hosts as plugin count is increased from 0 to 30 on an otherwise identical WordPress install. Companion to the 2026 speed leaderboard.

Methodology

The same WordPress 6.5 install was deployed to each host. Plugins were activated progressively in groups of 5, with TTFB measured at 0, 5, 10, 15, 20, 25, and 30 active plugins. Tests ran from WebPageTest Dulles, VA, with 9 runs per plugin level. The plugin set was real-world (caching disabled for fair measurement): WooCommerce, an SEO plugin, a form plugin, a security plugin, a page builder, and a representative mix of analytics, image-optimization, and utility plugins.

Per-Host Results

The headline finding: hosts with modern CPUs degrade roughly linearly with plugin count, while hosts with older CPUs degrade non-linearly, with steeper rises after the plugin count crosses 15. The mechanism is queueing: each front-end plugin adds PHP execution time to every uncached request, and on a slow core that added time compounds because requests start stacking up behind each other instead of clearing.

The zero-plugin baselines below come from our 2026 test cycle and set each host's starting line. A host that begins at 320ms with zero plugins has already spent your entire performance budget before a single plugin loads:

The per-host 0→30 plugin scaling curves and full data tables land in the next research pass. See the CPU rankings for the PassMark scores behind the hardware column.

Plugin Selection

The test stack mirrors what a real WooCommerce site runs, because plugin impact is not evenly distributed. What matters is whether a plugin executes on every front-end page load:

• Heavy, every request: WooCommerce (cart/session logic on every page), page builders (render their own templating layer), security plugins that inspect each request.
• Moderate, every request: SEO plugins (build meta/schema per page), form plugins that enqueue assets globally instead of per-page.
• Light or admin-only: image optimizers (work at upload time), backup plugins (run on schedule), analytics that load a single async script.

Groups of five were activated in that order, heaviest first, so the 0→15 segment of the curve carries most of the real-world load. Caching stayed disabled throughout: the point is to measure what PHP execution costs, and a page cache would hide exactly the thing being measured. Exact plugin versions get pinned in the next research pass.

Practical Takeaways

If you run WooCommerce, an SEO plugin, a page builder, a security plugin, caching, and a form plugin, you are already at 15-20 plugins before counting analytics or image optimization. Choose your host based on how it performs with 20 plugins active, not with 0. The 28ms TTFB number on a marketing page tests an empty install; the number that matters is what happens after the plugins your site actually needs are running.

To audit your own stack: install Query Monitor on a staging copy, note the PHP execution time per page, then deactivate plugins one at a time and re-measure. Any plugin adding more than 50ms to every front-end request should justify itself. The usual offenders are page builders kept active on sites that no longer use them, security plugins doubling up on rules your host already enforces at the server level, and form plugins loading their scripts on every page instead of only where forms appear. Fixing those three patterns routinely recovers 100-200ms without touching hosting at all.

Back to the full speed comparison: Fastest WordPress Hosting 2026.