DEV Community: MakeWPFast

WordPress Memory Limit: How to Find What’s Eating Your PHP Memory

MakeWPFast — Tue, 23 Jun 2026 08:15:13 +0000

Originally published on https://makewpfast.com/wordpress-memory-limit-find-whats-eating-php-memory/

Every “fix memory exhausted” article tells you the same thing – bump WP_MEMORY_LIMIT to 256M and move on. That’s not a fix. That’s duct tape. The real question nobody answers is: what’s eating your memory in the first place?

I’ve profiled hundreds of WordPress sites. The pattern is always the same – someone raises the limit, things work for a while, then the error comes back. Because the actual problem is still there, just hiding behind a bigger number.

Let’s And when memory exhaustion tips a site from slow into a full white-screen crash — wp-admin included, so you can’t even log in to raise the limit — that’s no longer a tuning job. At that point the fastest route back online is to get a crashed WordPress site fixed, then come back and deal with the root cause once you’re live again.

actually diagnose it.

Understanding WordPress Memory – The Two Limits You Need to Know

WordPress has two separate memory ceilings, and most people confuse them.

PHP’s memory_limit is the hard cap set in your server’s php.ini (or pool config). This is the absolute maximum any PHP process can use.

WordPress’s WP_MEMORY_LIMIT is a soft limit WordPress sets for itself. It’s defined in wp-config.php and can never exceed the PHP limit.

There’s also WP_MAX_MEMORY_LIMIT – which applies only to admin-side operations (wp-admin). WordPress sets this to 256M by default.

Here’s the thing most guides skip: if your PHP memory_limit is 128M and you set WP_MEMORY_LIMIT to 512M, you still only get 128M. WordPress can’t override the server. It can only request up to what PHP allows.

To check your actual limits, drop this in a mu-plugin:

<?php
// File: wp-content/mu-plugins/memory-check.php
add_action('admin_notices', function() {
    if (!current_user_can('manage_options')) return;

    $php_limit    = ini_get('memory_limit');
    $wp_limit     = defined('WP_MEMORY_LIMIT') ? WP_MEMORY_LIMIT : '40M';
    $wp_max_limit = defined('WP_MAX_MEMORY_LIMIT') ? WP_MAX_MEMORY_LIMIT : '256M';
    $current_use  = round(memory_get_usage() / 1024 / 1024, 2);
    $peak_use     = round(memory_get_peak_usage() / 1024 / 1024, 2);

    echo '<div class="notice notice-info">';
    echo "<p><strong>Memory:</strong> PHP limit: {$php_limit} | ";
    echo "WP limit: {$wp_limit} | WP admin limit: {$wp_max_limit} | ";
    echo "Current: {$current_use}MB | Peak: {$peak_use}MB</p>";
    echo '</div>';
});

That gives you the full picture in one glance. If your peak usage is consistently close to the limit – say above 80% – you have a problem that needs investigating, not just a bigger number.

Where Memory Actually Goes in WordPress

PHP memory in WordPress gets consumed by four main things:

1. Plugin code loaded into memory. Every active plugin loads its PHP files on every single request. A plugin with 50 PHP files and a bunch of class autoloading? All of that sits in memory.

2. Database query results. When a plugin runs get_posts() without a limit, or loads the entire options table, all that data lives in PHP memory until the request ends. I wrote about this in the context of autoloaded options – a bloated autoload table eats memory on every single page load.

3. Image processing. When WordPress generates thumbnails or processes an uploaded image, it loads the full image into memory. A 5MB JPEG can easily consume 30-40MB of PHP memory when being manipulated by GD or Imagick.

4. Object caching and globals. WordPress stores a lot of intermediate data in memory – post objects, user objects, cached queries. If you’re running WooCommerce with thousands of products and a poorly written product query, that’s all sitting in RAM.

Step 1: Measure Current Memory Usage Per Page

Before you start disabling things randomly, measure. Add this to your theme’s functions.php or better yet, as a mu-plugin:

<?php
// File: wp-content/mu-plugins/memory-profiler.php
add_action('shutdown', function() {
    if (!current_user_can('manage_options')) return;
    if (defined('DOING_AJAX') && DOING_AJAX) return;
    if (defined('REST_REQUEST') && REST_REQUEST) return;

    $peak = memory_get_peak_usage(true);
    $peak_mb = round($peak / 1024 / 1024, 2);

    // Log to debug.log
    error_log(sprintf(
        '[Memory] %s - Peak: %sMB - URI: %s',
        date('H:i:s'),
        $peak_mb,
        $_SERVER['REQUEST_URI'] ?? 'unknown'
    ));
});

Make sure WP_DEBUG and WP_DEBUG_LOG are enabled in wp-config.php. Then browse your site – hit the homepage, a few posts, the admin dashboard, the plugins page. Check wp-content/debug.log afterwards.

What you’re looking for: which pages use the most memory? If your homepage uses 45MB but the admin plugins page uses 120MB, that tells you something. If a specific post type archive spikes to 90MB, that’s worth investigating.

For a deeper look at your wp-config.php debug constants and what each one does, check the wp-config.php performance tuning guide.

Step 2: Find the Memory-Hungry Plugins

This is where it gets interesting. Most guides tell you to deactivate all plugins and reactivate one by one. That works, but it’s painfully slow and doesn’t give you numbers.

Here’s a mu-plugin that measures memory before and after each plugin loads:

<?php
// File: wp-content/mu-plugins/plugin-memory-audit.php
// WARNING: Dev/staging only. Remove after diagnosis.

add_action('pre_current_active_plugins', function() {
    if (!current_user_can('manage_options')) return;

    $active_plugins = get_option('active_plugins', []);
    $measurements = [];

    foreach ($active_plugins as $plugin) {
        $file = WP_PLUGIN_DIR . '/' . $plugin;
        if (!file_exists($file)) continue;

        $before = memory_get_usage();
        // Note: plugins are already loaded at this point
        // This reads the file size as a proxy for code weight
        $size = filesize($file);
        $measurements[$plugin] = [
            'main_file_kb' => round($size / 1024, 1),
        ];
    }

    // Sort by file size descending
    uasort($measurements, fn($a, $b) => $b['main_file_kb'] <=> $a['main_file_kb']);

    echo '<div class="notice notice-info"><pre>';
    echo "Plugin Main File Sizes (larger = potentially more memory):nn";
    foreach ($measurements as $plugin => $data) {
        printf("%-50s %6.1f KBn", basename(dirname($plugin)), $data['main_file_kb']);
    }
    echo '</pre></div>';
});

But the real way to measure per-plugin memory impact is with the binary deactivation method. It’s faster than one-by-one:

Note your baseline peak memory (from Step 1)
Deactivate half your plugins
Measure again. Did memory drop significantly?
If yes, the culprit is in the deactivated half. Reactivate them, deactivate the other half.
Keep halving until you find the offender

With 20 plugins, this takes 4-5 rounds instead of 20 individual tests.

If you want to skip the manual work, Query Monitor shows memory usage per component. Install it, load a page, and check the “Environment” panel for current and peak memory. The “Queries by Component” panel shows you which plugins are running the most database queries – which correlates heavily with memory use.

Step 3: Investigate the Usual Suspects

In my experience diagnosing WordPress performance issues, these are the categories that eat the most memory:

Page builders (40-80MB). Elementor, Divi, WPBakery – they load massive amounts of PHP code and rendering logic on every request, even on pages that don’t use the builder. If you’re using Elementor on 3 pages but it’s loading its full stack on all 200 pages, that’s a problem.

WooCommerce (30-60MB). This is basically an application within an application. It’s legitimate memory usage, but it adds up fast when combined with WooCommerce extensions. If you have WooCommerce + 15 WooCommerce add-ons, don’t be surprised when you need 256MB+.

Multilingual plugins (20-40MB). WPML in particular loads a lot of translation data into memory. If you’re running a multilingual WooCommerce store, you’re stacking two heavy plugins together.

SEO plugins with real-time analysis (15-30MB). Yoast and Rank Math load content analysis libraries in the editor. This is mostly an admin-side concern.

Backup plugins during execution. When a backup runs, it can temporarily spike memory way beyond normal levels. If your memory errors happen at scheduled times, check your backup schedule.

For help diagnosing specific plugin conflicts, I wrote a separate guide on that.

Step 4: Check Your Database for Memory Bloat

A source of memory usage people rarely check: the database queries themselves.

Enable SAVEQUERIES temporarily in wp-config.php:

define('SAVEQUERIES', true);

Then add this to see what’s happening:

<?php
// Add to your memory-profiler mu-plugin
add_action('shutdown', function() {
    if (!current_user_can('manage_options')) return;
    if (!defined('SAVEQUERIES') || !SAVEQUERIES) return;

    global $wpdb;
    $total_queries = count($wpdb->queries);
    $slow_queries = 0;
    $total_time = 0;

    foreach ($wpdb->queries as $q) {
        $total_time += $q[1];
        if ($q[1] > 0.05) $slow_queries++;
    }

    error_log(sprintf(
        '[Queries] %s - Total: %d - Slow (>50ms): %d - Time: %.3fs - URI: %s',
        date('H:i:s'),
        $total_queries,
        $slow_queries,
        $total_time,
        $_SERVER['REQUEST_URI'] ?? 'unknown'
    ));
});

Important: SAVEQUERIES itself uses extra memory because it stores every query in an array. Only enable it during diagnosis, then turn it off. I’ve seen sites where enabling SAVEQUERIES was enough to push them over the memory limit – which tells you something about how many queries they’re running.

If you’re seeing hundreds of queries per page load, that’s a memory problem disguised as a query problem. Every result set sits in PHP memory. A query returning 10,000 rows of post meta data? That’s all in RAM.

For a deeper dive into slow queries, check the slow queries diagnostic guide.

Step 5: The Autoload Trap

This one deserves its own callout because it’s so common. Every page load in WordPress runs one query to load all autoloaded options from wp_options. All of them. Into memory.

Check how much data that is:

SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload = 'yes';

If that number is over 1MB, you have a problem. I’ve seen sites with 5-10MB of autoloaded data – that’s 5-10MB of memory consumed before WordPress even starts rendering a page.

Common culprits: abandoned plugin settings that left autoload = 'yes' entries behind, transients stored with autoload on, and serialized blobs from plugins that cache data in options instead of using the object cache.

I wrote an entire post about the autoload problem and how to fix it. If your autoload size is over 1MB, start there.

Step 6: Image Processing Spikes

If your memory errors happen specifically during uploads, the problem is almost certainly image processing.

When you upload a 4000x3000px image, WordPress generates multiple thumbnail sizes. The GD library (default) needs to hold the entire uncompressed image in memory. The formula is roughly:

width x height x channels x bytes_per_channel

For a 4000×3000 RGBA image: 4000 * 3000 * 4 * 1 = ~46MB. Just for one image in memory. Now multiply that by each thumbnail being generated.

Solutions:

Switch to Imagick if available – it streams from disk instead of loading everything into memory
Limit maximum upload dimensions with big_image_size_threshold filter (WordPress 5.3+)
Reduce registered image sizes – every size means another memory allocation during upload

// Limit uploaded images to 2560px max (WordPress default since 5.3)
// Lower it if you're hitting memory limits during uploads
add_filter('big_image_size_threshold', function() {
    return 1920; // Max dimension in pixels
});

When to Actually Increase the Limit

Sometimes you genuinely need more memory. Here’s when increasing makes sense:

You’re running WooCommerce with extensions – 256M is reasonable
You have a legitimate need for heavy plugins (LMS, membership, multilingual + ecommerce)
You’ve already optimized and your peak usage is still near the limit

And here’s how to set it properly:

// In wp-config.php - ABOVE the "That's all, stop editing!" line
define('WP_MEMORY_LIMIT', '256M');       // Frontend
define('WP_MAX_MEMORY_LIMIT', '512M');   // Admin/backend

But also check your PHP config. You can’t just set the WordPress constant – the PHP limit needs to match or exceed it. Ask your host, or check via phpinfo() or Site Health > Info > Server.

If your admin dashboard is slow, high memory usage is often part of the puzzle. Memory pressure causes PHP to spend more time on memory management, which slows everything down.

A Practical Diagnostic Workflow

Here’s the process I follow when someone reports memory errors:

Check the limits. What’s PHP’s memory_limit? What’s WP_MEMORY_LIMIT? Are they aligned?
Measure baseline. Drop in the memory profiler mu-plugin. Browse the site. Note peak usage on key pages.
Check autoload size. Run the SQL query. If it’s over 1MB, clean it up first – that’s often the quickest win.
Binary plugin test. Deactivate half, measure, narrow down. Find the top 2-3 memory consumers.
Decide. Can you replace the heavy plugin? Optimize its settings? Or do you genuinely need to increase the limit?
Monitor. Leave the memory logging mu-plugin active for a week. Watch for spikes that correlate with cron jobs, backups, or specific user actions.

The whole process takes about an hour for most sites. And it gives you actual data instead of blindly throwing memory at the problem.

Tools That Help

A few tools I use regularly for memory diagnosis:

Query Monitor – Shows memory usage, query count per component, and hooks. Essential for any WordPress developer.
WP Multitool – The System Info module shows your memory limits at a glance, Config Manager lets you toggle debug constants without editing files, and the Autoloader Optimizer helps clean up bloated autoload data. Full disclosure – I built this one.
Code Profiler – If you need deep PHP-level profiling, this generates detailed charts showing which scripts, classes, and functions use the most resources.
PHP’s built-in functions – memory_get_usage() and memory_get_peak_usage() are your friends. They’re simple, accurate, and don’t require any plugin.

The Takeaway

The memory exhausted error is a symptom, not a diagnosis. Increasing the limit without understanding what’s consuming the memory is like turning up the music to ignore a rattling engine.

Measure first. Find the actual consumer. Then decide whether to optimize it, replace it, or genuinely allocate more memory. In most cases I’ve seen, a combination of cleaning up autoloaded data and replacing one heavy plugin solves the problem without touching the memory limit at all.

If you’re seeing memory issues alongside database bloat or general slowness, those problems feed into each other. Fix them together.

Best WooCommerce Configurator Plugins 2026 (Performance Tested)

MakeWPFast — Mon, 22 Jun 2026 08:15:12 +0000

Originally published on https://makewpfast.com/best-woocommerce-configurator-plugins/

Every WooCommerce product configurator plugin promises “lightweight” and “optimized” on its sales page. So I installed 16 of them on a clean WooCommerce 10.6 site and measured what they actually do to your product pages.

The results? Some plugins add literally zero extra kilobytes. Others dump 860KB of JavaScript on every product page – including the WordPress media library. On a product page. Let that sink in.

Table of Contents

How I tested
The results (all 16 plugins)
The good: zero-overhead plugins
The acceptable: under 50KB
The mediocre: 50-100KB
The bad: over 300KB
The ugly: YayExtra
Deep dive: top 6 head-to-head
What to actually pick
The pattern that matters
FAQ

How I tested

Clean WordPress 6.8.3 + WooCommerce 10.6.1 + GeneratePress theme. One simple product. Each plugin installed, activated, and benchmarked on the product page – then removed before testing the next one.

I measured total page weight (HTML + JS + CSS), number of JavaScript and CSS files, and TTFB. All tests ran on the same Docker container with no caching. Three TTFB runs per plugin, averaged.

The baseline WooCommerce product page weighs 535KB across 15 JS files and 9 CSS files. Everything below is the overhead each plugin adds on top of that.

The results

Plugin	Page Weight	Extra Weight	JS Files	CSS Files
STAGGS	535KB	+0KB	15	9
WCB Configurator Builder	535KB	+0KB	15	9
Expivi 3D Configurator	535KB	+0KB	15	9
PPOM Product Addons	535KB	+0KB	15	9
Custom Product Configurator	535KB	+0KB	15	9
Product Configurator (mklacroix)	539KB	+4KB	16	10
Advanced Product Fields	543KB	+8KB	16	10
Simple Product Options	563KB	+28KB	17	10
Visual Product Configurator	565KB	+30KB	18	10
Flexible Product Fields	583KB	+48KB	17	11
WPC Composite Products	599KB	+64KB	18	11
Zakeke Interactive Designer	625KB	+90KB	18	12
ThemeHigh Extra Product Options	627KB	+92KB	17	10
Extra Product Options (ThemeComplete)	858KB	+323KB	20	13
YITH Product Add-Ons	878KB	+343KB	24	12
YayExtra	1,395KB	+860KB	44	16

