WordPress Multisite Performance Deep Dive: switch_to_blog, Shared Tables, and Scaling Patterns

Why Multisite Performance Differs from Single-Site WordPress

WordPress Multisite transforms a single WordPress installation into a network of sites sharing the same codebase and, by default, the same database. This architecture introduces performance characteristics that single-site operators never encounter. The shared database model means that certain tables grow proportionally with network size while others multiply per site. Understanding this distinction is the foundation of every optimization strategy covered in this article.

A fresh single-site WordPress installation creates roughly 12 database tables. When you activate Multisite and add a new site, WordPress creates an additional 9 tables specific to that site (posts, postmeta, comments, commentmeta, terms, term_taxonomy, term_relationships, options, and links). A network with 500 sites means approximately 4,512 tables in a single database. MySQL and MariaDB both handle this without complaint at small scale, but the operational characteristics shift dramatically as site count grows.

The performance pitfalls in Multisite are not always about raw query speed. They often emerge from the interaction patterns between WordPress core functions, the object cache, and the database abstraction layer. A function call that takes 2 milliseconds on a single site can balloon to 2 seconds when executed across 1,000 sites in a loop. The problem is rarely the individual query. The problem is the multiplication of queries, cache invalidations, and context switches that Multisite operations demand.

This article breaks down the internal mechanics of key Multisite functions, identifies the scaling bottlenecks that appear at various network sizes, and provides concrete optimization patterns drawn from production networks ranging from 10 to 5,000+ sites.

How switch_to_blog() Works Internally

switch_to_blog() is the single most important function in WordPress Multisite development, and also the single most misunderstood from a performance standpoint. Its job seems simple: temporarily change the current blog context so that subsequent WordPress functions operate against a different site’s data. The actual implementation is considerably more involved.

The wpdb Prefix Swap

When you call switch_to_blog( $blog_id ), WordPress executes $wpdb->set_blog_id( $blog_id ). This method recalculates the table prefix for all per-site tables. The global $wpdb->prefix changes from something like wp_ to wp_42_ (for site ID 42). Every subsequent query that references $wpdb->posts, $wpdb->options, or any other per-site table property will now point to the switched site’s tables.

Here is what happens in the set_blog_id() method:

// Simplified from wp-includes/class-wpdb.php
public function set_blog_id( $blog_id, $network_id = 0 ) {
    $old_blog_id = $this->blogid;
    $this->blogid = $blog_id;

    $this->prefix = $this->get_blog_prefix( $blog_id );

    foreach ( $this->tables( 'blog' ) as $table => $prefixed_table ) {
        $this->$table = $prefixed_table;
    }

    return $old_blog_id;
}

The tables( 'blog' ) method returns the list of per-site tables (posts, postmeta, comments, etc.), and each one gets its property updated on the $wpdb object. This is a fast operation in isolation. The cost shows up when you do it hundreds or thousands of times.

Option Cache Flush

After the prefix swap, switch_to_blog() calls wp_cache_switch_to_blog( $blog_id ). This function does not flush the entire object cache. Instead, it swaps the internal blog ID reference so that cache keys become namespaced to the target blog. If you are using the default WordPress object cache (a PHP array), this means the cache essentially starts empty for the switched blog unless it was previously populated in the same request.

The critical detail: WordPress also calls wp_cache_init() indirectly through the blog switch process when certain persistent cache backends are in use. This resets some internal state. For the default in-memory cache, WordPress maintains separate cache arrays per blog ID, but the array for a blog you have never switched to in this request will be empty.

This matters because the first operation after a switch often triggers a fresh database query. If you switch to blog 42 and call get_option( 'siteurl' ), WordPress cannot find it in cache, so it queries the wp_42_options table. If you then switch to blog 43 and call get_option( 'siteurl' ), another query fires against wp_43_options. Multiply this by the number of sites and the number of options queried per site, and you have the classic Multisite performance problem.

Object Cache Clearing and Global Groups

WordPress defines certain cache groups as “global,” meaning they are not namespaced per blog. The users, usermeta, site-transient, blog-details, and networks groups persist across blog switches because they reference shared tables.

The non-global groups (posts, options, terms, etc.) get their effective namespace changed when you switch blogs. If you are using a persistent object cache like Redis or Memcached, the cache keys include the blog ID, so data from blog 42 and blog 43 coexist in the cache store without collision. But the switching process still has overhead: WordPress must verify the cache state, potentially flush stale entries, and rebuild context.

The restore_current_blog() Cost

Every switch_to_blog() call must be paired with restore_current_blog(). This function pops the previous blog ID off an internal stack and repeats the prefix swap and cache switch in reverse. The cost is roughly equivalent to another switch_to_blog() call. If you switch to 100 blogs in a loop, you execute 200 context switches total (100 switches + 100 restores), each with its own prefix recalculation and cache state change.

The N+1 Query Problem in Multisite

The N+1 query problem is well-known in ORM-based frameworks, but it manifests with particular severity in WordPress Multisite. The pattern looks like this: you need some piece of data from every site in the network, so you fetch the list of sites and then loop through each one, switching context and running a query.

A Typical N+1 Pattern

Consider a network dashboard that displays the latest post from each site:

$sites = get_sites( array( 'number' => 0 ) );

foreach ( $sites as $site ) {
    switch_to_blog( $site->blog_id );

    $latest = get_posts( array(
        'numberposts' => 1,
        'post_status' => 'publish',
    ) );

    if ( $latest ) {
        $results[] = array(
            'blog_id' => $site->blog_id,
            'title'   => $latest[0]->post_title,
            'url'     => get_permalink( $latest[0]->ID ),
        );
    }

    restore_current_blog();
}

For a network with 200 sites, this code executes:

• 1 query to fetch the site list from wp_blogs
• 200 switch_to_blog() calls, each resetting the wpdb prefix and cache namespace
• 200 queries to fetch the latest post from each site’s posts table
• 200 queries (at minimum) from get_permalink(), which internally calls get_option( 'permalink_structure' ) plus post meta queries
• 200 restore_current_blog() calls

The total query count easily exceeds 600 for just 200 sites. On a cold cache, each site switch triggers additional option loading queries (WordPress autoloads certain options the first time it accesses a site’s option table). The real query count for 200 sites with a cold cache can reach 1,200 to 1,800 queries.

Measuring the Impact

I benchmarked this exact pattern on a test network running MariaDB 10.6 with the default WordPress object cache (no Redis, no Memcached). The server was an 8-core VM with 16 GB RAM:

• 10 sites: 47ms total, 63 queries
• 50 sites: 289ms total, 312 queries
• 100 sites: 641ms total, 618 queries
• 500 sites: 3,847ms total, 3,042 queries

The relationship is roughly linear, but the constant factor is high. At 500 sites, you are spending nearly 4 seconds on what should be a simple dashboard widget. Add a persistent object cache and the numbers improve, but the fundamental scaling problem remains because each switch still requires at least one query per site if the cache is cold for that site.

Direct SQL Queries vs. switch_to_blog() Loops

The alternative to switch_to_blog() loops for cross-site data aggregation is direct SQL. Because every site’s tables follow a predictable naming convention (wp_{$blog_id}_posts), you can construct queries that join or union across multiple site tables.

A Direct SQL Approach

Here is the same “latest post per site” query implemented with direct SQL:

global $wpdb;

$sites = get_sites( array( 'number' => 0, 'fields' => 'ids' ) );

$unions = array();
foreach ( $sites as $blog_id ) {
    $prefix = $wpdb->get_blog_prefix( $blog_id );
    $unions[] = $wpdb->prepare(
        "SELECT %d AS blog_id, ID, post_title, post_date, post_name
         FROM {$prefix}posts
         WHERE post_status = 'publish' AND post_type = 'post'
         ORDER BY post_date DESC LIMIT 1",
        $blog_id
    );
}

$sql = implode( ' UNION ALL ', $unions );
$results = $wpdb->get_results( $sql );

This approach fires exactly 2 queries regardless of the number of sites: one for the site list, and one (large) UNION query for the posts. On the same test hardware:

• 10 sites: 8ms total, 2 queries
• 50 sites: 22ms total, 2 queries
• 100 sites: 41ms total, 2 queries
• 500 sites: 198ms total, 2 queries

The speedup ranges from 5x at 10 sites to 19x at 500 sites. The UNION query does get slower as more tables are involved, but the reduction in query count and the elimination of context switches makes a dramatic difference.

Tradeoffs of Direct SQL

Direct SQL queries bypass the WordPress abstraction layer. This means:

No filters or hooks. Plugins that modify queries via pre_get_posts or posts_clauses will not apply. If a site uses a plugin that alters post visibility, your direct query will ignore those rules.

No object cache population. Results from direct SQL do not automatically populate the object cache. If subsequent code calls get_post() for one of the returned posts after switching to that blog, it will fire another query because the cache is empty.

No post meta or taxonomy data. You get raw post table data. Fetching meta or term data requires additional JOINs to each site’s postmeta or term_relationships tables, making the UNION query significantly more complex.

Permalink generation requires switch_to_blog(). Functions like get_permalink() depend on the current blog context for rewrite rules and option values. You cannot generate proper permalinks without switching.

The practical guideline: use direct SQL for read-only aggregation dashboards, reports, and bulk data exports. Use switch_to_blog() for operations that require the full WordPress API, but do so with awareness of the per-switch cost.

Global Tables: Contention Points at Scale

WordPress Multisite uses several “global” tables shared across all sites in the network. The three most performance-sensitive are wp_users, wp_usermeta, and wp_blogs.

wp_users and wp_usermeta

Every user across every site in the network shares a single wp_users table. A network with 500 sites and an average of 100 users per site might have 50,000 rows in wp_users (assuming no overlap) or as few as 2,000 rows if most users belong to multiple sites. The wp_users table itself scales well because it has proper indexes on user_login, user_email, and user_nicename.

The real bottleneck is wp_usermeta. WordPress stores per-site capabilities in usermeta with keys like wp_42_capabilities and wp_42_user_level. A user who belongs to 10 sites has at least 20 extra usermeta rows just for capabilities. At scale, wp_usermeta becomes the largest table in the database. A network with 50,000 users averaging 5 sites each will have roughly 1.5 million usermeta rows (50,000 users x 5 sites x ~6 meta keys per site, plus standard meta entries).

Queries like get_users() that filter by meta values perform poorly on large usermeta tables because meta_value is not indexed by default. The WP_User_Query class generates JOINs against usermeta for role-based filtering, and these JOINs become expensive as the table grows.

Mitigation strategies:

// Instead of querying all users with a specific role across the network:
// BAD - scans entire usermeta table
$users = get_users( array(
    'blog_id'  => 42,
    'role'     => 'editor',
) );

// BETTER - use a direct query with the specific meta key
global $wpdb;
$prefix = $wpdb->get_blog_prefix( 42 );
$editors = $wpdb->get_col( $wpdb->prepare(
    "SELECT u.ID FROM {$wpdb->users} u
     INNER JOIN {$wpdb->usermeta} um ON u.ID = um.user_id
     WHERE um.meta_key = %s
     AND um.meta_value LIKE %s",
    $prefix . 'capabilities',
    '%\"editor\"%'
) );

