Scaling WordPress to 10M+ Users: Lessons from Brainstorm Force

In December 2024, Brainstorm Force served content to over 10 million WordPress-powered websites through its plugin portfolio — Spectra, Astra, WP Portfolio, Starter Templates, and more. That’s not a marketing number: it’s a daily operational reality that shapes every engineering decision.

This post covers the real architectural lessons we learned building and maintaining software at this scale — the decisions that seem obvious in hindsight but weren’t obvious at all when we were making them.

The Scale We’re Actually Talking About

When people talk about “scaling WordPress,” they usually mean handling more traffic. Our challenge was different: we’re scaling a software product that runs inside millions of other people’s WordPress installations. We don’t control the hosting environment, the PHP version, the database configuration, or the server resources. Our code has to work correctly in an 8MB memory limit shared hosting environment AND in a high-performance VPS with Redis and 2GB of PHP memory.

This constraint changes everything. It means:

• We can’t assume Redis or any object cache is available
• We can’t rely on cron jobs running reliably
• We can’t use PHP extensions that aren’t universally available
• Our plugin must degrade gracefully on every possible hosting configuration
• Every byte of memory we use comes out of the host site’s allocation

Lesson 1: Lazy Loading Is Not Optional — It’s Survival

The most impactful single change we made to Spectra’s architecture was moving from a monolithic bootstrap to a lazy-loading architecture. In Spectra v2, the main plugin file registered all hooks, loaded all classes, and initialized all modules on every page load. Even if only 2 of our 30 blocks were used on a page, all 30 were loaded.

// Spectra v2 — everything loads on every request
class UAGB_Init {
    public function __construct() {
        require_once 'classes/class-uagb-loader.php';
        require_once 'classes/class-uagb-helper.php';
        require_once 'classes/class-uagb-admin-helper.php';
        require_once 'classes/class-uagb-config.php';
        // ... 47 more require statements
        
        add_action('init', [$this, 'init_hooks']);
        add_action('admin_init', [$this, 'init_admin']);
        add_action('wp_enqueue_scripts', [$this, 'enqueue_frontend']);
        add_action('block_categories_all', [$this, 'register_categories']);
    }
}

In Spectra v3, we moved to a PSR-4 autoloader with context-aware lazy initialization:

// Spectra v3 — only load what's needed
class Plugin {
    private static array $registered_hooks = [];

    public static function boot(): void {
        // Always needed: post type registration, asset manifest
        add_action('init', [BlockRegistry::class, 'register_block_types'], 5);
        
        // Admin only — don't load on frontend requests
        if (is_admin()) {
            add_action('admin_menu', [AdminMenu::class, 'register']);
            add_action('rest_api_init', [SettingsController::class, 'register_routes']);
        }

        // Frontend only — skip the admin bloat
        if (!is_admin()) {
            add_action('wp_enqueue_scripts', [AssetLoader::class, 'enqueue_conditional'], 20);
        }

        // Editor-only assets — only in block editor context
        add_action('enqueue_block_editor_assets', [EditorAssets::class, 'enqueue']);
    }
}

// PSR-4 autoloader — classes load only when instantiated
spl_autoload_register(function(string $class): void {
    $prefix   = 'Brainstormforce\Spectra\';
    $base_dir = __DIR__ . '/src/';

    if (!str_starts_with($class, $prefix)) return;

    $relative_class = str_replace('\', '/', substr($class, strlen($prefix)));
    $file = $base_dir . $relative_class . '.php';

    if (file_exists($file)) {
        require $file;
    }
});

Impact: Memory usage per page request dropped 40% in benchmark testing. On shared hosting sites, this was the difference between working correctly and hitting the memory limit.

Lesson 2: Asset Loading Strategy Is Your #1 Performance Lever

WordPress plugins notoriously load CSS and JS on every page, regardless of whether the content requires them. At 1M+ installs, even a 10ms asset-loading overhead multiplies to massive real-world impact.

Spectra’s asset loading strategy evolved through three generations:

Generation 1: Load Everything Globally (Wrong)

// Bad — loads all CSS/JS on every page
function enqueue_spectra_assets() {
    wp_enqueue_style('spectra-blocks', SPECTRA_URI . 'dist/blocks.css');
    wp_enqueue_script('spectra-frontend', SPECTRA_URI . 'dist/frontend.js');
}
add_action('wp_enqueue_scripts', 'enqueue_spectra_assets');

Generation 2: Load Per Block (Better)

// Better — only load CSS for blocks that appear on this page
register_block_type('spectra/info-box', [
    'style' => 'spectra-info-box', // Auto-enqueued when block renders
    'editor_style' => 'spectra-info-box-editor',
]);

Generation 3: Combined Critical CSS + Deferred Rest (Best)

class AssetLoader {
    private static ?array $blocks_on_page = null;

    /**
     * Scan the current page's post content for Spectra blocks.
     * Uses regex rather than parsing to stay fast.
     */
    private static function detect_blocks_on_page(): array {
        if (static::$blocks_on_page !== null) {
            return static::$blocks_on_page;
        }

        static::$blocks_on_page = [];
        $post = get_post();
        if (!$post || empty($post->post_content)) {
            return [];
        }

        preg_match_all(
            '/