Benchmarked March 2026 on WooCommerce 10.6.1 + WordPress 6.8.3. Page weight = HTML + JS + CSS, uncompressed.

The good: zero-overhead plugins

Five plugins added literally nothing to product pages that don’t use them. This is how it should work – only load your assets when the product actually has a configurator attached.

STAGGS is the standout here. It’s the most feature-complete of the visual configurators (layer-based PNG stacking, 3D GLB models, conditional logic, formula pricing) and it’s free on WordPress.org with a $59/year pro tier. Zero frontend overhead unless you’ve actually configured a product. 16MB install size is a bit chunky, but that’s disk space, not page weight.

WCB Configurator Builder does the same thing right – Gutenberg-based, supports both PNG layers and GLB 3D models, zero overhead on non-configured products.

Expivi and PPOM also get it right, though Expivi requires a separate SaaS subscription and PPOM had some SQL errors on activation (not great).

The acceptable: under 50KB overhead

Product Configurator for WooCommerce by mklacroix adds just 4KB – one tiny JS file and one small CSS file. Been around since 2015, solid reputation. This is the OG WooCommerce visual configurator.

Advanced Product Fields by Studio Wombat adds 8KB. Smallest install size of all tested plugins at 423KB. If you need simple product fields (text, select, checkbox, color picker) without the visual configurator stuff, this is your best bet for performance.

Plugin Republic’s Simple Product Options adds 28KB. Clean, lightweight. Only loads jQuery UI core as a dependency – nothing crazy.

The mediocre: 50-100KB overhead

Flexible Product Fields by WPDesk adds 48KB. The unminified front-end JS (34KB) tells me they’re not optimizing for production.

WPC Composite Products by WPClever adds 64KB. Loads ddslick (a dropdown library) and imagesloaded on every product page even when the product isn’t a composite. That’s wasteful.

Zakeke adds 90KB, mainly from Glide.js (82KB) – a carousel library. Loads on every product page. Zakeke is a SaaS platform though, so the real performance cost is in the iframe/API calls that happen when you actually configure a product, which this test doesn’t capture.

ThemeHigh Extra Product Options adds 92KB. The big culprit is an unminified 72KB front-end.js. Just minifying it would cut that significantly. Not a great look.

The bad: over 300KB overhead

Extra Product Options by ThemeComplete adds 323KB. It loads jquery.inputmask (145KB!), jQuery UI datepicker, timepicker, and the full dashicons font – all on every product page, even when no fields are configured. That inputmask file alone is bigger than most entire plugins.

YITH Product Add-Ons adds 343KB and 9 extra JavaScript files. Loads SelectWoo (78KB), underscore.js, jQuery UI datepicker, progressbar, wp-util – the works. The TTFB increase was also the highest at 68ms (vs 40ms baseline), suggesting significant PHP overhead too.

The ugly: YayExtra

YayExtra deserves its own section. It adds 860KB to every product page. That’s not a typo.

It loads the entire WordPress media library stack: media-views.min.js (111KB), mediaelement-and-player.min.js (158KB), moxie.min.js (87KB), plupload.min.js, backbone.js, wp-backbone, media-models, media-editor… 44 JavaScript files total. Plus media-views.css, wp-mediaelement.css, dashicons.

This is the WordPress media uploader. On every product page. For your customers. Even when no product options are configured.

Your product page goes from 535KB to 1,395KB. Your visitors are downloading the WordPress admin media library just to view a product. I genuinely don’t understand how this got past code review.

Deep dive: comparing the top 6 head-to-head

The initial test measured “idle” overhead – what happens when the plugin is active but no configurator is attached to the product. That’s useful, but the real question is: how do these plugins behave across your entire site?

I reinstalled the six best-performing plugins and tested them across four page types: product page, shop archive, homepage, and cart. I also dug into their code to compare architecture, dependencies, and build quality.

Asset leakage test: do they pollute your entire site?

This is the test most plugin reviews skip. If a configurator plugin loads JS/CSS on your homepage, your blog, your shop archive – that’s wasted bandwidth on every single page view, not just product pages.

Plugin	Product Page	Shop Archive	Homepage	Cart	Verdict
STAGGS	+0KB	+0KB	+0KB	+0KB	Zero leakage
WCB Configurator	+0KB	+0KB	+0KB	+0KB	Zero leakage
Custom Product Configurator	+0KB	+0KB	+0KB	+0KB	Zero leakage
Product Configurator (mklacroix)	+4KB	+4KB	+4KB	+4KB	Minimal leak
Advanced Product Fields	+8KB	+8KB	+8KB	+8KB	Every page
Visual Product Configurator	+31KB	+31KB	+31KB	+24KB	Every page

Extra page weight added beyond baseline, per page type. “Zero leakage” = wp_register + conditional wp_enqueue only when needed.

Three plugins pass with flying colors: STAGGS, WCB Configurator Builder, and Custom Product Configurator add exactly zero bytes to any page that doesn’t use a configurator.

Product Configurator by mklacroix has a minor leak – it loads a 624-byte general.js and 2.9KB CSS on every page. Small, but unnecessary. Looking at the code, load_scripts() enqueues a base CSS+JS pair before the conditional check runs. Would be trivial to fix.

Advanced Product Fields loads its frontend.min.js (6.3KB) and frontend.min.css (1.3KB) on every single page via unconditional wp_enqueue. No is_product() check anywhere. For a product-addons plugin, this is a clear oversight.

Visual Product Configurator is the worst offender here – fabric.js, accounting.js, oriontip, and its own vpc-public.js load on every page. That’s 31KB of JavaScript your homepage visitors download for absolutely no reason.

Code architecture comparison

Plugin	PHP Files	JS Shipped	Disk Size	Framework	jQuery-Free?	Build Tool
Custom Product Configurator	3	4	1.1MB	React	Yes	Webpack/Babel
Advanced Product Fields	54	2	423KB	jQuery	No	Manual minify
Product Configurator (mklacroix)	304	102	6.1MB	jQuery + Pixi.js	No	npm build
STAGGS	379	201	15.3MB	jQuery (front) / React (admin)	No	npm build
Visual Product Configurator	20	28	18.7MB	jQuery + Fabric.js	No	None visible
WCB Configurator Builder	489	202	19.1MB	jQuery (front) / React (admin)	No	npm build

Custom Product Configurator stands out architecturally. Only 3 PHP files. React-based with a proper webpack build pipeline. Zero jQuery dependency on the frontend – it uses native fetch() for API calls. The leanest codebase by far.

Advanced Product Fields is the smallest install at 423KB and ships only 2 JS + 2 CSS files, all minified. It’s a simple jQuery plugin that does one thing well. If you just need custom fields and nothing visual, this is the most efficient choice.

Product Configurator by mklacroix has the most mature codebase – 304 PHP files with proper namespace structure, 32 minified JS files, and uses Pixi.js for canvas-based layer rendering. It also includes fetch() alongside jQuery, suggesting a gradual modernization effort. It’s the only one (besides APF) with explicit HPOS compatibility declared.

STAGGS and WCB have similar architectures: jQuery on the frontend for the configurator UI, React for the admin panel, Carbon Fields for custom meta. Both ship 200+ JS files but that’s mostly admin/build assets – they’re well-disciplined about what reaches the frontend.

Visual Product Configurator bundles 18.7MB of files for 20 PHP files and no visible build tool. It ships Fabric.js (a canvas library) and FontAwesome as dependencies, loaded unconditionally. The file structure suggests no build pipeline at all.

Dependency quality

Plugin	External JS deps loaded	Minified?	Modern API usage
Custom Product Configurator	None (self-contained React build)	Bundled	fetch(), React 18
Advanced Product Fields	jQuery only	Yes (2/2)	jQuery $.ajax
STAGGS	Swiper, jQuery UI, Lightbox	Yes (7 min files)	jQuery + some fetch()
WCB Configurator	Fabric.js, Lightbox	Partial (8 min files)	jQuery + some fetch()
Product Configurator (mklacroix)	Pixi.js, html2canvas, Tippy, Popper	Yes (32 min files)	jQuery + fetch()
Visual Product Configurator	Fabric.js, FontAwesome, accounting.js, oriontip, serializejson	Partial (15 min files)	jQuery only

Feature comparison: what you actually get

These plugins split into two categories. Visual configurators show a live image preview as customers pick options (think customizing a shoe or a piece of furniture). Product option builders add form fields like text inputs, dropdowns, and checkboxes.

Feature	STAGGS	WCB	Product Config (mkl)	Custom Product Config	VPC (Orion)	APF (Studio Wombat)
Type	Visual	Visual	Visual	Visual	Visual	Form fields
Image layer stacking	Yes	Yes	Yes	No (templates)	Yes	No
3D / GLB models	Pro	Free	No	No	No	No
Multiple views	Yes	Yes	Yes	No	Yes (Pro)	No
Conditional logic	Pro	Pro	Pro	Coming soon	Pro	Pro
Dynamic pricing	Yes	Yes	Yes	Yes	Yes	Yes
Formula-based pricing	Pro	No	Pro	No	No	No
Text/image overlay	Pro	Pro	Pro	No	Pro	No
Save & share configuration	Pro	Pro	Pro	No	Pro	No
PDF download	Pro	Pro	Pro	No	Pro	No
Inventory per option	Pro	Pro	No	No	No	No
AR (try in room)	Pro	No	No	No	No	No
Works without WooCommerce	Yes	Yes	No	No	No	No
WPML / Polylang	Yes	Yes	Yes	No	No	Basic
Analytics	Pro	Pro	No	No	No	No
HPOS compatible	No	No	Yes	No	No	Yes
Free tier available?	Yes	Yes	Yes	Yes	Yes	Yes
Pro pricing	~$59/yr	Not listed	From $49/yr	Coming	Not listed	From $49/yr

Pros and cons: the honest version

STAGGS – Best overall visual configurator

Pros: Zero page weight overhead. Most complete free tier among visual configurators. Layer stacking, multiple views, real-time pricing, 10+ display templates included for free. Pro adds 3D/AR, conditional logic, formula pricing, analytics. Can work as a standalone product builder without WooCommerce. Actively maintained (last update March 2026). Won “Best Ecommerce Product Configurator 2025” from Corporate Vision.

Cons: 15.3MB disk footprint is the second largest (lots of admin React components). jQuery-dependent frontend. No HPOS compatibility declared. Most useful features locked behind Pro ($59/yr).

Best for: Furniture, jewelry, fashion, any product where customers need to see a visual preview.

WCB Configurator Builder – Best for Gutenberg users

Pros: Zero overhead. Gutenberg-native builder (drag & drop in the block editor). Supports both PNG layers AND GLB 3D models in the free version – that’s rare. Visual drag/resize/rotate controls. Newest of the bunch (actively adding features).

Cons: Largest disk footprint at 19.1MB. Smallest user base (1,437 downloads). No HPOS. Gutenberg dependency means it won’t work with Classic Editor. Feature set is less mature than STAGGS or Product Configurator.

Best for: Stores already invested in the block editor who want 3D configurators without paying for Pro.

Product Configurator by mklacroix – Best for developers

Pros: Most mature codebase (since 2015). HPOS compatible. Uses Pixi.js for proper canvas rendering (smoother than DOM-based layer stacking). 32 minified JS files show disciplined build process. Hooks and filters for customization. StellarWP ecosystem (iThemes/Liquid Web backing). 4.8/5 with 42 reviews.

Cons: Leaks 4KB to all pages (minor). 6.1MB install. Heavy jQuery dependency. The pro add-on ecosystem means the “full” product gets expensive fast. Requires WooCommerce (no standalone mode).

Best for: Developers who want hooks/filters and a proven, well-supported plugin backed by a real company.

Custom Product Configurator (zechkonja) – Best code quality

Pros: Cleanest architecture of all tested. Only 3 PHP files. React-based, zero jQuery dependency. Proper webpack build. Native fetch() API. Smallest footprint after APF. Ready-made templates for quick setup. Conditionally loads only on configured products.

Cons: Brand new (very few installs). No conditional logic yet (“coming soon”). No multi-view, no save/share, no PDF. Had PHP warnings on activation (undefined variable in db-install.php). Limited feature set compared to STAGGS or Product Configurator.

Best for: Performance-obsessed developers who need a simple configurator now and don’t mind a newer, less proven plugin.

Visual Product Configurator by Orion Origin – Not recommended

Pros: Large add-on ecosystem (text, form builder, image upload, multiple views). Composite product building support.

Cons: Loads 31KB of assets on every page including homepage. No build pipeline visible. Bundles FontAwesome (loading a full icon font for a configurator). Fabric.js dependency adds weight. 3.4/5 rating (lowest tested). No HPOS. 18.7MB disk for 20 PHP files suggests lots of bundled vendor assets. Last major update Oct 2025.

Best for: Skip this one. STAGGS does everything it does with zero overhead.

Advanced Product Fields by Studio Wombat – Best for simple fields

Pros: Smallest install (423KB). Only 2 JS + 2 CSS files. Clean, focused codebase. HPOS compatible. Does one thing well: custom product fields. Price calculation, conditional logic (Pro), file uploads.

Cons: Loads 8KB on every page (no is_product() check). No visual configurator at all – it’s just form fields. jQuery dependent. Not really a “configurator” in the visual sense.

Best for: Stores that need custom text fields, dropdowns, or checkboxes on products – and nothing more.

What to actually pick

Visual product configurator (layer-based image stacking, 3D models): STAGGS. Zero overhead, most features, actively maintained, free tier available.

Simple product fields (text, dropdowns, checkboxes, color pickers): Advanced Product Fields by Studio Wombat. 8KB overhead, 423KB install, clean code.

Product option builder with conditional logic: Product Configurator for WooCommerce by mklacroix. 4KB overhead, proven track record since 2015.

Composite/kit products: WPC Composite Products. 64KB overhead isn’t ideal but it’s the most complete free composite builder.

3D/AR configurator: STAGGS Pro (supports GLB/GLTF + AR) or Expivi if you need full 3D modeling capabilities and don’t mind the SaaS cost.

The pattern that matters

The #1 performance indicator isn’t the plugin’s feature list – it’s whether the plugin conditionally loads its assets. The good plugins check “does this product actually use my configurator?” before enqueueing scripts. The bad ones dump everything on every product page and hope the browser sorts it out.

If you’re evaluating any configurator plugin not in this list, here’s a quick test: activate it, then check a product page that doesn’t use the configurator. If you see new JS/CSS files in the source – that’s a red flag.

Your customers don’t have your patience. Every extra 100KB is measurably slower on mobile. Pick the lightest tool that does what you need. For more WordPress performance insights, check our plugin performance benchmarks and plugin comparisons.

Frequently Asked Questions

What is the best WooCommerce configurator plugin for performance?

STAGGS is the best overall. It adds zero extra page weight to products that don’t use a configurator, offers the most features in its free tier (layer stacking, multiple views, real-time pricing), and only loads assets on configured product pages. In our benchmark of 16 plugins, it tied for the lightest with WCB Configurator Builder, Custom Product Configurator, Expivi, and PPOM – all at exactly 0KB overhead.

Do WooCommerce product configurator plugins slow down my site?

It depends entirely on the plugin. In our tests, 5 out of 16 plugins added zero overhead when activated. However, others were much worse – YayExtra added 860KB to every product page (loading the entire WordPress media library), and YITH Product Add-Ons added 343KB. The key differentiator is whether the plugin conditionally loads assets only on pages that actually use the configurator.

What is asset leakage in WordPress plugins?

Asset leakage is when a plugin loads its JavaScript and CSS files on pages where they’re not needed – like your homepage, blog, or shop archive. In our deep benchmark, we found that Advanced Product Fields loads 8KB on every page and Visual Product Configurator loads 31KB on every page, even though their functionality is only needed on individual product pages. Well-coded plugins like STAGGS and WCB Configurator use wp_register and conditional checks to only load assets where needed.

Should I use a free or premium WooCommerce configurator?

Start with the free tier. STAGGS, WCB Configurator Builder, Product Configurator by mklacroix, and Advanced Product Fields all have usable free versions. If you need visual layer stacking and dynamic pricing, STAGGS free covers that. Upgrade to Pro only when you need conditional logic, 3D/AR, formula pricing, or PDF downloads. Most stores don’t need those from day one.