The direct query is not dramatically different from what WordPress generates internally, but it avoids the overhead of WP_User_Query‘s abstraction and gives you control over exactly which JOINs execute.

wp_blogs Table

The wp_blogs table stores metadata for every site in the network. Core functions like get_sites(), get_blog_details(), and the internal site lookup during URL routing all query this table. At small scale, wp_blogs is negligible. At 10,000+ sites, it becomes a contention point during concurrent requests because every page load in the network touches this table at least once during the URL-to-blog-ID resolution.

WordPress caches blog details aggressively in the blog-details cache group (which is a global group), so a persistent object cache reduces the database load significantly. Without one, every request on every site generates at least one query against wp_blogs.

wp_is_large_network() and Its Effects

WordPress defines a “large network” as one with more than 10,000 sites or 10,000 users. The wp_is_large_network() function checks these thresholds and returns a boolean. Several core admin screens change their behavior based on this check.

What Changes for Large Networks

The Sites list in Network Admin. When wp_is_large_network( 'sites' ) returns true, WordPress disables the site count display in the admin bar and modifies the Sites list table to avoid counting all sites. Instead of showing “X items,” it shows a paginated view without a total count. The SQL query drops the SQL_CALC_FOUND_ROWS modifier, which avoids a full table scan on wp_blogs.

The Users list in Network Admin. When wp_is_large_network( 'users' ) returns true, WordPress disables the autocomplete user search in the “Add Existing User” form on individual site admin pages. The autocomplete would otherwise query all users in the network on every keystroke, which is unsustainable at 10,000+ users.

Site and user counts. Functions like get_blog_count() and get_user_count() switch from real-time counts to cached values that update periodically via a cron-like mechanism.

Adjusting the Threshold

The threshold is filterable:

add_filter( 'wp_is_large_network', function( $is_large, $component, $count, $network_id ) {
    if ( 'sites' === $component ) {
        return $count > 500; // Lower threshold for sites
    }
    if ( 'users' === $component ) {
        return $count > 5000; // Lower threshold for users
    }
    return $is_large;
}, 10, 4 );

Lowering the threshold can improve admin responsiveness on medium-sized networks. I have seen networks with 2,000 to 3,000 sites where the Network Admin Sites page takes 8 to 10 seconds to load because wp_is_large_network() returns false and WordPress performs full counts. Dropping the threshold to 500 sites cuts that page load to under 2 seconds.

Object Cache Strategies for Multisite

A persistent object cache (Redis, Memcached) is not optional for any Multisite network you care about performing well. The default WordPress object cache stores data in a PHP array that dies at the end of each request. In Multisite, this means every request starts cold for every site except the one being loaded. A persistent cache changes the game entirely.

Global Groups and Blog-Specific Namespacing

WordPress separates cache keys into global groups and per-blog groups. Global groups store data that applies across the entire network:

// These groups are registered as global in wp-includes/load.php
wp_cache_add_global_groups( array(
    'blog-details',
    'blog-id-cache',
    'blog-lookup',
    'global-posts',
    'networks',
    'rss',
    'sites',
    'site-details',
    'site-lookup',
    'site-options',
    'site-transient',
    'users',
    'useremail',
    'userlogins',
    'usermeta',
    'user_meta',
    'userslugs',
) );

Per-blog groups (posts, options, terms, etc.) are automatically prefixed with the blog ID by the cache backend. When you store a post in cache on blog 42, the actual cache key becomes something like 42:posts:123. This namespacing prevents collisions between sites.

Redis Configuration for Multisite

If you are running Redis as your object cache, the configuration needs to account for Multisite’s key structure. A typical wp-content/object-cache.php drop-in for Redis (via the WP Redis plugin or a similar implementation) will handle blog-specific namespacing automatically. But there are tuning considerations:

Memory allocation. Each site adds its own set of cached options, posts, and metadata. A rough guideline: allocate 50 to 100 MB of Redis memory per 100 sites for a typical content site. Sites with heavy custom post types or complex queries will need more.

Eviction policy. Use allkeys-lru as the eviction policy. This ensures that least-recently-used keys get evicted first, which naturally favors active sites over dormant ones.

Key prefixing. Some Redis object cache plugins allow you to set a global key prefix (useful when multiple WordPress installations share the same Redis instance). Make sure this prefix is unique per network:

// In wp-config.php
define( 'WP_CACHE_KEY_SALT', 'wpkite_network_' );

Cache Warming and Preloading

For networks where certain sites receive the bulk of traffic, you can implement cache warming via a cron job that pre-populates the object cache for those sites:

add_action( 'wpkite_warm_cache', function() {
    $high_traffic_sites = array( 1, 5, 12, 42 ); // Known high-traffic site IDs

    foreach ( $high_traffic_sites as $blog_id ) {
        switch_to_blog( $blog_id );

        // Trigger autoloaded options cache population
        wp_load_alloptions();

        // Warm the front page query cache
        $front_page_id = get_option( 'page_on_front' );
        if ( $front_page_id ) {
            get_post( $front_page_id );
            get_post_meta( $front_page_id );
        }

        restore_current_blog();
    }
} );

if ( ! wp_next_scheduled( 'wpkite_warm_cache' ) ) {
    wp_schedule_event( time(), 'hourly', 'wpkite_warm_cache' );
}

This is a targeted approach. Do not try to warm the cache for all 500 sites. Focus on the 20% that generate 80% of the traffic.

Database Sharding and Table Partitioning

When a single MySQL or MariaDB instance can no longer handle the load from a large Multisite network, the next step is distributing the database load across multiple servers. Two projects have historically provided this capability for WordPress: HyperDB and LudicrousDB.

HyperDB

HyperDB is a drop-in replacement for the WordPress $wpdb object. It supports multiple database servers with read/write splitting and table-based routing. You define a configuration that maps tables to specific database servers:

// db-config.php (HyperDB configuration)
$wpdb->add_database( array(
    'host'     => 'db-primary.example.com',
    'user'     => 'wp_writer',
    'password' => 'secret',
    'name'     => 'wordpress',
    'write'    => 1,
    'read'     => 1,
    'dataset'  => 'global',
    'timeout'  => 0.2,
) );

$wpdb->add_database( array(
    'host'     => 'db-replica-1.example.com',
    'user'     => 'wp_reader',
    'password' => 'secret',
    'name'     => 'wordpress',
    'write'    => 0,
    'read'     => 1,
    'dataset'  => 'global',
    'timeout'  => 0.2,
) );

// Route site-specific tables to a separate server
$wpdb->add_database( array(
    'host'     => 'db-sites-1.example.com',
    'user'     => 'wp_writer',
    'password' => 'secret',
    'name'     => 'wordpress_sites',
    'write'    => 1,
    'read'     => 1,
    'dataset'  => 'sites_1_to_500',
    'timeout'  => 0.2,
) );

// Callback to route queries to the correct dataset
$wpdb->add_callback( 'my_db_routing', 'dataset' );

function my_db_routing( $query, $wpdb ) {
    // Global tables stay on the primary
    $global_tables = array(
        $wpdb->users, $wpdb->usermeta, $wpdb->blogs,
        $wpdb->site, $wpdb->sitemeta, $wpdb->registration_log,
        $wpdb->signups,
    );

    foreach ( $global_tables as $table ) {
        if ( preg_match( "/\b{$table}\b/", $query ) ) {
            return 'global';
        }
    }

    // Route site-specific tables based on blog ID
    if ( preg_match( '/wp_(\d+)_/', $query, $matches ) ) {
        $blog_id = intval( $matches[1] );
        if ( $blog_id <= 500 ) {
            return 'sites_1_to_500';
        } else {
            return 'sites_501_plus';
        }
    }

    return 'global';
}

This configuration routes queries for sites 1 through 500 to one database server and sites 501+ to another, while global tables stay on the primary server. The routing is transparent to WordPress core and plugins.

LudicrousDB

LudicrousDB is a fork of HyperDB with additional features including heartbeat monitoring, automatic failover, and better connection pooling. The configuration syntax is nearly identical to HyperDB but adds options for connection reuse and health checking:

// LudicrousDB adds these capabilities
$wpdb->add_database( array(
    'host'        => 'db-primary.example.com',
    'user'        => 'wp_writer',
    'password'    => 'secret',
    'name'        => 'wordpress',
    'write'       => 1,
    'read'        => 1,
    'dataset'     => 'global',
    'timeout'     => 0.2,
    'lag_threshold' => 2, // Max acceptable replication lag in seconds
) );

The lag_threshold parameter is especially useful. If a read replica falls behind the primary by more than the specified number of seconds, LudicrousDB will route read queries to another replica or to the primary. This prevents stale data issues that can cause bizarre bugs in Multisite (e.g., a user updates a post on site 42, switches to the Network Admin, and does not see the update because the replica has not caught up).

Table Partitioning Within MySQL

An alternative to sharding across multiple servers is partitioning tables within a single MySQL instance. This is most useful for the global tables, particularly wp_usermeta:

ALTER TABLE wp_usermeta
PARTITION BY HASH(user_id) PARTITIONS 16;

Hash partitioning on user_id distributes usermeta rows across 16 physical partitions. Queries that filter by user_id (which most usermeta queries do) will only scan one partition instead of the full table. For a table with 2 million rows, this reduces the effective scan size to approximately 125,000 rows per query.

A word of caution: WordPress core does not expect partitioned tables, and certain queries (particularly those that do not include user_id in the WHERE clause) may actually perform worse on partitioned tables because MySQL must scan all partitions. Test thoroughly before deploying this in production.

Horizontal Scaling: Separate Databases Per Site

The most aggressive scaling strategy is to give each site (or groups of sites) its own database. This eliminates cross-site table contention entirely and allows each site's database to be independently sized, backed up, and migrated.

Implementation with HyperDB or LudicrousDB

The database routing callback becomes the core of this architecture:

function per_site_db_routing( $query, $wpdb ) {
    $global_tables = array(
        $wpdb->users, $wpdb->usermeta, $wpdb->blogs,
        $wpdb->site, $wpdb->sitemeta,
    );

    foreach ( $global_tables as $table ) {
        if ( preg_match( "/\b{$table}\b/", $query ) ) {
            return 'global';
        }
    }

    if ( preg_match( '/wp_(\d+)_/', $query, $matches ) ) {
        $blog_id = intval( $matches[1] );
        return 'site_' . $blog_id;
    }

    // Main site tables (no numeric prefix)
    return 'site_1';
}

Each site_N dataset maps to a separate database (potentially on a separate server). The global tables remain in a shared database that all sites connect to.

Operational Complexity

Separate databases per site brings significant operational overhead:

Backup complexity. Instead of one database to back up, you have N+1 (one global + one per site). Automated backup scripts must enumerate all databases and handle failures per-database.

Migration complexity. Adding a new site requires creating a new database, setting up the routing entry, and running the WordPress table creation process against the new database. This is not supported by the standard WordPress "Add New Site" flow and requires custom tooling.

Cross-site queries become impossible. You cannot UNION across tables in different databases on different servers (you can UNION across databases on the same server, but that defeats the purpose of separation). Any dashboard or reporting feature that aggregates data across sites must use application-level aggregation.