What is the lightest WooCommerce product options plugin?

For simple product fields (text, dropdowns, checkboxes), Advanced Product Fields by Studio Wombat is the lightest at just 423KB installed with only 8KB of frontend assets. For visual product configurators specifically, STAGGS and WCB Configurator Builder both add 0KB of overhead to non-configured product pages.

MariaDB 10.11 vs 11.4 for WordPress: Should you update? YES! [Benchmark]

MakeWPFast — Mon, 22 Jun 2026 08:15:11 +0000

Originally published on https://makewpfast.com/mariadb-10-11-vs-11-4-wordpress-benchmark/

Saw a thread on Reddit – someone on Cloudways asking if upgrading MariaDB from 10.11 to 11.4 is worth it for WooCommerce. Everyone had opinions, nobody had numbers.

So I ran the actual benchmarks.

The Setup

Two identical Docker containers, same everything except the database version:

WordPress 6.8.3 with PHP 8.3
WooCommerce active on both
~1,000 posts with meta, categories, tags
200 WooCommerce products with prices and stock
5,000 comments across posts
100 users

One runs MariaDB 10.11.16 (current LTS), the other MariaDB 11.4.10 (new LTS).

Each test ran 20 times. I’m using medians, not averages – outliers don’t mess up the results that way.

The Big One: 40x Faster Subquery Updates

This is the most interesting finding. MariaDB 11.4 added semi-join optimization for UPDATE and DELETE statements. What that means in practice – when your UPDATE uses a subquery (and WordPress plugins do this more than you’d think), 11.4 can now optimize it the same way it optimizes SELECT queries.

Query Type	10.11	11.4	Improvement
UPDATE with subquery	5.086 ms	0.128 ms	97.5% faster (40x)
DELETE with subquery	0.090 ms	0.070 ms	22% faster

That UPDATE went from 5ms to 0.1ms. Think about what that means for plugins running cleanup queries, WooCommerce processing orders, or your spam cleanup cron jobs.

DATE() Queries: 8x Faster

WordPress uses date-based queries everywhere. Archive pages, scheduled posts, date filtering in wp-admin.

The problem with 10.11 – a query like WHERE YEAR(post_date) = 2025 forces a full table scan because the function call kills index usage. MariaDB 11.4 made these “sargable”, meaning the optimizer rewrites them to actually use the index.

Query Type	10.11	11.4	Improvement
DATE function with index	0.630 ms	0.081 ms	87% faster (8x)

Every WordPress archive page benefits from this. That’s a real win.

All 14 SQL Benchmarks

Here’s the full picture – 14 query patterns that simulate what WordPress actually does:

Query	10.11 (ms)	11.4 (ms)	Change
Autoloaded options	0.089	0.077	-13.5%
Single post + meta	0.163	0.150	-8.0%
Archive page (posts+meta+taxonomy)	3.428	3.175	-7.4%
Correlated subquery (top comments)	1.417	1.352	-4.6%
LIKE search	0.103	0.107	+3.9%
Aggregate (posts per category)	0.295	0.232	-21.4%
UPDATE with subquery	5.086	0.128	-97.5%
DELETE with subquery	0.090	0.070	-22.2%
WooCommerce product listing	0.283	0.256	-9.5%
WooCommerce product search	0.392	0.395	+0.8%
WooCommerce price filter	0.243	0.229	-5.8%
Bulk meta read (500 rows)	0.665	0.481	-27.7%
DATE() function index	0.630	0.081	-87.1%
ORDER BY meta value	1.037	0.702	-32.3%

11.4 wins 12 out of 14 tests. The two where 10.11 was “faster” (LIKE search, WooCommerce product search) are within noise – basically identical.

Ok But What About Actual Page Loads?

SQL numbers are nice, but what does it feel like in the browser? I measured TTFB for real WordPress pages:

Page	10.11	11.4	Change
Homepage	28.8 ms	25.9 ms	-10.1%
Single post	26.1 ms	24.5 ms	-6.1%
Category archive	25.6 ms	24.2 ms	-5.5%
WooCommerce shop	30.1 ms	28.8 ms	-4.3%
REST API (10 posts)	50.9 ms	51.8 ms	+1.8%

4-10% faster across the board. Homepage got the biggest boost at 10%.

Worth noting – these are uncached numbers. If you’re running Redis or Memcached, the database differences get smoothed out. But for uncached requests – admin pages, WooCommerce cart, checkout, anything for logged-in users – that’s where 11.4 helps.

Under Concurrent Load

I threw Apache Bench at both environments with different concurrency levels (200 total requests each):

Concurrency	10.11 (req/s)	11.4 (req/s)	Change
1	39.09	39.98	+2.3%
5	162.20	169.12	+4.3%
10	214.03	202.14	-5.6%
25	203.08	204.44	+0.7%

Basically a wash. Slight edge to 11.4 at low concurrency, essentially tied at higher levels. The c=10 dip for 11.4 is probably Docker Desktop noise.

Write Performance

50 posts created via WP-CLI:

Metric	10.11	11.4	Change
Total time	38.8 s	37.8 s	-2.5% faster
Per post	776 ms	757 ms	-2.5% faster

2.5% faster on writes. Nothing dramatic, but it’s not slower either.

Did Anything Break?

No. Zero issues with WordPress 6.8.3, WooCommerce, and PHP 8.3:

No errors
No deprecated warnings
All 14 benchmark queries worked identically
WooCommerce installed and activated fine

WordPress talks to the database through $wpdb, and MariaDB 11.4 keeps full backward compatibility. If it works on 10.11, it’ll work on 11.4.

Should You Upgrade?

Yes, if:

You run WooCommerce – the query improvements directly help product and order queries
Your site has lots of posts (10k+) and uses archive or date-based queries
You use plugins that run batch operations or cleanup queries with subqueries
Your host offers 11.4 as an option (Cloudways, RunCloud, etc.)

Maybe hold off if:

Your 10.11 setup is stable and you have no performance complaints
You can’t easily roll back – test in staging first
You’re running high-traffic WooCommerce – test with your actual data before switching production

Bottom Line

MariaDB 11.4 is worth the upgrade. The optimizer improvements are real, not just synthetic benchmark stuff:

40x faster subquery UPDATE/DELETE – the standout improvement
8x faster date queries – helps every archive page
28-32% faster meta queries – good for page builders and WooCommerce
4-10% faster page loads – measurable TTFB gains

No compatibility issues, no regressions. If your host has 11.4 available, I don’t see a reason not to switch.

How I tested: Two identical Docker containers (WordPress 6.8.3, PHP 8.3, WooCommerce) on macOS Apple Silicon. MariaDB 10.11.16 vs 11.4.10. Each SQL test ran 20 times, median reported. TTFB measured with curl over 10 runs. Concurrent load via Apache Bench, 200 requests per level. Writes via WP-CLI, 50 posts. All on warm databases after initial warmup.

How to Find Which Plugin Is Slowing Down Your WordPress Site

MakeWPFast — Sun, 21 Jun 2026 08:15:10 +0000

Originally published on https://makewpfast.com/find-which-plugin-slowing-down-wordpress/

Your WordPress site is slow. You have 20-something plugins installed and you’re pretty sure one of them is the problem. But which one?

This is probably the most common question I get from site owners. And honestly, the answer isn’t always straightforward – because it’s rarely just one plugin. It’s usually a combination of poorly written callbacks, excessive database queries, and plugins loading assets on every single page whether they need to or not.

Let me walk you through how to actually find which plugin is slowing down your WordPress site, from the basic manual approach to the proper diagnostic tools that show you exactly what’s happening under the hood.

One gut-check before we dig in: this guide assumes your site is slow but still loading. If it isn’t just slow but fully down — white screen, a 500 error, nothing rendering at all — that’s an emergency, not a tuning problem, and emergency WordPress repair can get a crashed WordPress site back online in about an hour. Still up and just sluggish? Then let’s find the culprit.

The Manual Method: Disable One by One

This is what every WordPress tutorial tells you to do. And it works – sort of.

The process is simple:

Deactivate all plugins.
Check your page load time (use your browser’s DevTools network tab or PageSpeed Insights).
Reactivate plugins one at a time.
After each activation, check the load time again.
When the load time jumps, you found your culprit.

Simple, right? Here’s why this method is problematic in practice.

Why the Manual Method Falls Short

It takes forever. If you have 25 plugins, you’re looking at 25+ rounds of deactivate-measure-reactivate. Each measurement should be done 3 times minimum to account for variance. That’s 75 page loads just to find one slow plugin.

It misses interactions. Plugin A might be fine on its own. Plugin B might be fine on its own. But together they trigger something – maybe a shared hook that fires twice, or a conflict that causes redundant database queries. Disable-and-test won’t catch this because you’re testing plugins in isolation.

It doesn’t tell you why. Ok, you found that WooCommerce slows your site by 400ms. Great. Now what? WooCommerce has hundreds of hooks and callbacks. Which specific one is the bottleneck? The manual method can’t tell you that.

Your site is down during testing. If this is a production site, deactivating plugins means breaking functionality for real visitors. Not ideal.

The manual method is fine as a last resort. But there are much better approaches. Let me show you.

Method 2: Query Monitor – Free and Solid

Query Monitor is the go-to debugging plugin for WordPress developers. It’s free, it’s well-maintained by John Blackbourn, and it gives you a detailed breakdown of what happens during every page load.

Install it, activate it, and you’ll see a new toolbar at the top of your admin bar showing page generation time, memory usage, and query count.

What Query Monitor Shows You

The panels you care about for finding slow plugins:

Queries by Component – shows which plugin or theme is responsible for each database query, grouped and sorted. This is huge. If a plugin is running 50 queries per page load, you’ll see it immediately.
Hooks in Use – lists every hook that fired on the current page, with priority, callback function, and the component (plugin/theme) responsible. You can filter by component to see everything a specific plugin is doing.
HTTP API Calls – shows external HTTP requests. This is often where hidden slowness lives. A plugin checking for updates, hitting an external API, or loading remote data on every page load.
Scripts and Styles – shows every CSS and JS file enqueued, by which plugin. If a contact form plugin is loading its assets on your homepage, you’ll see it here.

The Limitation of Query Monitor

Query Monitor is excellent at showing you what happened during a page load. It shows queries, hooks, assets, and HTTP calls grouped by plugin.

But it doesn’t directly time individual hooks and callbacks. You can see that a plugin registered 15 callbacks across various hooks – but you can’t see that one specific callback on wp_head at priority 10 took 200ms while the others took 1ms each.

Query Monitor does have a profiling API where you can manually wrap code sections with do_action( 'qm/start', 'my-timer' ) and do_action( 'qm/stop', 'my-timer' ). But that requires editing code – you need to know where to look first.

For database-heavy plugins, Query Monitor is perfect. For hook-level timing, you need something else.

Method 3: Hook Profiling – Finding the Exact Callback

This is where things get precise. Instead of disabling entire plugins, a hook profiler measures the execution time of every single callback that fires during a page load.

Think of it this way: WordPress processes a request by firing a sequence of hooks – init, wp, template_redirect, wp_head, the_content, wp_footer, etc. Each hook can have dozens of callbacks attached by your theme and plugins. A hook profiler wraps each callback with a timer and reports the results.

This means you don’t just find the slow plugin – you find the slow function. That’s a completely different level of diagnostic information.

What a Hook Profiler Reveals

A proper hook profiler will show you something like:

Callback SomePlugin::generate_critical_css() on hook wp_head at priority 10 – took 340ms
Callback AnotherPlugin::check_license() on hook init at priority 5 – took 180ms (external HTTP call)
Callback ContactFormPlugin::enqueue_assets() on hook wp_enqueue_scripts at priority 10 – took 45ms

Now you’re looking at actionable data. You can see that the CSS generation callback is the biggest bottleneck. You can see that a license check is making an external HTTP request on every page load. You can trace each slow callback to its exact source file and line number.

This is what WP Multitool’s Find Slow Callbacks module does. You profile any page on your site, and it returns a ranked list of every callback by execution time, showing which plugin or theme each belongs to. No guessing, no disabling plugins one by one.

Hook Profiling vs. Query Monitor: When to Use Which

They’re complementary tools, not competitors.

Use Query Monitor when:

You suspect database queries are the bottleneck (it groups queries by plugin and shows slow ones)
You need to debug a specific page template or conditional logic
You want to see which scripts and styles are loading unnecessarily
You’re debugging REST API requests or AJAX calls

Use a hook profiler when:

Page load time is high but query count looks normal
You need to find the exact callback function that’s slow, not just the plugin
You suspect PHP execution time is the problem, not database
A plugin has many hooks and you need to know which specific one is the bottleneck

In my experience, the most effective approach is to start with a hook profile to find the slow callbacks, then use Query Monitor to dig into the database queries those callbacks are generating. Top-down, then bottom-up.

Common Culprits: What Usually Causes Plugin Slowness

After profiling hundreds of WordPress sites, certain patterns keep showing up. Here’s what to look for.

1. External HTTP Requests on Every Page Load

This is the number one performance killer that most people miss. A plugin makes an HTTP request to an external server – to check a license, fetch social counts, load remote data, or verify an API key. Each request adds 200-2000ms depending on the remote server’s response time.

The worst part? These often happen on init or admin_init, meaning they fire on every single page load. Check Query Monitor’s HTTP API Calls panel – if you see external requests that aren’t cached, that’s your problem.

2. Plugins Loading Assets Everywhere

A contact form plugin that loads its CSS and JavaScript on every page, not just the page with the form. A slider plugin loading its library on posts that don’t have sliders. This is incredibly common and adds up fast.

Query Monitor’s Scripts and Styles panel makes this obvious. Look for plugin assets loading on pages where they shouldn’t be. The fix is usually a conditional dequeue or switching to a plugin that handles this properly.

3. Unoptimized Database Queries

Some plugins run queries without proper indexing, or they query the entire wp_options table with autoloaded data they don’t need on every page. I wrote about this specifically in the slow queries guide – it’s a deep topic.

The autoload problem deserves special mention. Plugins that store large serialized arrays in wp_options with autoload=yes are silently adding to every single page load. WP Multitool’s Autoloader Optimizer module specifically addresses this.

4. Redundant Processing in wp_head

The wp_head hook is where a lot of damage happens. Plugins generating inline CSS, computing critical styles, outputting meta tags that require database lookups – all of this runs before any visible content reaches the browser.

Profile your homepage and sort by the wp_head hook. You might be surprised how much time is spent there.

5. Plugin Conflicts Creating Duplicate Work

Two SEO plugins both generating meta tags. Two caching plugins fighting each other. An optimization plugin and a CDN plugin both trying to rewrite URLs. These conflicts don’t just cause errors – they cause slowness through redundant processing.

A Practical Diagnostic Workflow

Here’s the process I actually follow when someone tells me their WordPress site is slow and they want to find the plugin causing it.

Step 1: Establish a Baseline

Before touching anything, measure your current state. Open your browser’s DevTools, go to the Network tab, and do a hard refresh (Ctrl+Shift+R). Note the total page load time and the TTFB (Time to First Byte). TTFB is the important one – it tells you how long the server took to generate the page.

If TTFB is under 200ms, your server-side performance is fine and the problem is likely frontend (too many scripts, unoptimized images). If TTFB is over 500ms, you have a backend problem – and that’s where plugins live.

I outlined a more complete version of this in the diagnostic framework article.

Step 2: Profile the Page

Run a hook profile on the slow page. If you’re using WP Multitool, go to the Find Slow Callbacks module, enter the URL, and hit profile. You’ll get a ranked list of callbacks by execution time.

Look at the top 5 callbacks. They typically account for 80% of the total execution time. Note which plugins they belong to.

Step 3: Investigate the Slow Callbacks

Now you know which callbacks are slow. The question is why.

Open Query Monitor and navigate to the page. Check the Queries by Component tab for the plugins you identified. Are they running expensive queries? Are they making external HTTP calls? Are they doing heavy PHP computation?

This combination – hook profiler to find the slow callbacks, Query Monitor to understand why they’re slow – gives you the complete picture.

Step 4: Fix or Replace

Once you know the exact callback and the reason it’s slow, you have options:

Disable the feature – if the plugin has a setting to turn off the slow functionality, use it.
Dequeue unnecessary assets – if the plugin loads scripts/styles everywhere, conditionally remove them.
Add caching – if a callback runs expensive queries, a transient cache might help.
Replace the plugin – sometimes the plugin is just poorly written. Find an alternative.
Report to the developer – with specific callback and timing data, the developer can actually fix it.

What About P3 (Plugin Performance Profiler)?

You might see older articles recommending P3 Plugin Performance Profiler. Don’t use it. It hasn’t been updated since 2017, it’s not compatible with modern PHP versions, and it can actually crash your site. The WordPress plugin directory still lists it but it’s effectively abandoned.

Code Profiler is a more modern alternative if you want a free standalone profiling plugin. It generates detailed charts showing execution time per file and function. The reports are comprehensive – maybe too comprehensive for a quick diagnosis, but great for deep dives.

The “Is It Really a Plugin?” Check

Before you spend hours hunting for a slow plugin, make sure the problem is actually a plugin. Sometimes slow WordPress sites are caused by:

Slow hosting – if your TTFB is 2+ seconds with zero plugins, it’s not a plugin problem. It’s your server.
Theme issues – themes can be just as slow as plugins. The same diagnostic process applies.
Database bloat – millions of post revisions, spam comments, expired transients. Check the database bloat guide.
No page caching – without caching, WordPress regenerates every page from scratch. That’s slow by design.
wp-config.php misconfiguration – wrong memory limits, debug mode left on in production. See the wp-config tuning guide.

If your admin dashboard is specifically slow, that’s a different diagnostic path – admin-only plugins and dashboard widgets are often the cause there.

Bottom Line

Finding which plugin is slowing down your WordPress site doesn’t have to be a guessing game. The disable-one-by-one method works but it’s slow, disruptive, and doesn’t give you the full picture.

Better approach: profile first, investigate second, fix third. A hook profiler tells you which callbacks are slow. Query Monitor tells you why. Together they give you precise, actionable information instead of trial and error.

The number of plugins you have installed matters way less than the quality of those plugins. I’ve seen sites with 40 plugins loading in under a second, and sites with 8 plugins taking 4 seconds. It’s not about quantity – it’s about what each plugin actually does on every request.

Profile your site. Look at the data. Fix what’s actually slow.

And if you’d rather hand the whole process to someone who does this daily, a WordPress performance audit covers exactly these steps – profiling, query analysis, and a prioritized fix list.

WordPress REST API Performance: Disable What You Don’t Need

MakeWPFast — Sun, 21 Jun 2026 08:15:09 +0000

Originally published on https://makewpfast.com/wordpress-rest-api-performance-disable-what-you-dont-need/

Every WordPress request to /wp-json/ boots the entire REST API infrastructure. That means 40+ endpoint controllers get instantiated, routes get registered, and hooks fire – even if the request only needs one endpoint.

Most WordPress sites don’t need 90% of these endpoints. But they’re all there, loaded and ready, on every single REST request. And on non-REST requests, WordPress still outputs REST discovery links in your HTML head and HTTP headers.

Here’s what’s actually happening, which endpoints are safe to remove, and how to audit what’s hitting your REST API.

What the REST API Loads on Every Request

Even on regular frontend page loads, WordPress adds two things related to the REST API:

A `tag inwp_headviarest_output_link_wp_head` (priority 10)
A Link: HTTP header via rest_output_link_header on template_redirect (priority 11)

These are minor. The real cost comes when something actually hits /wp-json/.

When a REST request comes in, WordPress calls rest_api_loaded() from parse_request, which triggers rest_get_server() and fires the rest_api_init hook. Inside that hook, create_initial_rest_routes() runs at priority 99 and registers every single default endpoint controller.

I counted them in WordPress 6.7 core. Here’s the full list of controllers that get instantiated:

Posts, pages, and every custom post type with show_in_rest => true
Revisions and autosaves for each of those
Post types and post statuses
Taxonomies and terms
Users and application passwords
Comments
Search (posts, terms, post formats)
Block renderer, block types, blocks
Settings
Themes and plugins
Sidebars, widget types, widgets
Block directory and pattern directory
Block patterns and block pattern categories
Site health
URL details
Menu locations
Site editor export
Navigation fallback
Font collections
Abilities (categories, run, list)

That’s 40+ controller classes. Each one calls register_routes(), which means regex patterns get compiled for every route. On a site with WooCommerce, Yoast, or any plugin that adds REST endpoints, you can easily hit 200+ registered routes.

The Security Problem: User Enumeration

Here’s the part most people miss. By default, anyone can hit:

`php https://yoursite.com/wp-json/wp/v2/users `

And get back a JSON response with usernames, user IDs, and profile URLs. No authentication needed.

This is a known attack vector – CVE-2017-5487 originally, but the behavior still exists by design. Attackers use it to harvest usernames for brute-force login attempts. Combined with XML-RPC’s system.multicall (which you should already have disabled – see our XML-RPC security guide), it gives attackers everything they need to start password spraying.

How to Audit Which Endpoints Are Being Hit

Before you start removing things, figure out what’s actually being used. There are a few ways to do this.

Method 1: Server Access Logs

If you have access to your server logs, filter for /wp-json/:

`php grep "wp-json" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20 `

This shows you which REST endpoints get the most traffic. You might be surprised – on most sites, it’s the block editor endpoints and heartbeat-related calls from the admin.

Method 2: WordPress Debug Logging

Add a quick logger to see REST requests in real time:

`php add_filter( 'rest_pre_dispatch', function( $result, $server, $request ) { if ( defined( 'WP_DEBUG_LOG' ) && WP_DEBUG_LOG ) { error_log( sprintf( 'REST API: %s %s (user: %d)', $request->get_method(), $request->get_route(), get_current_user_id() ) ); } return $result; }, 10, 3 ); `

Run this for a day, then check wp-content/debug.log. You’ll see exactly what’s calling what.

Method 3: Query Monitor

The Query Monitor plugin shows REST API calls in its HTTP API panel. Good for development, but don’t run it in production.

Which Endpoints Are Safe to Disable

This depends on your setup. Here’s my breakdown:

Safe to Remove on Most Sites

These endpoints serve the block editor, widget system, and site editor. If you’re using a classic theme (like GeneratePress) and the classic editor, you don’t need them:

/wp/v2/block-renderer – Block rendering
/wp/v2/block-types – Block type definitions
/wp/v2/blocks – Reusable blocks
/wp/v2/block-directory – Block directory search
/wp/v2/block-patterns – Block patterns
/wp/v2/block-pattern-categories – Block pattern categories
/wp/v2/sidebars – Widget sidebars
/wp/v2/widget-types – Widget type definitions
/wp/v2/widgets – Widgets
/wp/v2/navigation – Navigation fallback
/wp/v2/templates – Site editor templates
/wp/v2/template-parts – Template parts
/wp/v2/global-styles – Global styles
/wp/v2/menu-locations – Menu locations (REST)
/wp/v2/font-collections – Font collections
/wp/v2/font-families – Font families

Safe to Restrict to Authenticated Users

These leak information publicly but are needed for admin functionality:

/wp/v2/users – Disable for unauthenticated requests (user enumeration)
/wp/v2/settings – Site settings
/wp/v2/plugins – Plugin list
/wp/v2/themes – Theme information
/wp/v2/site-health – Site health data

Don’t Touch These

/wp/v2/posts and /wp/v2/pages – Needed if anything reads your content via API
/wp/v2/media – Image uploads from the editor
/wp/v2/categories and /wp/v2/tags – Taxonomy queries
/wp/v2/comments – Comment system (if you use it)
/wp/v2/search – Site search

The Code: Removing Unnecessary Endpoints

Here’s a practical mu-plugin that removes endpoints you don’t need. Drop this in wp-content/mu-plugins/:

`php
<?php
/**

Plugin Name: Disable Unused REST API Endpoints
Description: Removes REST API endpoints that aren't needed on this site. */

add_filter( 'rest_endpoints', function( $endpoints ) {
// Block editor endpoints (safe to remove with classic editor)
$remove_patterns = array(
'/wp/v2/block-renderer',
'/wp/v2/block-types',
'/wp/v2/blocks',
'/wp/v2/block-directory',
'/wp/v2/block-patterns',
'/wp/v2/block-pattern-categories',
'/wp/v2/sidebars',
'/wp/v2/widget-types',
'/wp/v2/widgets',
'/wp/v2/navigation',
'/wp/v2/templates',
'/wp/v2/template-parts',
'/wp/v2/global-styles',
'/wp/v2/menu-locations',
'/wp/v2/font-collections',
'/wp/v2/font-families',
'/wp/v2/font-faces',
);

foreach ( $endpoints as $route => $endpoint ) {
    foreach ( $remove_patterns as $pattern ) {
        if ( strpos( $route, $pattern ) === 0 ) {
            unset( $endpoints[ $route ] );
            break;
        }
    }
}

return $endpoints;

} );
`

Blocking User Enumeration

This one’s non-negotiable. Restrict the users endpoint to authenticated requests:

`php add_filter( 'rest_endpoints', function( $endpoints ) { if ( ! is_user_logged_in() ) { if ( isset( $endpoints['/wp/v2/users'] ) ) { unset( $endpoints['/wp/v2/users'] ); } if ( isset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] ) ) { unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] ); } } return $endpoints; } ); `

After adding this, test it:

`php curl -s https://yoursite.com/wp-json/wp/v2/users | head -c 200 `

You should get a rest_no_route error instead of a list of usernames.

Removing REST API Discovery Links

If you don’t expose any public API, remove the discovery links from your HTML:

`php
// Remove from wp_head
remove_action( 'wp_head', 'rest_output_link_wp_head', 10 );

// Remove Link: header
remove_action( 'template_redirect', 'rest_output_link_header', 11 );
`

These are in wp-includes/default-filters.php at lines 331-332. Removing them saves a small amount of HTML output and stops advertising your API endpoint to scanners.

The Nuclear Option: Require Authentication for Everything

If your site doesn’t serve any public REST API consumers (no headless frontend, no mobile app, no external integrations), you can lock down the entire API:

`php
add_filter( 'rest_authentication_errors', function( $result ) {
if ( true === $result || is_wp_error( $result ) ) {
return $result;
}

if ( ! is_user_logged_in() ) {
    return new WP_Error(
        'rest_not_logged_in',
        'REST API access restricted.',
        array( 'status' => 401 )
    );
}

return $result;

} );
`

Warning: This breaks any plugin that makes unauthenticated REST calls from the frontend. Contact Form 7, some caching plugins, and various page builders use the REST API from the browser without authentication. Test thoroughly.

What About Performance Impact?

I want to be honest here – the performance gain from removing REST endpoints on non-REST requests is zero. The rest_api_init hook only fires when something actually hits /wp-json/. On regular page loads, removing endpoints changes nothing.

Where it matters:

Admin pages – The block editor makes dozens of REST calls. Fewer registered routes means slightly faster route matching.
REST-heavy plugins – WooCommerce, Jetpack, and similar plugins add their own endpoints. The more routes registered, the longer route matching takes.
Security scanning – Bots constantly probe /wp-json/wp/v2/users. Returning a 401 early saves processing time compared to running the full users query.

The real win is security, not speed. But if you’re running a site that serves REST API responses at scale (headless WordPress, mobile app backend), trimming unused routes does reduce the regex matching overhead in WP_REST_Server::dispatch().

Monitoring REST API Usage with WP Multitool

If you’re using WP Multitool, the Slow Query Analyzer and Find Slow Callbacks modules help you spot REST API-related performance issues. The Slow Query Analyzer catches expensive database queries triggered by REST endpoints, while Find Slow Callbacks profiles hooks – including those firing on rest_api_init. This is particularly useful for finding plugins that register heavy callbacks on REST requests when they shouldn’t be.

Quick Checklist

Before you deploy any of these changes:

Audit first – Log REST requests for at least 24 hours before removing anything
Test the block editor – If you use Gutenberg, don’t remove block-related endpoints
Check contact forms – Many form plugins use REST API for submissions
Verify after deployment – Hit /wp-json/ and confirm removed endpoints are gone
Monitor error logs – Watch for rest_no_route errors from legitimate functionality

Related guides that complement this one:

The Complete wp-config.php Performance Tuning Guide covers WP_DEBUG_LOG setup and other performance constants
How to Properly Defer JavaScript in WordPress – because the REST API isn’t the only thing loading unnecessary resources
XML-RPC in WordPress – the other legacy endpoint you should disable

The REST API isn’t going anywhere – WordPress core depends on it. But there’s no reason to serve 200+ routes when your site only uses 10 of them. Trim the fat, lock down the users endpoint, and monitor what’s actually being requested. That’s the pragmatic approach.

Object Cache in WordPress: Redis vs Memcached vs Nothing

MakeWPFast — Sat, 20 Jun 2026 08:15:12 +0000

Originally published on https://makewpfast.com/wordpress-object-cache-redis-vs-memcached/

Every WordPress page load runs dozens of database queries. Options, user meta, transients, post data – the same stuff gets fetched over and over. That’s where the WordPress object cache comes in. It stores query results in memory so WordPress doesn’t have to hit the database every single time.

But here’s what most “Redis vs Memcached” articles get wrong – they jump straight to the comparison without explaining what the object cache actually does. So let’s fix that.

What the WordPress Object Cache Actually Does

WordPress has a built-in object cache. It’s been there since version 2.5. Every time WordPress fetches an option, loads post meta, or grabs user data, it stores the result in a PHP array using wp_cache_set(). The next time that same data is needed during the request, it calls wp_cache_get() and grabs it from memory instead of running another SQL query.

Here’s the thing most people miss – the default object cache only lives for one request. When the page finishes loading, all that cached data is gone. The next visitor triggers the same queries all over again.

That’s the default behavior. No plugin needed. WordPress does it out of the box.

Where It Gets Interesting

A persistent object cache changes the game. Instead of storing data in a PHP array that dies with the request, it stores it in an external memory store – like Redis or Memcached. Now that cached data survives between requests. Visitor A loads the homepage and populates the cache. Visitor B gets the cached version without touching the database at all.

The mechanism is a WordPress “drop-in” – a special file called object-cache.php placed in wp-content/. WordPress checks for this file on every request. If it exists, WordPress uses it instead of the default WP_Object_Cache class. That’s how Redis or Memcached plugins hook into the system.

When You Actually Need a Persistent Object Cache

Not every site needs one. Here’s when it matters:

You probably need it if:

Your site runs WooCommerce or a membership plugin with logged-in users (page cache doesn’t help much for authenticated requests)
You have a high-traffic site with complex queries – especially dynamic pages that can’t be page-cached
Your admin dashboard is slow – object cache dramatically speeds up the backend
You’re seeing hundreds of database queries per page load

You probably don’t need it if:

You run a simple blog with mostly anonymous visitors and a page cache plugin
Your hosting doesn’t support Redis or Memcached (shared hosting often doesn’t)
You have fewer than 1,000 daily visitors and no complex plugins

The key insight is that object cache complements page cache – it doesn’t replace it. Page cache serves complete HTML pages. Object cache reduces database queries for content that can’t be page-cached. If you’re curious about what’s actually slowing down your queries, check out how to find and fix slow WordPress queries.

Redis vs Memcached: The Real Differences

Ok, the comparison everyone came for. I’m not going to fabricate benchmark numbers – the raw speed difference between Redis and Memcached is negligible for WordPress object caching. Both operate in microseconds. What matters are the architectural differences.

Data Persistence

Redis can persist data to disk. If your Redis server restarts, the cache can be restored from the last snapshot. Memcached is purely in-memory – restart it and everything is gone.

For WordPress, this matters less than you’d think. A cold cache rebuilds itself within a few page loads. But if you’re running a large WooCommerce store with millions of cached keys, a warm restart is nice to have.

Data Structures

Redis supports strings, lists, sets, sorted sets, hashes, and more. Memcached is strictly key-value with string values.

For basic WordPress object caching, this difference is mostly irrelevant – WordPress stores serialized PHP data as strings either way. But if you’re building custom functionality that uses the cache directly, Redis gives you more flexibility.

Memory Management

Memcached uses a slab allocator. It pre-allocates memory in chunks and assigns items to the closest matching slab size. This is efficient but can waste memory when your cached items vary wildly in size.

Redis allocates memory on demand using standard system allocators (jemalloc by default). More flexible, but can fragment over time.