Connection pooling. Each unique database requires its own connection. If you have 500 sites on 500 databases, a single PHP process might need to open multiple database connections during a request that involves blog switches. Connection pooling via ProxySQL or a similar proxy becomes essential.

When Separate Databases Make Sense

This architecture is appropriate when:

• Individual sites generate enough traffic that they would benefit from dedicated database resources
• Sites have different data retention or compliance requirements (GDPR, data residency)
• You need the ability to independently scale database resources per site
• The network is large enough (1,000+ sites) that the single-database model creates lock contention

For most networks under 500 sites, a single database with read replicas and a persistent object cache will perform adequately.

Performance Benchmarks at Different Network Sizes

The following benchmarks were collected on standardized hardware (8-core AMD EPYC, 32 GB RAM, NVMe SSD) running MariaDB 10.6 with the InnoDB buffer pool sized at 16 GB. The WordPress version was 6.0.x. Each site had approximately 200 posts, 50 pages, and 20 registered users. Redis 7.0 served as the persistent object cache where noted.

Front-Page Load Time (Cold Cache)

This measures the time to serve the front page of a single site in the network, starting from a completely cold cache (Redis flushed, PHP OPcache cleared):

Without a persistent cache, front-page load time increases with network size even when loading a single site. This is because WordPress still queries the global tables (wp_blogs, wp_users, wp_usermeta) during every request, and these tables grow with the network. With Redis, the impact is minimal because the global table data is cached.

Front-Page Load Time (Warm Cache)

The warm cache numbers tell the real story. Without a persistent cache, the "warm" cache is just OPcache helping with PHP compilation; the database still gets hit on every request. With Redis, the database is almost entirely bypassed for read-heavy front-page requests.

Network Admin Sites List

Loading the Network Admin "All Sites" page, which lists sites with pagination:

The default behavior includes SQL_CALC_FOUND_ROWS and full site counts. With the threshold lowered, WordPress skips these expensive operations and the page loads in under 500ms regardless of network size.

Cross-Site Aggregation Query

Fetching the latest post title from every site in the network:

The direct SQL approach scales roughly linearly with network size but at a much lower constant factor. The switch_to_blog() approach also scales linearly but carries the overhead of cache switches and per-site option loading.

Practical Optimization Techniques

With the theory and benchmarks established, here are concrete techniques for improving WordPress Multisite performance in production.

1. Batch switch_to_blog() Operations

If you must use switch_to_blog() in a loop, minimize the work done inside each switch. Pre-fetch any data you can before the loop, and avoid calling functions that trigger cascading queries:

// BAD: Multiple expensive calls per switch
foreach ( $sites as $site ) {
    switch_to_blog( $site->blog_id );

    $title     = get_bloginfo( 'name' );
    $desc      = get_bloginfo( 'description' );
    $url       = home_url();
    $admin     = get_option( 'admin_email' );
    $posts     = wp_count_posts();
    $comments  = wp_count_comments();

    restore_current_blog();
}

// BETTER: Fetch only what you need, cache results
$site_data = wp_cache_get( 'network_site_summary', 'wpkite' );
if ( false === $site_data ) {
    $site_data = array();

    foreach ( $sites as $site ) {
        switch_to_blog( $site->blog_id );

        // wp_load_alloptions() populates the options cache in one query
        wp_load_alloptions();

        $site_data[ $site->blog_id ] = array(
            'name'  => get_option( 'blogname' ),
            'url'   => get_option( 'home' ),
            'email' => get_option( 'admin_email' ),
        );

        restore_current_blog();
    }

    wp_cache_set( 'network_site_summary', $site_data, 'wpkite', HOUR_IN_SECONDS );
}

The key insight: wp_load_alloptions() fetches every autoloaded option for the current blog in a single query. Once called, subsequent get_option() calls for autoloaded options hit the cache instead of the database.

2. Use get_sites() Efficiently

The get_sites() function accepts a fields parameter that controls which columns are returned. If you only need site IDs, ask for IDs:

// Returns full WP_Site objects (more memory, triggers additional queries for each)
$sites = get_sites( array( 'number' => 0 ) );

// Returns only blog IDs (minimal memory, no additional queries)
$site_ids = get_sites( array( 'number' => 0, 'fields' => 'ids' ) );

On a network with 1,000 sites, the difference between full objects and IDs is approximately 4 MB of memory and 1,000 additional cache lookups.

Also be careful with the number parameter. Setting 'number' => 0 fetches all sites. If you are building a paginated interface, set number and offset appropriately:

$sites = get_sites( array(
    'number' => 50,
    'offset' => ( $page - 1 ) * 50,
    'orderby' => 'id',
    'order' => 'ASC',
) );

3. Implement Network-Level Transients

WordPress provides get_site_transient() and set_site_transient() for network-wide cached data. Use these for expensive cross-site aggregations:

function wpkite_get_network_post_counts() {
    $counts = get_site_transient( 'network_post_counts' );
    if ( false !== $counts ) {
        return $counts;
    }

    global $wpdb;
    $sites = get_sites( array( 'number' => 0, 'fields' => 'ids' ) );
    $counts = array();

    foreach ( $sites as $blog_id ) {
        $prefix = $wpdb->get_blog_prefix( $blog_id );
        $count = $wpdb->get_var(
            "SELECT COUNT(*) FROM {$prefix}posts WHERE post_status = 'publish' AND post_type = 'post'"
        );
        $counts[ $blog_id ] = intval( $count );
    }

    set_site_transient( 'network_post_counts', $counts, 6 * HOUR_IN_SECONDS );
    return $counts;
}

The transient prevents the cross-site query from running on every page load. The 6-hour expiration means the data is reasonably fresh without imposing constant load.

4. Avoid wp_get_sites() (Deprecated) and Legacy Patterns

The function wp_get_sites() was deprecated in WordPress 4.6 in favor of get_sites(). If you encounter legacy code using wp_get_sites(), migrate it. The old function has worse performance characteristics and lacks the query optimization available in WP_Site_Query.

Similarly, watch for code that uses $wpdb->blogs directly instead of get_sites(). Direct queries against wp_blogs bypass the site cache layer and will not benefit from the optimizations WordPress has built into WP_Site_Query.

5. Custom Global Tables for Shared Data

If you frequently need to aggregate data across sites (e.g., a network activity feed or a global search), consider creating a custom global table that gets populated via hooks:

// Create the global table
function wpkite_create_network_posts_table() {
    global $wpdb;

    $table = $wpdb->base_prefix . 'network_recent_posts';

    $charset_collate = $wpdb->get_charset_collate();
    $sql = "CREATE TABLE IF NOT EXISTS {$table} (
        id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
        blog_id bigint(20) unsigned NOT NULL,
        post_id bigint(20) unsigned NOT NULL,
        post_title text NOT NULL,
        post_date datetime NOT NULL,
        post_url varchar(255) NOT NULL,
        PRIMARY KEY (id),
        KEY blog_post (blog_id, post_id),
        KEY post_date (post_date)
    ) {$charset_collate};";

    require_once ABSPATH . 'wp-admin/includes/upgrade.php';
    dbDelta( $sql );
}

// Populate on publish
add_action( 'publish_post', function( $post_id, $post ) {
    global $wpdb;

    $table = $wpdb->base_prefix . 'network_recent_posts';
    $blog_id = get_current_blog_id();

    $wpdb->replace( $table, array(
        'blog_id'    => $blog_id,
        'post_id'    => $post_id,
        'post_title' => $post->post_title,
        'post_date'  => $post->post_date,
        'post_url'   => get_permalink( $post_id ),
    ) );

    // Keep only the latest 1000 entries
    $wpdb->query( "DELETE FROM {$table} WHERE id NOT IN (
        SELECT id FROM (SELECT id FROM {$table} ORDER BY post_date DESC LIMIT 1000) tmp
    )" );
}, 10, 2 );

// Fast network-wide recent posts query
function wpkite_get_network_recent_posts( $limit = 20 ) {
    global $wpdb;
    $table = $wpdb->base_prefix . 'network_recent_posts';

    return $wpdb->get_results( $wpdb->prepare(
        "SELECT * FROM {$table} ORDER BY post_date DESC LIMIT %d",
        $limit
    ) );
}

This pattern trades write-time overhead (an extra INSERT on every publish) for dramatically faster read-time queries. Instead of looping through 500 sites to find recent posts, you query a single table.

6. Lazy-Load Blog Switches

If your code conditionally needs data from other sites, defer the switch until you are certain you need it:

// BAD: Always switches, even if $show_network_posts is false
function wpkite_maybe_show_network_posts() {
    $show = get_option( 'wpkite_show_network_posts' );

    $sites = get_sites( array( 'number' => 10, 'fields' => 'ids' ) );
    $posts = array();

    foreach ( $sites as $blog_id ) {
        switch_to_blog( $blog_id );
        // ... fetch posts ...
        restore_current_blog();
    }

    if ( $show ) {
        return $posts;
    }
    return array();
}

// BETTER: Only switches if needed
function wpkite_maybe_show_network_posts() {
    $show = get_option( 'wpkite_show_network_posts' );

    if ( ! $show ) {
        return array();
    }

    $sites = get_sites( array( 'number' => 10, 'fields' => 'ids' ) );
    $posts = array();

    foreach ( $sites as $blog_id ) {
        switch_to_blog( $blog_id );
        // ... fetch posts ...
        restore_current_blog();
    }

    return $posts;
}

This seems obvious in isolation, but in large codebases with multiple contributors, it is surprisingly common to find blog switches happening inside functions that are called unconditionally but whose results are only used conditionally.

7. Connection Pooling with ProxySQL

For networks using HyperDB or LudicrousDB with multiple database servers, ProxySQL acts as a connection multiplexer between PHP and MySQL. Without it, each PHP-FPM worker maintains its own connection to each database server it contacts. With 50 PHP-FPM workers and 10 database servers, that is 500 connections.

ProxySQL sits between PHP and MySQL, pooling connections so that 50 PHP workers share a smaller pool of persistent connections to each database. Configuration is beyond the scope of this article, but the key settings are:

-- ProxySQL configuration for WordPress Multisite
INSERT INTO mysql_servers (hostgroup_id, hostname, port, weight) VALUES
(10, 'db-primary.example.com', 3306, 1000),
(20, 'db-replica-1.example.com', 3306, 500),
(20, 'db-replica-2.example.com', 3306, 500);

-- Route writes to primary (hostgroup 10), reads to replicas (hostgroup 20)
INSERT INTO mysql_query_rules (rule_id, active, match_digest, destination_hostgroup) VALUES
(1, 1, '^SELECT', 20),
(2, 1, '^INSERT|^UPDATE|^DELETE|^REPLACE', 10);

8. Monitor Query Performance Per Site

Use the Query Monitor plugin on Multisite networks to identify slow queries. Query Monitor is network-aware and will show you which blog context a query executes in. This is invaluable for tracking down performance problems that only affect specific sites.

For production monitoring without a browser-based plugin, log slow queries at the MySQL level:

# In my.cnf or mariadb.cnf
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5
log_queries_not_using_indexes = 1

Parse the slow query log to identify which site tables appear most frequently. A site with a poorly indexed custom postmeta query can drag down the entire database server, affecting all sites on the network.

9. Optimize wp_options Per Site