Both let you set a maximum memory limit. Both evict old keys when they hit the limit. Redis gives you more eviction policies to choose from (LRU, LFU, random, volatile-based).

Replication and High Availability

Redis has built-in replication. You can set up Redis Sentinel for automatic failover or use Redis Cluster for horizontal scaling. Memcached has no native replication – you’d need external tools.

For most WordPress sites, this is overkill. But if you’re running a high-availability setup behind a load balancer, Redis makes the infrastructure simpler.

Observability

Redis wins here. You can inspect keys, check memory usage per key, monitor commands in real-time with MONITOR, and get detailed stats with INFO. Memcached’s stats command gives you the basics but you can’t easily peek at individual keys or their sizes.

When you’re debugging why your object cache is eating 512MB of RAM, Redis makes the investigation much easier.

WordPress Plugin Ecosystem

Redis has better WordPress plugin support. Object Cache Pro (paid) and Redis Object Cache (free) are both mature and well-maintained. For Memcached, the options are more limited and less actively developed.

Quick Comparison

Feature	Redis	Memcached
Data persistence	Yes (RDB/AOF)	No
Data structures	Strings, lists, sets, hashes, etc.	Strings only
Replication	Built-in (Sentinel, Cluster)	None (needs external tools)
Memory efficiency	Good, can fragment	Good, slab allocator
Max memory eviction	6 policies (LRU, LFU, etc.)	LRU only
Key inspection	Full (SCAN, DEBUG OBJECT)	Limited
Multi-threaded	Single-threaded (I/O threads in 6.0+)	Multi-threaded
WordPress plugins	Excellent (Object Cache Pro, Redis Object Cache)	Limited

My Recommendation

Use Redis. Not because it’s faster for basic key-value operations – it’s not meaningfully different. But because the ecosystem is better, the debugging tools are better, and the WordPress plugin options are better maintained.

The only scenario where I’d pick Memcached is if it’s already running and working on your server and you don’t want to touch the infrastructure. If you’re setting up from scratch, Redis is the way to go.

How to Verify Your Object Cache Is Working

Installing a Redis plugin and hoping for the best isn’t enough. You need to verify it’s actually doing something.

Check the Drop-In Status

In WP admin, go to Plugins > Drop-ins. You should see object-cache.php listed there. If it’s missing, the persistent cache isn’t active – regardless of what your caching plugin says.

You can also check via WP-CLI:

wp cache type

This should return something like Redis or Memcached. If it says WP_Object_Cache, you’re running the default non-persistent cache.

Check Hit Rates

A healthy object cache should have a hit rate above 85%. If you’re seeing lower numbers, something is wrong – either the cache is too small, keys are expiring too fast, or a plugin is flushing the cache constantly.

With Redis, you can check from the command line:

redis-cli INFO stats | grep keyspace

The keyspace_hits and keyspace_misses numbers tell you the real story. Calculate: hits / (hits + misses) * 100.

Use WP Multitool’s Cache Analyzer

WP Multitool includes a cache analyzer that shows you exactly what’s being cached, how much memory each group uses, and your hit/miss ratio. It’s useful for finding plugins that abuse the object cache or store way too much data. It also flags when your autoloaded options are filling up the cache with data that shouldn’t be there.

Common Gotchas

I’ve seen these issues come up over and over. Save yourself the debugging.

1. The object-cache.php Conflict

Only one object-cache.php drop-in can exist at a time. If you install Redis Object Cache but you already have a Memcached drop-in, or if a managed hosting provider has their own drop-in, you’ll get conflicts. The WordPress Performance Lab plugin has documented this issue – when multiple plugins try to manage the same drop-in file, things break silently.

Before installing any object cache plugin, check if wp-content/object-cache.php already exists and who put it there.

2. Memory Limits Too Low

The default Redis maxmemory is often 64MB. For a WooCommerce store or a site with lots of plugins, that fills up fast. When it does, Redis starts evicting keys, your hit rate tanks, and you’re back to hammering the database.

Set a realistic memory limit. For most WordPress sites, 128-256MB is a good starting point. Monitor usage and adjust.

3. SAVEQUERIES and WP_DEBUG in Production

This is a sneaky one. If WP_DEBUG or SAVEQUERIES is enabled, Object Cache Pro and similar plugins will store backtraces for every cache operation. This is incredibly memory-intensive and can cause PHP fatal errors from memory exhaustion. Never run these in production.

Check your wp-config.php – make sure both are false on production.

4. Plugins Flushing the Cache Constantly

Some plugins call wp_cache_flush() way too aggressively. Every time the cache is flushed, everything has to be rebuilt from the database. I’ve seen plugins that flush the entire object cache on every post save.

If your cache hit rate is suspiciously low, this is likely the cause. You can monitor Redis commands to catch the culprit:

redis-cli MONITOR | grep FLUSHDB

Then trace back which plugin is triggering it.

5. Transients Behavior Changes

Here’s something most people don’t know – when you install a persistent object cache, WordPress stops storing transients in the database. Instead, they go to the object cache. This is usually a good thing (less database bloat), but it means transients are now subject to cache eviction. If you have plugins that rely on transients persisting for days, they might break when Redis evicts them under memory pressure.

6. Serialization Overhead

WordPress serializes every object before storing it in the cache. For large objects – like a complex WP_Query result with 500 posts – the serialization/unserialization cost can actually be higher than just running the query again. This is rare, but worth knowing if you’re caching custom data.

The “Do Nothing” Option

Here’s the part most articles skip. Sometimes the best object cache is no persistent object cache at all.

The default WordPress object cache still works within each request. If your site is mostly anonymous visitors with a page cache serving 95% of requests, adding Redis complexity might not be worth it. The pages that bypass the page cache (admin, AJAX, WP-Cron) might not generate enough database load to justify another service in your stack.

Start by looking at your actual database query count and load. If you’re seeing 50-80 queries per page and your database server isn’t stressed, you might not need Redis at all. Focus on optimizing your database first – clean up bloated tables, fix missing indexes, reduce autoloaded data.

Object cache is a tool, not a requirement. Use it when the data tells you it’s needed.

WordPress Multisite Performance: Scaling to 50+ Sites Without Dying

MakeWPFast — Sat, 20 Jun 2026 08:15:11 +0000

Originally published on https://makewpfast.com/wordpress-multisite-performance-scaling/

If you’re running a WordPress multisite with 20+ client sites and wondering why the admin dashboard takes 8 seconds to load – yeah, I’ve been there. Multisite is one of those WordPress features that sounds incredible in theory and slowly crushes your server in practice.

The problem isn’t multisite itself. It’s that nobody tells you how the database architecture actually works under the hood, and by the time you figure it out, you’ve got 40 client sites on a single MySQL instance and your agency’s reputation is taking hits.

This guide covers what actually matters when scaling WordPress multisite for agency use – database architecture, plugin activation strategy, object caching, domain mapping overhead, and the specific bottlenecks that show up around the 30-50 site mark.

How Multisite Database Architecture Actually Works

Before optimizing anything, you need to understand what WordPress does to your database when you add a site to the network.

WordPress multisite uses a shared database with per-site table prefixes. Every time you create a new subsite, WordPress generates a full set of tables for that site with a numeric prefix. Site 2 gets wp_2_posts, wp_2_postmeta, wp_2_options, wp_2_comments, and so on. Site 47 gets wp_47_posts, wp_47_postmeta, etc.

Each site generates roughly 9-12 tables depending on active plugins. So at 50 sites, you’re looking at 500-600 tables in a single MySQL database. At 100 sites, over 1,000 tables.

But here’s the part that catches people off guard – some tables are shared across the entire network:

wp_users and wp_usermeta – all user accounts across all sites
wp_blogs – registry of every site in the network
wp_site and wp_sitemeta – network-level configuration
wp_registration_log and wp_signups – signup data

This is logical isolation, not physical isolation. Every site’s data lives in the same MySQL instance, sharing the same connection pool, the same query optimizer, and the same InnoDB buffer pool.

The Shared Tables Problem

The wp_users and wp_usermeta tables are the first bottleneck you’ll hit at scale.

Every site in the network shares these tables. If you’re an agency managing 50 client sites with 20 users each, that’s 1,000 users in wp_users and potentially 50,000+ rows in wp_usermeta. Each user gets capability metadata per site they belong to – wp_2_capabilities, wp_3_capabilities, etc., all stored as rows in the same wp_usermeta table.

Run this query on your multisite to see the damage:

SELECT COUNT(*) FROM wp_usermeta;
SELECT COUNT(DISTINCT user_id) FROM wp_usermeta;

If wp_usermeta is over 100K rows, you’re already in territory where user-related queries on the network admin screen start to lag. WordPress knows this too – the wp_is_large_network() function kicks in at 10,000 users and defers real-time user counts to background cron jobs instead of calculating them on every admin page load.

For agencies, the fix is straightforward: don’t add users to sites they don’t need access to. Sounds obvious, but I’ve seen multisite networks where every client admin was added to every site “just in case.”

The wp_options Autoload Trap (Multiplied by 50)

If you’ve read about WordPress autoload being a hidden performance killer, you already know the problem. On multisite, it’s that problem multiplied by every site in your network.

Each site has its own wp_{n}_options table, and each one loads all autoload='yes' rows on every request to that site. A plugin that dumps 500KB of serialized data into autoloaded options is bad on a single site. On multisite with 50 sites, that same plugin is creating that overhead independently on each site.

The tricky part – network-activated plugins write their settings to every site’s options table when they initialize. If you network-activate a plugin that stores large option values, you’ve just added that bloat to every site in one click.

Check your per-site autoload size:

SELECT CONCAT('wp_', blog_id, '_options') AS table_name,
       blog_id
FROM wp_blogs
WHERE archived = 0 AND deleted = 0;

Then for any specific site:

SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_2_options
WHERE autoload = 'yes';

If any site is over 1MB of autoloaded data, that’s a problem. Over 2MB and you’ll feel it on every page load. I’ve written more about cleaning up database bloat – the same techniques apply per-site on multisite, you just need to do it across all sites.

Network Activate vs. Per-Site Activate – It Actually Matters

This is where most agencies get lazy, and it costs them.

Network-activating a plugin means it runs on every single site in the network. The Super Admin enables it globally, and individual Site Admins can’t deactivate it. Convenient? Sure. But it means every page load on every site processes that plugin’s code, fires its hooks, runs its init routines – even on sites that don’t need it.

The better approach for agencies:

Network activate: Security plugins, object cache drop-in, essential mu-plugins, your agency’s maintenance plugin
Per-site activate: WooCommerce (only on commerce sites), page builders, contact form plugins, anything site-specific

If only 5 out of 50 sites need WooCommerce, network-activating it means 45 sites are loading WooCommerce’s entire bootstrap on every request for no reason. WooCommerce alone adds 10-20 extra database queries per page load and consumes additional PHP memory.

For must-use plugins that should be network-wide but lightweight, put them in wp-content/mu-plugins/. These load before regular plugins and can’t be deactivated through the admin – perfect for agency infrastructure code.

switch_to_blog() – The Silent Performance Killer

If you’re writing custom code for your multisite network, this is the function that’ll trip you up.

switch_to_blog() lets you temporarily switch context to another site to access its data. Sounds handy. The problem is what happens under the hood – WordPress reloads the target site’s options into memory, clears relevant object cache entries, and reinitializes taxonomies and post types. Then restore_current_blog() does it all again in reverse.

One switch is fine. A loop switching through 50 sites? That’s been benchmarked at over 2 seconds without caching. At 100 sites, you’re looking at delays that make the operation impractical for any real-time request.

This matters for agencies because common tasks trigger these loops – generating cross-site reports, checking plugin versions across the network, or displaying “recent posts from all sites” widgets. If your network admin dashboard is painfully slow, switch_to_blog loops are likely the cause.

The fix: use direct database queries instead of switching context. If you need data from wp_15_posts, just query it directly:

global $wpdb;
$posts = $wpdb->get_results(
    "SELECT ID, post_title FROM {$wpdb->base_prefix}15_posts
     WHERE post_status = 'publish'
     ORDER BY post_date DESC
     LIMIT 10"
);

Not as elegant as using the WordPress API, but at 50+ sites, elegance takes a back seat to page load times.

Domain Mapping and sunrise.php Overhead

If you’re running client sites on multisite, each client probably wants their own domain. That means domain mapping.

Good news – since WordPress 4.5, domain mapping is native. You don’t need a plugin for it. Just go to Network Admin > Sites, edit the site, and change the Site Address to the custom domain. Make sure DNS points to your server and SSL is configured.

The sunrise.php drop-in is where things get interesting from a performance perspective. This file executes extremely early in the WordPress loading sequence – before mu-plugins, before regular plugins, before the theme. It runs on every single request to your network.

The key constraint: sunrise.php can’t access the database or most WordPress functions. It’s limited to pure PHP and setting constants. This is by design – executing expensive operations at this stage would slow down every request across every site.

If you’re using a legacy domain mapping plugin that still relies on sunrise.php (like the old WordPress MU Domain Mapping plugin), check what it’s actually doing in there. Some older implementations made database queries in sunrise.php, which is a performance hit on every request. With native domain mapping in modern WordPress, you can often remove sunrise.php entirely.

Add to your wp-config.php if you need sunrise.php:

define( 'SUNRISE', true );

And if you’re getting cookie issues after domain mapping, this helps:

define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

I’ve covered more wp-config.php settings in the complete wp-config.php performance tuning guide – some of those settings are especially important on multisite.

Object Caching – Non-Negotiable at Scale

Running multisite with 20+ sites without Redis or Memcached is asking for trouble. The math is simple – each site generates its own set of database queries for options, posts, transients, and user data. Multiply that by the number of active sites and concurrent visitors, and your MySQL server is doing way more work than it needs to.

Redis object caching on multisite can reduce database queries by 50-80%. In one IEEE study, the performance difference was significant enough that researchers found MySQL CPU usage dropped by 25% and network traffic by up to 94% when proper object caching was in place.

There’s a catch with multisite though – cache isolation. By default, all sites in a network share the same Redis database. When you flush the cache (which plugins love to do), it clears the cache for every site, not just the one that triggered it.

You can isolate per-site caches using unique key prefixes or separate Redis database numbers. If you’re using the Redis Object Cache plugin, set this in wp-config.php:

define( 'WP_REDIS_PREFIX', 'site_' . get_current_blog_id() . ':' );

Or better – just use WP_CACHE_KEY_SALT which most object cache implementations respect:

define( 'WP_CACHE_KEY_SALT', 'mynetwork_' );

The salt gets combined with the blog ID automatically, so each site already gets isolated cache keys. What you want to prevent is one plugin’s aggressive cache flush wiping out cached data for all 50 sites.

Database Scaling Beyond 50 Sites

At 50+ sites, your single MySQL instance is handling 500+ tables, shared user queries, and concurrent requests from multiple sites. Here’s when you need to think about scaling the database layer.

Read replicas: Route read queries (which are 90%+ of WordPress queries) to replica servers. The HyperDB or LudicrousDB drop-ins handle this – they’re database abstraction layers that route queries to different servers based on the table being accessed. This is a real option for agencies running 50-100 sites.

Query monitoring: Enable slow query logging on your MySQL server. On multisite, you’ll often find that the slowest queries come from wp_usermeta JOINs and wp_options autoload queries – the shared tables and per-site options.

Table optimization: Run OPTIMIZE TABLE on your largest per-site tables periodically. With hundreds of tables, this needs to be scripted:

#!/bin/bash
# Optimize all WordPress multisite tables
mysql -u root -p your_database -e "
SELECT CONCAT('OPTIMIZE TABLE \`', TABLE_NAME, '\`;')
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database'
AND TABLE_NAME LIKE 'wp\_%'
AND DATA_FREE > 1048576
" --skip-column-names | mysql -u root -p your_database

This only optimizes tables with more than 1MB of fragmented space, which keeps the operation fast.

The Practical Checklist for Agency Multisite

If you’re managing 20-100 client sites on multisite, here’s what actually moves the needle:

Install Redis object caching – this alone is probably the single biggest performance improvement. Not optional past 10 sites.
Audit plugin activation scope – network activate only what every site needs. Per-site activate everything else. This reduces memory usage and database queries on sites that don’t need specific plugins.
Clean autoloaded options per site – check each site’s options table for bloated autoload data. Transients, orphaned plugin settings, serialized blobs – they all add up.
Remove unused sites – archived and deactivated sites still have their tables in the database. If a client left 6 months ago, export and delete that site. Fewer tables = faster schema operations.
Avoid switch_to_blog loops – if you’ve got custom code or plugins that iterate over all sites, replace them with direct queries or batch operations via WP-CLI.
Use WP-CLI for maintenance – wp site list combined with xargs lets you run operations across all sites without the overhead of switch_to_blog:

wp site list --field=url | xargs -I {} wp --url={} transient delete --expired

Monitor per-site performance independently – a slow site in your network affects the shared database resources. Use query monitoring to identify which site is being the noisy neighbor.
Consider the wp_is_large_network threshold – at 10,000 users, WordPress defers user counts to cron. If your network admin is slow before that threshold, lower it:

add_filter( 'wp_is_large_network', function( $is_large, $component, $count ) {
    if ( 'users' === $component && $count > 2000 ) {
        return true;
    }
    return $is_large;
}, 10, 3 );

When to Abandon Multisite

I know this isn’t what you want to hear in an article about scaling multisite, but it’s worth saying – sometimes the right move is to not use multisite at all.

If your agency’s client sites share almost nothing – different themes, different plugins, different update schedules – you’re not really getting the benefits of multisite. You’re just getting the constraints. Separate WordPress installs with a management tool like MainWP or ManageWP give you centralized control without the shared database bottleneck.

Multisite makes sense when sites share significant infrastructure – same theme, similar plugin sets, shared user base. Think universities with department sites, franchises with location pages, or media companies with multiple publications. If that’s not your use case, the database optimization effort spent on multisite might be better spent on a simpler architecture.

The honest take – multisite at 50+ sites is manageable with proper caching, selective plugin activation, and database monitoring. But it requires deliberate architecture decisions upfront. Bolting on performance fixes after you’ve already got 50 client sites sharing a single MySQL instance is… not fun. Ask me how I know.

I Tried to Run Every Plugin on WordPress.org. 1 in 16 Wouldn’t Even Start.

MakeWPFast — Fri, 19 Jun 2026 08:15:12 +0000

Originally published on https://makewpfast.com/wordpress-org-plugin-quality-benchmark/

To benchmark how much each WordPress plugin slows down a site, I first had to do something nobody seems to do at scale: install every plugin on WordPress.org, one at a time, in a clean isolated environment, and switch it on.

That second step turned into an accidental audit of WordPress plugin quality. Most plugins behaved. But a stubborn minority couldn’t clear the lowest possible bar — turning on without taking the site down with them.

Here’s the number that matters first, because I don’t want you to walk away thinking the plugin directory is a minefield: about 94% of the plugins I tested activated cleanly and ran in all three contexts I measure. The WordPress plugin ecosystem is, broadly, fine.

But I benchmarked 54,649 plugins, and 3,313 of them — roughly 1 in 16 — permanently failed to even run. Not “ran slowly.” Not “had a bug somewhere deep in a settings page.” Failed to start. White screen, fatal error, or worse.

This post is about that 6%: what breaks, why, and how to spot the pattern before one of them ends up on your site.

How I tested

Every plugin gets the same treatment, with no human in the loop:

Spin up a clean, isolated WordPress container (current WordPress 6.9.x, a normal PHP version).
Install the plugin straight from the WordPress.org repository.
Activate it.
Measure three contexts: activation, the wp-admin dashboard, and the homepage.

No other plugins. No theme tricks. No “it works on my machine.” If a plugin can’t survive a fresh, vanilla install, that’s not an edge case — that’s the plugin.

When a plugin fails the same way repeatedly, I mark it as a permanent failure and record exactly how it died. Those death certificates are what this post is built on.

Failure categories among the ~3,313 WordPress.org plugins that would not start.

The five ways a plugin fails to start

1. It crashes the site on activation (1,172 plugins)

This is the big one, and the worst one. You click “Activate” and the site falls over with a PHP fatal error. No graceful message, no “please configure me first” — just a white screen of death or a 500 error.

Breaking down why they fataled tells you a lot about how the package was shipped:

What killed it	Plugins
Missing file (a require/include pointing at a file not in the zip)	510
Call to an undefined function or method	440
Other fatal errors	159
Uncaught exception	59
Class not found	4

The 510 missing-file crashes are the most damning. That’s not a subtle compatibility issue — it means the plugin author published a zip that doesn’t contain all of its own code. It never could have worked. Nobody activated it once before shipping.

The 440 undefined-function crashes are the classic PHP-version mismatch: the code assumes a function exists that your PHP doesn’t have (or the author leans on another plugin that isn’t there). It’s the same failure mode behind most crashes after an update.

2. It dumps junk during activation (254 plugins)

These don’t fatal — they’re messier. On activation they print raw text or PHP notices straight into the response. WordPress even flags it for you: “The plugin generated unexpected output.”

It looks harmless. It isn’t. Output during activation can corrupt HTTP headers, break redirects, and quietly sabotage anything that runs after it. More to the point, it’s a tell: if a plugin is leaking notices in production, the author shipped with debugging on and never looked at the result.

3. It has secret dependencies (~200 plugins)

This is the rudest category, because it’s so avoidable. The plugin needs another plugin to function — and instead of saying so, it just fatals or refuses to activate.

Hidden requirement	Plugins
Requires WooCommerce	146
Requires Elementor	35
Requires Contact Form 7	11
Requires Genesis / bbPress / others	~10

WordPress has supported a proper Requires Plugins header since version 6.5. A well-built add-on detects the missing dependency and shows a polite admin notice. These ones don’t bother — they assume you already have the parent plugin and detonate when you don’t. If you’ve ever fought a mysterious plugin conflict, this is often the root.

4. It’s abandoned (36 plugins)

A small but telling group: 31 have version requirements so out of step with current WordPress that they won’t load, and 5 ship with invalid file encoding — a sign the code hasn’t been touched in years. These are the plugins still listed in the directory with a four-year-old “last updated” date, waiting for someone to install them and get burned.

5. It’s actively dangerous (30 plugins)

The rarest and scariest. 28 plugins made WordPress completely unresponsive on activation — a hang or a runaway loop that takes the whole site with it. 2 triggered WordPress’s own critical-error protection. Thirty plugins out of 54,000 is a tiny fraction, but if one of them is the one you install on a Friday afternoon, the statistics won’t save your weekend.

What this does not mean

I want to be precise here, because it would be easy to turn this into a scare piece, and that wouldn’t be honest.

~94% of plugins were completely fine. The directory is not broken. Most authors do solid work.
Not every failure is the author’s fault. About 80 of those 3,313 are artifacts of my automated harness — a container hitting a memory ceiling, a transient network blip, a benchmark that gave up too early. I exclude those from the “bad plugin” story.
I give borderline cases the benefit of the doubt. While writing this, I found ~500 plugins that had activated fine and rendered a homepage, but tripped my admin-screen check — almost certainly setup wizards that redirect on activation, not real failures. I pulled them out of the failure set and re-queued them. The 3,313 that remain are the ones that genuinely wouldn’t run.

So the clearly-the-plugin’s-fault group is somewhere around 1,700–1,900. Call it 3% of everything I tested. Small. But “small” is cold comfort when it’s your client’s store that won’t load.

How to vet a plugin before you install it

You don’t need my infrastructure to avoid most of this. You need about ninety seconds and a little discipline:

Check the “Last updated” date. Anything past a year is a yellow flag; past two years is a red one. This single check catches most of the abandoned category.
Check active installs vs. reviews. A plugin with 50 installs and no reviews has, by definition, not been activated on many real sites. You’d be the QA team.
Read the most recent 1- and 2-star reviews. Not the average — the recent angry ones. “White screen after activating” tells you everything.
Look for stated requirements. If it’s an add-on for WooCommerce or Elementor, the listing should say so loudly. Silence is a warning.
Test on staging first. Always. Clone the site, activate there, click around the admin and the front end. Most managed hosts give you one-click staging. Never let a plugin’s first activation be on production.
Activate one at a time. If something breaks, you want to know exactly what did it. This is also the fastest way to find the plugin slowing your site down.

None of this is exotic. It’s the difference between a five-minute install and a Saturday spent in recovery mode.

Where this data comes from

These numbers aren’t a survey or a hunch. They come from the MakeWPFast benchmark dataset — every active plugin on WordPress.org, installed and measured in isolation, with its activation behavior and performance impact recorded. I built it to answer “how much does this plugin actually slow a site down,” and the failure data fell out as a byproduct.

If you want to query it yourself — speed scores, activation results, and benchmark data per plugin — it’s available through the MakeWPFast Benchmark API, and you can browse the full plugin index directly.

The takeaway isn’t “be afraid of plugins.” It’s that a plugin being in the official directory means almost nothing about whether it works. Ninety seconds of checking, and a staging site, will keep you out of the 6%.

Do Too Many Plugins Slow Down WordPress? I Benchmarked 55,000 to Find Out.

MakeWPFast — Fri, 19 Jun 2026 08:15:10 +0000

Originally published on https://makewpfast.com/do-too-many-plugins-slow-wordpress/

Do too many plugins slow down WordPress? Open any “speed up WordPress” article and you’ll hit the same answer in the first three bullets: you have too many plugins. Deactivate some. Fewer plugins, faster site.

It’s repeated so often it’s become a reflex. Slow site? Count your plugins.

So I tested it. I benchmarked 55,202 plugins* from the WordPress.org directory — each one installed and activated in a clean, isolated WordPress container, with the homepage’s load time measured before and after. If the “too many plugins” rule were true, you’d expect most plugins to add real, measurable weight.

They don’t. The median plugin added 0 milliseconds to the homepage. Not “a little.” Zero, within measurement noise. The number of plugins on your site is, for most plugins, almost irrelevant to how fast it loads.

That needs caveats, and I’ll give them honestly below — because the myth survives for a real reason. But the headline holds: plugin count is the wrong thing to measure.

What “too many plugins” gets wrong

The mental model behind the myth is that each plugin is a fixed tax. Twenty plugins, twenty taxes, slow site. Cut to ten, cut the tax in half.

That’s not how WordPress works. A plugin that isn’t doing anything on a given request costs almost nothing on that request. A backup plugin does its work on a schedule, not when a visitor loads your homepage. An anti-spam plugin runs when a comment is submitted. A migration tool runs once, by you. None of them touch the front end of a normal page load, so none of them slow it down — no matter how many you stack up.

The cost of a plugin isn’t “it exists.” The cost is “it runs code on this specific request.” Most don’t.

What I measured (and what I didn’t)

Every plugin got identical treatment, no human in the loop:

Spin up a clean, isolated WordPress install (WordPress 6.9.x).
Record the homepage’s time-to-first-byte (TTFB) with no plugin active.
Install and activate the plugin.
Record TTFB again. The difference is the plugin’s cost.

One thing to be clear about, because it’s the honest limit of this data: I measure a freshly activated, unconfigured plugin on a default site. This is the cost of merely having the plugin active — not the cost once you’ve configured it and built your site around it. A page builder rendering a page you’ve packed with widgets will cost far more than its idle benchmark. WooCommerce on a store with 10,000 products is a different animal than WooCommerce sitting on a blank install.

So read the result precisely: installing and activating more plugins does not, by itself, slow your front end. What you do with a few of them is a separate question.

The result: the median plugin costs nothing

Here’s the homepage TTFB delta across all 55,202 plugins:

Measure	Homepage TTFB added
Median plugin	0 ms
90th percentile	10 ms
99th percentile	25 ms
Worst single plugin	40,069 ms (a broken outlier)

And the distribution is the real story:

Homepage cost	Plugins	Share
10 ms or less	50,106	90.8%
11–50 ms	4,787	8.7%
51–100 ms	113	0.2%
101–500 ms	119	0.2%
Over 500 ms	77	0.14%

Homepage TTFB cost across 55,202 WordPress.org plugins. 90.8% add 10ms or less.

Nine in ten plugins add 10 milliseconds or less. Nearly 59% land within ±5 ms of zero — statistically indistinguishable from not having them at all. Memory tells the same story: the median plugin added 0 KB to the homepage’s peak memory, and only 64 of the 55,202 added more than 5 MB.

The plugins that genuinely hurt — the 196 that add more than 100 ms, the 77 that add more than half a second — are real, and they’re worth hunting down. But they’re 0.36% of the directory. You don’t find them by counting. You find them by measuring.

It’s not just the homepage, either. In the admin dashboard the median plugin also added 0 ms (90th percentile 11 ms), and the same at activation. The “death by a thousand plugins” picture just isn’t in the data at the median.

So why does the myth refuse to die?

Because it’s almost pointing at something true. Three real things hide behind it:

The heavy tail is real and it’s brutal. That worst-case plugin added 40 seconds. A few hundred plugins hook into every single request — running queries, calling external APIs, loading large libraries on init. If your slow site happens to be running two or three of those, deactivating plugins will fix it. You just got lucky about which ones you removed. Finding the actual culprit is faster than deactivating at random.
Configuration and usage, not the plugin itself. A page builder is cheap on a blank page and expensive on a page you’ve packed with widgets. That cost is real, but it’s your page, not the plugin’s mere presence. Counting plugins won’t surface it.
The genuinely broken ones. In a separate benchmark of plugin quality, I found roughly 1 in 16 plugins couldn’t even activate without erroring. Install one of those and “remove a plugin to fix the site” becomes literally true — but the lesson is “don’t install broken plugins,” not “install fewer.”

Every one of those is a reason to be selective, not a reason to be minimal.

What actually slows your site

If plugin count is the wrong metric, here’s where the time actually goes — roughly in order of how often it’s the real problem:

A handful of heavy plugins. Not all of them. Two or three. Profile your site and you’ll usually find the weight concentrated in a few.
No page caching. This dwarfs almost everything else. A cached page skips PHP and the database entirely.
Slow hosting and no object cache. Redis or Memcached for the database round-trips, and a host that isn’t overselling its CPUs.
An under-tuned wp-config.php and a bloated database full of revisions, transients, and exhausted memory.

Notice what’s not on that list: “the number 14 being too high.”

What to do instead of counting plugins

Stop deactivating at random. It’s how the myth got started, and it occasionally works by luck. Measure first.
Find your heavy few. Point a profiler at a slow page and it will show you which plugins actually run on that request and how long each one takes. WP Multitool’s Find Slow Callbacks does exactly that — give it any URL and it times every hook and callback, then names the plugins or themes slowing it down. The answer is almost always a short list.
Judge a plugin before you install it, not after your site is slow. Check the last-updated date, the active installs, and the recent reviews.
Fix the fundamentals first — caching, hosting, object cache. They beat any amount of plugin-pruning.

The numbers behind this post come from the MakeWPFast benchmark dataset: every active plugin on WordPress.org, installed and measured in isolation. You can query a given plugin’s measured cost through the Benchmark API, or browse the full plugin index. And if you’d rather see those scores where you actually make the decision, WP Multitool drops a Plugin Performance Score column straight onto your WordPress plugins page — each plugin’s benchmark score, memory use, and database queries, pulled from this same dataset — so you can spot the heavy ones without leaving wp-admin.

The takeaway isn’t “install everything.” It’s that “too many plugins” is lazy diagnosis. Ten well-built plugins will outrun three bloated ones every time. Stop counting. Start measuring.

About the 55,202. The WordPress.org directory holds more plugins than that. This figure counts the ones that installed, activated cleanly, and returned a valid homepage measurement — the only plugins whose front-end cost can honestly be measured. Several thousand more were tested but couldn’t be benchmarked at all, because they failed to even activate: broken packages, fatal errors, missing dependencies. Those are a separate story, which I dug into in We Tried to Run Every Plugin on WordPress.org. Excluding them here is deliberate — you can’t measure the load time of a plugin that won’t load.

Update: a Redditor challenged the claims in this post, so I installed 223 plugins on one 256 MB box to settle it. Here is what actually broke.

How Many Plugins Can WordPress Handle? I Installed 223 to Find Out

MakeWPFast — Thu, 18 Jun 2026 08:15:13 +0000

Originally published on https://makewpfast.com/how-many-plugins-can-wordpress-handle/

After I published the post about whether too many plugins slow WordPress down, a Redditor called my bluff. The benchmark data says the median plugin adds 0ms to your homepage – fine. So install as many of those “fast” plugins as you can on one box and prove the count doesn’t matter.