Each site's wp_N_options table tends to accumulate bloat over time. Transients (if not stored in the object cache) pile up. Plugins store serialized data blobs. Autoloaded options grow unbounded.

Audit autoloaded options per site:

// Run this via WP-CLI for a specific site
// ddev wp eval 'echo wpkite_check_autoload_size();' --url=site42.example.com

function wpkite_check_autoload_size() {
    global $wpdb;

    $size = $wpdb->get_var(
        "SELECT SUM(LENGTH(option_value)) FROM {$wpdb->options} WHERE autoload = 'yes'"
    );

    $count = $wpdb->get_var(
        "SELECT COUNT(*) FROM {$wpdb->options} WHERE autoload = 'yes'"
    );

    return sprintf(
        "Autoloaded options: %d entries, %s total size\n",
        $count,
        size_format( $size )
    );
}

// Network-wide audit
function wpkite_network_autoload_audit() {
    global $wpdb;

    $sites = get_sites( array( 'number' => 0, 'fields' => 'ids' ) );
    $report = array();

    foreach ( $sites as $blog_id ) {
        $prefix = $wpdb->get_blog_prefix( $blog_id );
        $size = $wpdb->get_var(
            "SELECT SUM(LENGTH(option_value)) FROM {$prefix}options WHERE autoload = 'yes'"
        );
        $report[ $blog_id ] = intval( $size );
    }

    arsort( $report );
    return $report;
}

Healthy autoload sizes are under 500 KB. If a site's autoloaded options exceed 1 MB, investigate which options are responsible and either disable autoloading for large values or move them to a custom table.

10. WP-CLI Commands for Network Maintenance

WP-CLI is the most efficient way to perform maintenance across a Multisite network. The --url flag lets you target specific sites, and shell loops let you iterate:

# Clear transients across all sites
ddev wp site list --field=url | xargs -I {} ddev wp transient delete --all --url={}

# Check autoloaded option sizes across the network
ddev wp site list --field=url | while read url; do
    size=$(ddev wp eval 'global $wpdb; echo $wpdb->get_var("SELECT SUM(LENGTH(option_value)) FROM '$wpdb->options' WHERE autoload=\"yes\"");' --url="$url")
    echo "$url: $size bytes"
done

# Optimize tables for all sites
ddev wp db query "SELECT CONCAT('OPTIMIZE TABLE ', table_name, ';') FROM information_schema.tables WHERE table_schema = DATABASE() AND engine = 'InnoDB'" --skip-column-names | ddev wp db query

For scheduled maintenance, create a custom WP-CLI command that handles the network iteration internally, with progress bars and error handling:

if ( defined( 'WP_CLI' ) && WP_CLI ) {
    WP_CLI::add_command( 'wpkite-network', 'WPKite_Network_CLI' );
}

class WPKite_Network_CLI {

    /**
     * Optimize autoloaded options across the network.
     *
     * ## OPTIONS
     *
     * [--dry-run]
     * : Show what would be changed without making changes.
     *
     * @subcommand optimize-autoload
     */
    public function optimize_autoload( $args, $assoc_args ) {
        $dry_run = isset( $assoc_args['dry-run'] );
        $sites = get_sites( array( 'number' => 0, 'fields' => 'ids' ) );

        $progress = \WP_CLI\Utils\make_progress_bar( 'Optimizing sites', count( $sites ) );

        foreach ( $sites as $blog_id ) {
            switch_to_blog( $blog_id );

            global $wpdb;

            // Find non-core options larger than 100KB that are autoloaded
            $large_options = $wpdb->get_results(
                "SELECT option_name, LENGTH(option_value) as size
                 FROM {$wpdb->options}
                 WHERE autoload = 'yes'
                 AND LENGTH(option_value) > 102400
                 AND option_name NOT IN ('active_plugins', 'widget_block', 'sidebars_widgets', 'cron')"
            );

            foreach ( $large_options as $opt ) {
                if ( $dry_run ) {
                    WP_CLI::log( sprintf(
                        'Site %d: Would disable autoload for %s (%s)',
                        $blog_id,
                        $opt->option_name,
                        size_format( $opt->size )
                    ) );
                } else {
                    $wpdb->update(
                        $wpdb->options,
                        array( 'autoload' => 'no' ),
                        array( 'option_name' => $opt->option_name )
                    );
                    WP_CLI::log( sprintf(
                        'Site %d: Disabled autoload for %s (%s)',
                        $blog_id,
                        $opt->option_name,
                        size_format( $opt->size )
                    ) );
                }
            }

            restore_current_blog();
            $progress->tick();
        }

        $progress->finish();
        WP_CLI::success( $dry_run ? 'Dry run complete.' : 'Optimization complete.' );
    }
}

Architecture Decision Framework

Choosing the right scaling strategy depends on your network's size, traffic pattern, and operational capacity. Here is a decision framework based on practical experience:

Under 50 Sites

A single database server with a persistent object cache (Redis or Memcached) handles this size comfortably. Focus on:

• Installing and configuring Redis with the WordPress object cache drop-in
• Ensuring wp_options autoload sizes stay reasonable per site
• Using get_sites() with fields => 'ids' wherever possible
• Avoiding unnecessary switch_to_blog() calls in theme and plugin code

At this scale, the default MySQL configuration with minor tuning (increase InnoDB buffer pool to 70% of available RAM) is sufficient.

50 to 500 Sites

Add read replicas and tune MySQL/MariaDB:

• Deploy 1-2 read replicas using standard MySQL replication
• Use HyperDB or LudicrousDB for read/write splitting
• Lower the wp_is_large_network() threshold to match your actual site count
• Implement custom global tables for any cross-site data aggregation features
• Schedule regular network-wide maintenance (transient cleanup, autoload optimization)
• Size Redis appropriately (1-2 GB minimum)

500 to 5,000 Sites

This range requires database sharding or per-group database separation:

• Shard site-specific tables across 2-4 database servers using LudicrousDB routing
• Keep global tables on a dedicated primary with read replicas
• Deploy ProxySQL for connection pooling
• Implement aggressive caching strategies including full-page caching per site
• Use direct SQL queries instead of switch_to_blog() loops for any administrative aggregation
• Size Redis at 4-8 GB with allkeys-lru eviction

5,000+ Sites

At this scale, you are operating a platform, not a website. The architecture shifts to:

• Separate database servers per site or per group of 50-100 sites
• Dedicated MySQL instances for global tables with multiple read replicas
• Event-driven data aggregation (populate global summary tables via hooks rather than querying across sites)
• Consider whether WordPress Multisite is still the right architecture, or whether independent WordPress installations managed by a deployment tool (e.g., WordPress VIP's infrastructure, Flavius, or a custom Kubernetes-based deployment) would be simpler to operate
• Full-page caching at the edge (Varnish, Cloudflare, Fastly) becomes mandatory
• Redis Cluster or a sharded Redis setup for object cache

Common Pitfalls and How to Avoid Them

The "Accidental Global Query" Problem

Plugins designed for single-site WordPress sometimes run queries that inadvertently scan global tables without realizing the scale implications. A plugin that calls count_users() on activation, for example, will trigger a full scan of wp_usermeta to count users by role. On a network with 100,000 usermeta rows, this query can take 5+ seconds and locks the table for writes during execution.

Audit every plugin before deploying it on a Multisite network. Look for:

• Direct queries against $wpdb->users or $wpdb->usermeta without LIMIT clauses
• Calls to get_users() with 'number' => -1 or 'number' => 0
• Calls to count_users() without caching the result
• Admin dashboard widgets that aggregate data on every page load

The "Forgotten restore_current_blog()" Bug

Failing to call restore_current_blog() after a switch_to_blog() leaves the global state pointed at the wrong site. All subsequent WordPress function calls in that request will operate against the wrong blog. This bug is insidious because it does not always produce visible errors. Instead, it silently writes data to the wrong site's tables or serves content from the wrong site's cache.

Always use try/finally patterns when switching blogs in code that might throw exceptions:

switch_to_blog( $target_blog_id );
try {
    // Do work that might fail
    $result = some_risky_operation();
} finally {
    restore_current_blog();
}

PHP 5.5+ supports try/finally without a catch block, making this pattern clean and safe.

The "Transient Bloat" Problem

Without a persistent object cache, WordPress stores transients in the wp_options table (or wp_N_options for per-site transients). Expired transients are only cleaned up when they are accessed, not proactively. A site with hundreds of transients that are set but rarely read will accumulate thousands of stale rows in its options table.

With Redis or Memcached as the object cache, transients are stored in the cache backend with proper TTLs and never touch the database. This alone can reduce per-site options table size by 30-60%.

If you cannot deploy a persistent object cache, schedule regular cleanup:

// Clean expired transients for all sites
add_action( 'wpkite_transient_cleanup', function() {
    $sites = get_sites( array( 'number' => 0, 'fields' => 'ids' ) );

    foreach ( $sites as $blog_id ) {
        switch_to_blog( $blog_id );

        global $wpdb;
        $wpdb->query(
            "DELETE a, b FROM {$wpdb->options} a
             INNER JOIN {$wpdb->options} b ON b.option_name = REPLACE(a.option_name, '_transient_timeout_', '_transient_')
             WHERE a.option_name LIKE '\_transient\_timeout\_%'
             AND a.option_value < UNIX_TIMESTAMP()"
        );

        restore_current_blog();
    }
} );

if ( ! wp_next_scheduled( 'wpkite_transient_cleanup' ) ) {
    wp_schedule_event( time(), 'daily', 'wpkite_transient_cleanup' );
}

Monitoring and Alerting for Multisite Networks

Performance optimization is not a one-time effort. Networks grow, plugins get added, and traffic patterns shift. Establish monitoring for these key metrics:

Database query count per request. Track the total number of queries per page load across the network. A sudden spike often indicates a new plugin or a cache failure. Use the $wpdb->num_queries property at the end of each request:

add_action( 'shutdown', function() {
    global $wpdb;
    if ( $wpdb->num_queries > 100 ) {
        error_log( sprintf(
            'High query count: %d queries for %s on blog %d',
            $wpdb->num_queries,
            $_SERVER['REQUEST_URI'] ?? 'CLI',
            get_current_blog_id()
        ) );
    }
} );

Object cache hit rate. Redis provides INFO stats which shows keyspace_hits and keyspace_misses. A healthy cache hit rate is above 90%. If it drops below 80%, investigate whether Redis is running out of memory and evicting keys too aggressively, or whether a plugin is bypassing the cache.

Table sizes. Monitor the row count and data size of wp_usermeta, wp_blogs, and each site's wp_N_options table. Growth that outpaces site/user creation indicates bloat.

Replication lag. If you are using read replicas, monitor the Seconds_Behind_Master metric. Lag above 5 seconds can cause data inconsistency bugs. Lag above 30 seconds usually indicates the replica cannot keep up with write volume and needs more I/O capacity.

Setting up these monitoring points gives you early warning before performance problems become user-facing incidents. The best time to optimize is when the dashboard tells you a metric is trending in the wrong direction, not when users start complaining about slow page loads.

Multisite performance management is an ongoing discipline. The techniques in this article provide a foundation, but every network has its own profile of traffic patterns, plugin stacks, and operational constraints. Measure first, optimize based on data, and re-measure to verify your changes produced the expected improvement.