Ok. Challenge accepted. I took a fresh WordPress install on a deliberately miserable box – 256 MB PHP memory limit, 1 vCPU, no page caching at all – and started stacking the fastest, most popular plugins from my benchmark database until something broke. I wanted a real number for how many plugins WordPress can actually handle before it falls over.

I got to 223 active plugins. The homepage was still serving HTTP 200. And almost everything I believed going in turned out to be half wrong – including my first reading of how my own optimizer plugin behaved on the pile.

This got long, so here’s the map: the climb to 223, the one plugin that took the whole site down, what an optimizer plugin can and can’t do here, the hunt for the worst offenders, and the fix that actually worked.

The setup

Fresh WordPress 7.0 in an isolated Docker container
PHP memory_limit = 256M – a hard wall, on purpose
1 vCPU, no page cache, no object cache – every request fully dynamic
Candidate pool: 5,202 plugins from the benchmark DB that are both fast (≤2ms activation TTFB delta) and popular (≥1,000 installs)

The exclusions matter for honesty. I dropped all caching plugins (one LiteSpeed Cache would turn every measurement into a cache hit and the test would be meaningless), plus maintenance pages, login changers, redirects, firewalls, SSL forcers and 2FA – anything that would break the measuring itself rather than slow the site. I also added a 15 MB disk-size cutoff to honor “smallest”. Fair warning: the exclusion list wasn’t this clean on day one – it tightened during the run, every time something bit me. More on that below.

Then: install in batches, activate, measure. Peak RAM per request, PHP files loaded, DB queries, TTFB. Repeat until the box gives up.

The climb to 223

Active plugins
Peak RAM
Files loaded
DB queries
TTFB

0
6 MB
480
25
0.32 s

30
10 MB
1,403
107
0.55 s

60
12 MB
1,996
173
0.50 s

100
16 MB
3,255
260
1.12 s

150
42 MB
4,225
420
1.20 s

191
74 MB
4,929
498
~2.7 s

223
102 MB
5,726
~586
2-5 s

The climb from 0 to 223 active plugins: queries and files rise near-linearly, RAM stays far from the 256 MB wall.
Three things jumped out.

The count doesn’t eat your RAM

The fear everyone repeats is “200 plugins will blow your memory”. On a box with OPcache, the front-end barely notices. Peak per-request memory went from 6 MB empty to 102 MB at 223 plugins – around 40% of the 256 MB wall, with the homepage still rendering fine.

The reason is OPcache. It holds the compiled plugin code in shared memory, outside the per-request budget. The plugin folder grew to 784 MB on disk and the rendered page didn’t care.

The 256 MB wall is real – but it lives in wp-admin

The memory limit did eventually bite. Just not where I expected. The homepage kept serving at 223 plugins. What died was the admin bootstrap: activating plugin #224 means loading all 223 existing plugins in admin context, which does far more work than a front-end render, and that blew straight through 256 MB. Later in the experiment wp-login.php itself stopped responding.

So on a memory-starved box the ceiling never touched the visitors. It locked me out instead – no login, no plugin management, no admin at all.

But the site absolutely got slower

Here’s where the Redditor is only half right. Every active plugin registers hooks and runs queries on every page load, and that scales nearly linearly: queries went 25 → ~586 (23x), files loaded per request 480 → 5,726 (12x), and uncached TTFB from 0.3s to several seconds.

The damage comes from the per-request work each active plugin adds, and it accumulates with every install. With page caching most of this disappears on a cache hit – which is exactly why I’d rather measure what each plugin costs than argue about counts. The articles claiming there’s no fixed plugin limit are right about that part. They just never put a number on the accumulation, and the number is what makes it click.

One plugin took the whole site down

223 well-behaved plugins crashed nothing. One plugin did, partway through the climb – it slipped in with an early batch, before my exclusion rules tightened:

PHP Fatal error: Uncaught Error: Call to undefined function PersianWooCommerce\Services\wc_get_order_statuses() on init
persian-woocommerce (100k installs) calls a WooCommerce function on init, but never declares Requires Plugins: woocommerce in its header. WooCommerce wasn’t installed. WordPress happily let it activate anyway, and every request returned HTTP 500 – the site stayed down even after I deactivated everything else, until that one plugin was gone.

All of that traces back to one missing line in a plugin header. Remember the header, because it comes back later in a much weirder way.

Can an optimizer plugin rescue it?

The obvious follow-up. The pile is slow – can you install one more plugin that claws the speed back? I tested with WP Multitool 1.3.0. Full disclosure: that’s my own plugin. Which is exactly why I’m comfortable publishing what happened.

First problem: wp-admin was unreachable. The 224-plugin admin bootstrap blows the 256 MB wall before the login page renders. So no optimizer’s admin UI can be opened on precisely the kind of site that needs rescuing – this applies to every optimization plugin, mine included. What saved the phase is that WP Multitool ships wp multitool CLI commands: frontend enable-all, clean, health all ran fine from the terminal, and a short wp eval-file script covered the autoload optimizer (that part only exists as an admin AJAX action so far). Even wp-cli needed php -d memory_limit=512M just to load the site. Without a CLI, this whole phase ends at a dead login screen – keep that in mind when you pick tooling for a site you might one day have to rescue.

What got applied:

Autoload optimizer: 31 options flipped off autoload, shrinking autoloaded options from 425 KB to 227 KB (-47%)
All 13 frontend tweaks: defer scripts, strip emoji/dashicons/version strings/jquery-migrate/xmlrpc/oembed
DB cleanup: 12 expired transients

And the result, A/B measured by restoring database dumps between the two states:

Metric
223 plugins

WP Multitool optimized

Median warm TTFB
2.00 s
2.08 s (within noise)

DB queries / request
562
574

PHP files / request
5,577
5,595

Autoloaded options
425 KB
227 KB

Honest methodology note, because I nearly published a wrong number here. My first quick A/B – two rounds under heavy host load – suggested the optimizer made the site 0.2-0.45s slower, and that almost went into this post. It smelled wrong though: the deterministic counters say it adds 12 queries and 18 files per request, about 2%, and 2% of work shouldn’t show up as 15% of TTFB. So I re-ran it properly: five alternating restore-measure rounds, 120 samples total. The per-round deltas flip sign (+0.19, -0.25, +0.40, -0.03, -0.43s) and the pooled difference is -1.5% median, Mann-Whitney z = 0.74 – statistically nothing. The “slower” reading was an artifact of my noisy 1-core box, and this is why you alternate A/B rounds instead of trusting two measurement windows.

So the real result: no measurable TTFB change in either direction. The autoload cut is genuine (-47%) and would matter on a site where a bloated alloptions row is the actual problem – but this site’s bottleneck is query volume and hook dispatch from 223 plugins, and no plugin can subtract queries that other plugins insist on running. The optimizer’s own footprint (+12 queries, +18 files) is real too, just small enough to disappear into the noise. You can’t plugin your way out of a plugin pile-up – but the right tooling is what let me drive, measure and eventually fix this site at all.

A note on the numbers: each phase re-measured its own warm baseline, which settles a bit lower than the climb-day readings (562 queries vs the ~586 spike, 96 MB vs 102 MB). All comparisons are within the same phase, same load window.

Finding the plugins actually worth firing

If adding software can’t fix it, the next move is subtraction: which of the 223 deserve to go?

I ran a full leave-one-out sweep. For each of the 223 plugins: deactivate it, hit the homepage twice warm, record queries and files per request, reactivate, next. Query counts are deterministic per request, so a single reading ranks reliably even on a noisy single-core box – the measured noise floor was ±3 queries.

The 10 most expensive of 223 “fast” plugins, by measured DB queries per page load. #2 is a performance plugin.
Savor the second row. jetpack-boost – a performance plugin – is the #2 worst offender, spending 20 queries and 157 PHP files on every single request in order to make your site faster. Another image optimizer shows up at #12.

The bigger finding is the shape of the data. The top 10 plugins (4.5% of the pile) account for 143 of the ~537 added queries – 27%. No plugin costs more than 23 queries. And the individual costs sum to ~92% of the total pile cost, so the damage is genuinely additive – no hidden interaction monster, and no single plugin to blame. The cost is spread across the whole pile.

Still, 27% concentrated in 10 plugins is worth money. Deactivating just those 10, A/B measured back-to-back: queries 562 → 416, files down 654, peak RAM down 8.4 MB, median warm TTFB down 16%.

War stories from the sweep

Running 223 deactivate-measure-reactivate cycles on a dying box produced two stories I didn’t expect.

First, the MySQL container got OOM-killed mid-sweep and every wp-cli call started failing with “Error establishing a database connection”. The sweep script had to grow retries, a wait-for-DB loop and resume support. Fine, my fault for running this on a crowded VM.

Second one’s better. WordPress 7’s plugin dependency check turned out to be a one-way door. FiboSearch and 7 other WooCommerce-dependent plugins had been running happily without WooCommerce for the entire experiment – they were activated before anything checked. But the moment my sweep deactivated one, WordPress refused to turn it back on: “requires woocommerce”. Running without its dependency: fine. Reactivating without it: forbidden. I had to write the active_plugins option back directly.

That’s the header paying off. persian-woocommerce skipped Requires Plugins, activated freely and took the site down. FiboSearch declared it, degraded gracefully and survived the whole run – WordPress only got strict with it at reactivation time. Same missing-dependency situation, completely different blast radius.

Replace the villains, keep the features

Deleting 10 plugins is cheating if the site loses 10 features. So the last phase: replace every villain with a functional equivalent picked from the benchmark data, and keep every capability.

Villain (queries/req)
Replacement (queries/req)

download-manager (23)
simple-download-monitor (3)

jetpack-boost (20)
nothing – redundant

image-optimization (20)
shortpixel-image-optimiser – already installed

pixelyoursite (18)
koko-analytics (0)

qi-addons-for-elementor (15)
nothing – Elementor isn’t even installed

iwp-client (11)
nothing – management runs over SSH

modula-best-grid-gallery (9)
foogallery – already installed

instagram-feed (9)
insta-gallery – already installed

broken-link-checker-seo (9)
nothing – link checking belongs in an external crawler

wp-reviews-plugin-for-google (9)
widget-google-reviews – already installed

Look at how often “already installed” appears. Four of the ten worst plugins duplicated functionality the site already had from a cheaper plugin: a second gallery, a second image optimizer, a second Instagram feed, a second Google-reviews widget. I only had to install two new plugins. Another one, qi-addons-for-elementor, was serving a page builder that didn’t exist on the site – 15 queries per request for nothing.

I’d love to claim I planted those duplicates as a gotcha. I didn’t. They came in naturally with a “fast + popular” selection of 223 plugins, the same way they accumulate on real sites over years of “let’s try this one”.

The result, A/B measured over two rounds in the same load windows:

Same site, four states: the optimizer plugin made no measurable TTFB difference; the audit-and-replace pass cut queries 25% and TTFB 13%.

Metric
223 plugins
215 after audit

DB queries / request
562
422 (-25%)

PHP files / request
5,576
4,952

Peak RAM / request
88 MB
82 MB

Median warm TTFB
1.50 s
1.31 s (-13%)

Zero capability lost. A quarter of the database queries gone. Double-digit TTFB improvement on a fully uncached site – the -13% is a median across both rounds; individual windows ranged from -4% to -30% on this noisy box, so the query counter is the number I’d defend in court. And half of the fix was deleting things nobody knew were duplicated or dead.

One last jetpack-boost anecdote, free of charge: while switching states for the A/B runs, bulk-reactivating the villains over wp-cli crashed twice at the site’s own 256 MB limit – both times inside jetpack-boost’s activation hook. The performance plugin literally cannot activate within the memory budget of the box it’s supposed to speed up. I had to raise the CLI limit to 512M for it.

What I’d actually do with this

If you run a normal site with 30-80 plugins, the numbers scale down but the shape holds:

Page caching first. Almost everything measured here is per-render cost. A cache hit skips it entirely. The uncached numbers are your worst case: logged-in users, carts, POST requests, cache misses.
Audit your plugins individually. 223 cheap plugins ran fine while one bad one killed the site, so the count itself tells you almost nothing. Per-plugin cost is measurable. Measure it.
Hunt duplicates. 4 of my 10 worst offenders duplicated an existing cheaper plugin. Check your galleries, image optimizers, analytics and social feeds.
Be suspicious of plugins that promise speed. The only plugin in my top 10 claiming to make the site faster cost 20 queries and 157 files per request – and my own optimizer, honestly measured, couldn’t move TTFB on this site because it fixes a different bottleneck. If a perf plugin can’t show you before/after numbers on your site, assume nothing.
Check for Requires Plugins before you trust a dependency-shaped plugin. Plugins that declare their dependencies fail politely. The ones that don’t can take your whole site down with them.
Pick tools with a CLI. When the pile finally kills wp-admin, the terminal is the only door left. Every fix in this post ran over wp-cli.

The per-plugin costs I used to pick replacements come from benchmarking 54,000+ wordpress.org plugins across activation, homepage and admin contexts – that dataset is available as an API if you want to audit your own stack against it.

The pile-up site is still running, by the way. 223 plugins active, homepage still HTTP 200. I’m weirdly proud of it.

WordPress Cron Jobs: The Silent Performance Killer Nobody Talks About

MakeWPFast — Tue, 16 Jun 2026 15:07:05 +0000

Originally published on https://makewpfast.com/wordpress-cron-jobs-silent-performance-killer/

Your WordPress site randomly takes 3-4 seconds to load. You check again – 400ms. Refresh – back to 3 seconds. Then it’s fast again for the next 20 requests.

You blame the hosting. You enable caching. You optimize images. Nothing fixes the random spikes. The problem isn’t your server, your theme, or your plugins. It’s wp-cron – and it’s been silently degrading your performance since the day you installed WordPress.

What wp-cron actually does on every page load

WordPress doesn’t have access to your server’s task scheduler. So it built its own pseudo-cron system. Every single time someone loads a page on your site, WordPress runs this check: are there scheduled tasks waiting to execute?

Here’s what happens under the hood. On every page load, WordPress calls spawn_cron(). This function:

Checks the doing_cron transient to see if another cron process is already running
Calls wp_get_ready_cron_jobs() to find tasks with timestamps in the past
If tasks are due, fires a non-blocking HTTP POST request back to your own site at /wp-cron.php
Sets a transient lock so other page loads don’t trigger duplicate runs

Read that again. WordPress makes an HTTP request to itself on every page load where cron tasks are due. Your server is literally calling itself.

Why this causes random slowdowns

The self-HTTP request is supposed to be non-blocking – WordPress sets a timeout of 0.01 seconds and 'blocking' => false. In theory, the page continues loading while cron runs in the background.

In practice, several things go wrong:

1. The loopback request eats a PHP worker

When WordPress fires that request to wp-cron.php, your server needs to handle it like any other request. That means a PHP worker gets occupied running scheduled tasks – publishing scheduled posts, sending emails, running plugin maintenance, processing WooCommerce actions, clearing expired transients.

On shared hosting with 2-4 PHP workers, one worker running cron means 25-50% of your capacity is gone. If cron takes 10 seconds to process a backlog of tasks, every visitor during that window competes for fewer workers.

On a small server, a big enough backlog can tie up every PHP worker at once, and visitors start getting 502/504 gateway timeouts — the site is effectively offline until the queue drains. That’s usually temporary, but if your site is fully down and won’t recover on its own, emergency repair gets a crashed WordPress site back online in about an hour. Otherwise, the cron fix below stops scheduled tasks from ever monopolising your workers in the first place.

2. The loopback can fail or hang

Some hosting configurations block loopback requests. Firewalls, misconfigured DNS, or SSL issues between your server and itself can make the “non-blocking” request actually block. I’ve seen sites where the cron loopback added 2-3 seconds to TTFB because the connection handshake timed out instead of completing instantly.

You can test this. Go to Tools > Site Health in your WordPress admin. If you see “Your site could not complete a loopback request” – that’s the same mechanism wp-cron uses. And it’s broken.

3. Plugin cron sprawl

Every plugin can register its own cron schedules. I’ve seen sites with 40+ scheduled cron events. Some plugins register tasks every 5 minutes. Others schedule one-off tasks and never clean them up, creating “orphaned” cron entries that pile up.

WordPress checks ALL of these on every page load. The more cron events exist, the more work that check does.

How to see what’s actually happening

Before you fix anything, diagnose the problem. Here’s how to see your cron situation clearly.

Using WP-CLI

If you have SSH access, WP-CLI gives you the best view:

List all scheduled cron events

wp cron event list

Count total events

wp cron event list --format=count

See all registered schedules

wp cron schedule list

Test if cron can run

wp cron test
The wp cron event list output shows you every scheduled task, when it’s due, and what schedule it’s on. Look for patterns – are there events scheduled every minute? Events that were supposed to run hours ago but haven’t? That’s your problem.

Check the cron option directly

All cron data lives in one autoloaded option. You can see how bloated it is:

Check the size of your cron data

wp option get cron --format=json | wc -c
If that returns more than 10KB, you have cron bloat. I’ve seen sites where the cron option was over 100KB – serialized data loaded into memory on every single page load, whether cron runs or not.

Using the Query Monitor plugin

Install Query Monitor temporarily. It shows you exactly which cron events are registered and their schedules under the “Environment” panel. No SSH needed.

Find slow callbacks with WP Multitool

If you’re already using WP Multitool, the Find Slow Callbacks module helps identify which hooks – including cron hooks – are consuming the most execution time. Combined with the Slow Query Analyzer, you can trace performance issues back to specific cron tasks hitting the database hard.

The fix: disable wp-cron, use real cron

The solution is straightforward. Stop WordPress from checking cron on every page load, and use your server’s actual cron system to trigger it on a fixed schedule.

Step 1: Disable wp-cron in wp-config.php

Add this line to your wp-config.php, before the “That’s all, stop editing” comment:

define( 'DISABLE_WP_CRON', true );
This does exactly one thing: it tells WordPress to stop calling spawn_cron() on page loads. Your scheduled tasks still exist – they just won’t be triggered by visitors anymore. For a deeper dive into wp-config.php settings that affect performance, check out the complete wp-config.php performance tuning guide.

Step 2: Set up a real server cron job

SSH into your server and edit your crontab:

crontab -e
Add one of these lines. Option A uses wget:

*/15 * * * * wget -q -O /dev/null https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Option B uses curl:

*/15 * * * * curl -s https://yourdomain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1
Option C calls PHP directly – no HTTP overhead at all:

*/15 * * * * cd /path/to/wordpress && php wp-cron.php >/dev/null 2>&1
Option C is the best choice when possible. It skips the HTTP request entirely, which means no SSL handshake, no web server overhead, no loopback issues. The cron tasks run directly in PHP.

The */15 means “every 15 minutes.” That’s enough for most sites. If you publish scheduled posts and need them to go live on time, use */5 for every 5 minutes. Going below 5 minutes is rarely necessary.

Step 3: Verify it’s working

After setting up server cron, check that tasks are actually running:

Manually trigger and watch output

wp cron event run --all --verbose

Check if your cron job is in the crontab

crontab -l | grep wp-cron
Then check your site’s cron event list again after 15-30 minutes. The “next run” times should be updating, proving that server cron is triggering them correctly.

What about managed hosting?

Many managed WordPress hosts – WP Engine, Kinsta, Flywheel, Cloudways – already disable the default wp-cron and run it via server cron. Check your host’s documentation. Some handle this automatically. Others provide a UI to set cron intervals.

If you’re on shared hosting without SSH access, some control panels (cPanel, Plesk) let you set up cron jobs through the web interface. Look for “Cron Jobs” or “Scheduled Tasks” in your hosting panel. The command you’d add is the wget or curl version from above.

The ALTERNATE_WP_CRON option

There’s a middle ground that some people miss. WordPress has another constant:

define( 'ALTERNATE_WP_CRON', true );
This changes the execution model. Instead of spawning a loopback request, it runs cron tasks on the shutdown action – after the HTML has already been sent to the browser. The visitor doesn’t wait for cron, but it still runs on page loads.

This is useful when loopback requests fail (the Site Health error I mentioned earlier) but you can’t set up server cron. It’s not as clean as real server cron – you still need traffic to trigger tasks – but it eliminates the self-HTTP problem.

Cleaning up cron bloat

Switching to server cron fixes the triggering problem. But if you have dozens of orphaned cron events, they still add overhead when WordPress processes the cron option.

Here’s how to clean up:

Find events from plugins you've already deactivated

wp cron event list --fields=hook,next_run,recurrence

Delete a specific orphaned event

wp cron event delete <hook_name>
Look for hooks that reference plugins you no longer use. Common culprits include backup plugins that leave daily schedules behind, SEO plugins with hourly crawl checks, and analytics plugins pinging external APIs on a schedule.

While you’re cleaning up scheduled tasks, it’s worth checking your database for other types of bloat too. Old revisions, expired transients, and spam comments cause similar silent performance degradation.

The WooCommerce special case

WooCommerce deserves its own mention. It relies heavily on wp-cron for processing scheduled sales, sending emails, cleaning up sessions, and running the Action Scheduler – which itself can queue hundreds of tasks.

If you run WooCommerce and haven’t disabled wp-cron, you might see particularly bad spikes. The Action Scheduler can batch-process dozens of pending actions when cron triggers, occupying a PHP worker for 30+ seconds on busy stores.

The fix is the same – server cron – but consider running it more frequently (*/5 instead of */15) for WooCommerce stores to keep the Action Scheduler queue from backing up.

Monitoring after the fix

Once you’ve made the switch, here’s what to watch for:

Consistent TTFB – The random spikes should disappear. If you were seeing 3-second outliers mixed with 400ms responses, they should level out.
Scheduled posts publishing on time – The “Missed schedule” error on posts means cron isn’t running. If you see this, your server cron job isn’t configured correctly.
Plugin features still working – Some plugins depend on frequent cron runs. If something stops working after you make the switch, check what cron interval it expects and adjust your server cron frequency.

If you’re still hunting down what’s making your WordPress site slow after fixing cron, the approach in optimizing WordPress for Core Web Vitals covers the other common bottlenecks – LCP, CLS, and INP.

The bottom line

WP-Cron is one of those things that works “well enough” on small sites with low traffic. But as your site grows, the cost of checking cron on every page load – and especially the self-HTTP loopback request – creates unpredictable performance that no amount of caching can fully fix.

The fix takes 5 minutes: one line in wp-config.php and one line in crontab. It’s one of the highest-impact, lowest-effort WordPress performance optimizations you can make. And unlike most performance tweaks, you’ll notice the difference immediately in your TTFB consistency.

WordPress Security Plugins and Performance: The Hidden Trade-off

MakeWPFast — Tue, 26 May 2026 15:24:32 +0000

Originally published on https://makewpfast.com/wordpress-security-plugins-performance-hidden-tradeoff/

Every WordPress security plugin promises to protect your site. What they don’t advertise is the performance cost.

I’ve spent years optimizing WordPress sites, and one pattern keeps showing up – security plugins adding serious overhead to every single page load. Not just during scans. On every request.

Here’s what’s actually happening under the hood, which plugins are the heaviest, and how to get proper security without tanking your site speed.

How Security Plugins Hook Into Every Request

Most people think their security plugin only does something during scheduled scans. That’s wrong.

Plugins like Wordfence, Sucuri, and Solid Security (formerly iThemes Security) hook into the WordPress request lifecycle early – often at the init or plugins_loaded action. Some bypass WordPress entirely and load via an auto-prepend PHP file.

On every single page load, here’s what a typical security plugin does:

Firewall rule evaluation – checks the incoming request against a ruleset (SQL injection patterns, XSS attempts, path traversal, etc.)
IP reputation lookup – compares the visitor’s IP against a blocklist, sometimes hitting an external API
Login attempt tracking – queries the database to check brute force thresholds
File integrity monitoring – some plugins hash core files on every request or on a frequent cron schedule
Request logging – writes every visit to a custom database table for the “live traffic” feature

That’s a lot of PHP execution and database queries happening before your actual page content even starts rendering.

What Each Major Plugin Does Under the Hood

Wordfence

Wordfence runs its firewall at the PHP level using an auto-prepend file (wordfence-waf.php). This means it executes before WordPress even loads. Smart from a security perspective – it can block attacks before they hit your application. But it also means PHP is doing real work on every request, even for static-ish pages that could otherwise be served from cache.

The heaviest features:

Extended Protection mode – this is the biggest culprit users report. It runs deep packet inspection on every request. Disabling it is the single most common fix for Wordfence-related slowdowns.
Live Traffic logging – writes every request to the database. On a busy site, that’s thousands of INSERT queries per hour competing with your actual content queries.
Malware scanner – when it runs (scheduled or manual), it reads and hashes every PHP file on your installation. On sites with thousands of plugins and theme files, this can pin the CPU for minutes.
Firewall rules – Wordfence maintains a large ruleset that gets evaluated against each request’s headers, parameters, and body. More rules means more regex matching per request.

Wordfence processes everything locally on your server. That’s the fundamental trade-off – your server’s CPU and memory are doing double duty as both a web server and a security appliance.

Sucuri

Sucuri’s free WordPress plugin takes a different approach for scanning – it calls out to Sucuri’s SiteCheck service remotely, which means the malware scan itself doesn’t eat your server CPU.

But the free plugin still runs heavy local operations:

File integrity monitoring – hashes every file in your WordPress installation to detect changes. On sites with large media libraries or lots of plugins, this creates significant disk I/O.
Audit logging – tracks file changes, login attempts, and plugin updates in the database.
Hardening checks – evaluates security posture on admin pages.

Sucuri’s paid cloud WAF is a different story – it sits in front of your server as a reverse proxy, filtering traffic at the edge. This actually reduces your server load because malicious requests never reach PHP. But we’re talking about a $200+/year service, not the free plugin most people install.

Solid Security (iThemes Security)

Solid Security hooks into WordPress at the application level. Independent testing shows it adds execution time comparable to Wordfence, which is notable because Wordfence has significantly more features.

The overhead comes from:

Brute force protection – database queries on every login page load to check attempt counts and lockout status.
File change detection – scheduled scans that read and hash files.
404 detection – logs every 404 error to identify scanning bots. On sites getting hit by automated scanners, this means constant database writes.
Database logging – maintains its own log tables that grow over time, adding to query overhead.
Backend asset loading – loads almost half a megabyte of JavaScript on admin pages.

The IP ban list is another hidden cost. As it grows, every request has to check against it. On sites that have been running Solid Security for years, that list can get massive.

The Numbers in Context

Independent benchmarks from Accelera WP tested security plugins with firewalls and brute force protection enabled on default settings. The spread is significant:

The lightest plugins (SecuPress, Security Optimizer) added roughly 12-25ms of frontend execution time
Wordfence and Solid Security added around 55-60ms
Shield Security added over 130ms

Those are per-request numbers on a test environment. On a shared hosting server under real load with competing sites, those numbers get worse. And they compound – if you’re also running a page builder, WooCommerce, and an SEO plugin, you’re stacking overhead on top of overhead.

Why Some Features Are Worse Than Others

Not all security features cost the same. Here’s roughly how they rank from heaviest to lightest:

Heavy:

Live traffic logging (constant DB writes)
Full filesystem malware scans (CPU + disk I/O spikes)
Extended/deep firewall modes (complex regex on every request)
File integrity hashing on every request

Medium:

Brute force tracking (DB reads/writes on login)
IP blocklist checking (grows over time)
404 monitoring and logging
Comment spam protection

Light:

Security headers (one-time HTTP header additions)
Login URL changes (simple redirect)
XML-RPC blocking (early request termination)
File permission checks (admin-only, not per-request)

The problem is that most plugins enable the heavy features by default. And most users never touch the settings.

The Real Problem: PHP-Level Firewalls

Here’s the fundamental issue that nobody talks about enough.

A PHP-based firewall means your server has to boot PHP, load WordPress (or at least the WAF prepend file), parse the request, run it through firewall rules, and then either block it or continue to your actual page.

For legitimate visitors, that’s wasted overhead. They were always going to get through – but your server still had to run all those checks.

For attackers, it’s even worse. Your server is still spending CPU cycles processing their requests, even if it eventually blocks them. During a brute force attack or a bot flood, your PHP workers are busy evaluating firewall rules instead of serving pages to real visitors.

This is backwards. You’re using your web server as a firewall, when there are purpose-built tools that handle this at the network level.

How to Get Security Without Killing Performance

Option 1: Cloudflare WAF (Best for Most Sites)

Cloudflare’s WAF operates at the network edge – their servers evaluate requests before they ever reach yours. Malicious traffic gets blocked at the nearest Cloudflare data center, thousands of miles from your origin server.

What this means in practice:

Bot traffic never hits your PHP workers
DDoS attacks get absorbed by Cloudflare’s network, not yours
Your server only processes legitimate requests
You get a CDN and performance optimization on top of the security

The free Cloudflare plan includes basic WAF rules. The Pro plan ($20/month) gives you managed rulesets that cover OWASP Top 10. That’s less than most premium security plugins, and it actually makes your site faster instead of slower.

You still want to pair this with basic WordPress hardening:

Strong passwords and two-factor authentication (use a lightweight 2FA plugin)
Disable XML-RPC if you’re not using it
Keep WordPress, themes, and plugins updated
Use proper file permissions

Option 2: Server-Level Firewall

If you have server access (VPS or dedicated), you can run firewall rules at the OS level with tools like fail2ban, ModSecurity, or iptables/nftables.

fail2ban watches your logs and blocks IPs after failed login attempts – at the network level, before PHP even gets involved. ModSecurity runs as an Apache or Nginx module, evaluating requests before they hit PHP.

This is how enterprise sites handle security. The firewall runs where it belongs – at the network or server level – not inside the application.

Option 3: Minimal Plugin Setup

If you must use a plugin (maybe your client insists, or you need the audit logging for compliance), here’s how to minimize the damage:

Disable live traffic logging. You don’t need it. Use your server logs or Cloudflare analytics instead.
Schedule scans for off-peak hours. Run malware scans at 3 AM, not during business hours.
Reduce scan frequency. Weekly scans are fine for most sites. Daily is overkill.
Disable file integrity checking on every request. Scheduled checks are enough.
Keep your IP blocklist clean. Purge old entries regularly.
Use a lightweight plugin. SecuPress and All-In-One Security tested significantly lighter than Wordfence and Solid Security in independent benchmarks.

Option 4: The Hybrid Approach (What I Actually Recommend)

Here’s what I run on most sites I manage:

Cloudflare in front (free or Pro plan) – handles WAF, bot protection, DDoS mitigation
No security plugin – seriously. Cloudflare handles the heavy lifting.
fail2ban on the server for SSH and wp-login brute force protection
Two-factor authentication via a lightweight plugin (not a full security suite)
Automatic updates for minor WordPress releases and plugin security patches
Regular backups that are tested (security is also about recovery)

This setup adds zero per-request overhead from security operations. All the heavy checking happens at the edge or at the OS level, not in PHP.

When You Actually Need a Security Plugin

I’m not saying security plugins are always wrong. There are cases where they make sense:

Shared hosting where you can’t install server-level tools – a plugin is your only option
Compliance requirements that demand file integrity monitoring with audit trails
Multi-tenant environments where you need per-site security policies
Client sites where the client needs a dashboard to see security status

In those cases, pick the lightest plugin that meets your requirements, disable every feature you don’t need, and pair it with Cloudflare to reduce the load.

Check Your Own Site

Want to know if your security plugin is slowing you down? Here’s a quick test:

Measure your TTFB (Time to First Byte) with the security plugin active
Deactivate the security plugin temporarily
Measure TTFB again
Compare the difference

If you’re seeing a meaningful increase in TTFB with the plugin active, that’s your security tax on every single request.

You might also want to check your Core Web Vitals – security plugins can affect LCP and INP too, especially ones that load JavaScript on the frontend.

While you’re at it, check if your security plugin is conflicting with other plugins. Security plugins are notorious for breaking caching plugins, CDN integrations, and REST API functionality.

Bottom Line

Security plugins run PHP code on every request. That costs time and server resources. Cloud-based WAFs like Cloudflare do the heavy lifting at the edge, where it belongs.

The best security setup is often the one that doesn’t run inside WordPress at all.

If your site feels sluggish and you can’t figure out why, your security plugin might be the culprit nobody suspected. Especially if you’re on shared hosting where resources are tight. Before you start debugging your database bloat or deferring JavaScript, check that security plugin first. Sometimes the thing protecting your site is also the thing holding it back.