A WordPress multisite network is not one website with extra pages. It is dozens — sometimes hundreds — of sites sharing one codebase, one database, and one server. That sharing is the whole point of multisite, and it is also why a network can feel fast when it has ten sites and crawl when it has fifty.
The good news: most multisite slowness comes from a handful of predictable causes, and none of them require you to rebuild the network. The bad news: the fixes that work on a single site do not always translate cleanly, because a change made at the network level touches every subsite at once.
This guide walks through how to speed up a WordPress multisite network safely — what to optimize globally, what to handle per site, and what to avoid so you don’t break a subsite while fixing another.
Why Multisite Gets Slow Differently
On a single WordPress site, performance problems are usually local: a heavy theme, an unoptimized image, a chatty plugin. On a network, the same problems compound. Every subsite adds its own tables to the shared database — nine or more per site — so a network with 100 sites carries close to a thousand tables. Plugins network-activated on all sites run their code on every subsite whether that subsite uses them or not. And a traffic spike on one popular subsite eats server resources that every other subsite shares.
That shared-resource reality shapes every decision below. On multisite, you optimize the platform first and individual sites second, and you test changes on one subsite before rolling them out network-wide.
Step 1: Fix the Foundation Before Touching Plugins
Check whether your hosting actually fits a network
A plan that handled one site comfortably may not handle a network. Multisite needs more PHP memory, more database capacity, and headroom for traffic spikes across many sites at once. As a starting point, a network of any real size should run on hosting with at least 512 MB of PHP memory (WordPress multisite itself will not use all of it, but plugins and themes on busy subsites will), a database server that is not shared with dozens of other accounts, and PHP 8.x. If your host caps database size aggressively or throttles CPU on shared plans, no plugin will save you — the bottleneck is the server. For a fuller comparison of what to look for, see our guide on choosing fast WordPress hosting (https://wpspeedaudits.site/best-wordpress-hosting-for-speed/).
Keep the network lean
Every network-activated plugin loads on every subsite. Audit your network plugins ruthlessly: if a plugin is only used by two subsites, activate it on those two subsites only, not network-wide. Deactivate and delete anything nobody uses. The same applies to themes — network-enabled themes that no subsite uses still cost nothing at runtime, but they do cost maintenance and update risk, so prune them.
This is the same discipline as a single-site plugin audit, just with higher stakes: one bad network plugin slows every site you run.
Step 2: Set Up Caching at the Network Level
Caching is where multisite optimization pays off fastest, because a good cache configuration benefits every subsite at once.
Page caching, configured once
Most caching plugins support multisite, but they behave differently on a network. Some require network activation; others are configured per subsite. Either way, the rules are the same: cache anonymous visitors aggressively, never cache logged-in users or admin pages, and exclude cart and checkout pages on any subsite running WooCommerce. A single misconfigured cache rule — caching a logged-in dashboard page, for example — can leak one user’s content to another, so after enabling page caching, test a logged-in session and a logged-out session on at least two subsites before calling it done.
Object caching: the multisite multiplier
If page caching is the biggest win for anonymous traffic, object caching is the biggest win for logged-in traffic and for the database. Multisite databases are large by nature, and every page load that is not served from page cache triggers queries against those tables. An object cache (Redis or Memcached) stores the results of common queries in memory so the database is not hit repeatedly for the same data.
This matters more on multisite than on a single site because the shared database is the network’s single biggest contention point. Set up Redis or Memcached at the server level, install the matching drop-in (object-cache.php) once at the network level, and every subsite benefits without individual configuration. Our step-by-step Redis setup guide (https://wpspeedaudits.site/how-to-set-up-redis-cache-for-wordpress/) covers the installation and verification; on multisite the process is the same, it just pays off across every site at once.
One caution: object caching does not replace page caching, and it will not fix a database that is genuinely bloated — it just reduces how often that bloat is queried. Clean the database too (Step 4).
Step 3: Control Per-Site Bloat Before It Spreads
A network’s speed is often decided by its worst subsite. One subsite with a page builder loading twenty stylesheets, or a media library full of unresized images, drags down shared resources for everyone.
Give subsites sensible defaults
Use a network default theme that is genuinely fast — a lightweight theme with minimal JavaScript — and resist the urge to network-enable every theme in your library. If subsite owners can install their own themes and plugins, set clear rules: no page-builder-heavy themes without a performance review, no slider plugins, no image uploads larger than a reasonable limit. Where possible, enforce image sizes with a plugin that resizes uploads automatically, so one careless upload does not become a multi-megabyte hero image on a shared server.
Audit the heavy subsites individually
When the network feels slow, do not guess which subsite is responsible. Check server-level resource usage per subsite (most hosts show this per domain or subdomain), and run speed tests on your five busiest subsites. Fix the worst offenders first: a single subsite with a misbehaving plugin can account for a disproportionate share of database queries, and removing it helps the whole network.
Step 4: Tame the Shared Database
A multisite database grows in ways a single-site database does not. Each new subsite adds its own set of tables, and each subsite accumulates its own revisions, transients, spam comments, and orphaned metadata. Over time, autoloaded options — data WordPress loads on every single page request — can balloon, because every network-activated plugin can add its own autoloaded rows.
What to clean, and how often
Run a database cleanup on a schedule, not as a one-off emergency. The safe targets are the same as on a single site: post revisions (cap them going forward with WP_POST_REVISIONS in wp-config.php), expired transients, spam and trashed comments, and orphaned postmeta left behind by deleted plugins. Our database cleanup guide (https://wpspeedaudits.site/wordpress-database-cleanup-speed-up/) walks through each of these with safe methods — follow it, but run it on a staging copy of the network first if you have more than a handful of subsites, because a cleanup plugin that misbehaves on a network touches every subsite’s tables.
Cap revisions and autosaves network-wide
Add these two lines to wp-config.php and they apply to every subsite:
define( ‘WP_POST_REVISIONS’, 5 );
define( ‘AUTOSAVE_INTERVAL’, 300 );
Five revisions per post is plenty for almost every subsite, and a five-minute autosave interval cuts down on the background write load that a busy network generates. This is a small change with a network-wide effect — exactly the kind of fix multisite rewards.
Step 5: Replace WP-Cron With a Real Cron Job
WP-Cron is triggered by site visits, and on a network that creates a specific problem: scheduled tasks for every subsite are checked on visits to any subsite, and on low-traffic subsites tasks can run late or pile up. Worse, a traffic spike on one subsite can trigger a backlog of cron events for others, adding load at exactly the wrong moment.
The fix is the same as on a single site, applied once at the network level: disable WP-Cron in wp-config.php with define( ‘DISABLE_WP_CRON’, true ); and set up a real server cron job that hits wp-cron.php on a schedule. Our full walkthrough (https://wpspeedaudits.site/disable-wp-cron-real-cron-job/) covers the server cron setup and how to verify events are actually firing. On multisite, point the server cron at the main site’s wp-cron.php — it processes the network’s scheduled tasks — and verify with a plugin like WP Crontrol that events across subsites are running on time.
Step 6: Handle Domain Mapping and SSL Correctly
Most networks use either subdomains or subdirectories, and many map custom domains onto subsites. Each setup has a performance trap.
On subdirectory installs, a misconfigured redirect (www vs non-www, HTTP vs HTTPS) can create redirect chains that cost every visitor an extra round trip — on every subsite. Audit your redirects with a redirect checker on the main site and at least one mapped domain. On subdomain installs, make sure your wildcard SSL certificate actually covers all subdomains; a certificate error on one subsite does not just look bad, it blocks that subsite entirely for some visitors.
If you use a CDN, configure it for the whole network, not per subsite. A CDN that caches the main site but not mapped domains leaves your most important subsites unprotected, and a CDN rule that caches logged-in pages on one subsite can repeat the logged-in-cache mistake across the network.
What Not to Do on Multisite
Some optimizations that are safe on a single site are risky on a network:
- Do not network-activate a new caching or optimization plugin on a live network without testing it on a staging copy first. A plugin that breaks one subsite’s layout breaks your credibility with every subsite owner.
- Do not run aggressive database optimization (table optimization, index changes) directly on the live network database. Back up first, test on staging, and schedule it during low traffic.
- Do not delete subsite tables by hand from the database. Use the network admin’s delete-site flow, which cleans up tables, uploads, and options properly. Orphaned tables from manual deletes are a classic source of slow queries later.
- Do not assume a fix that helped one subsite will help all of them. Test per subsite, roll out network-wide only after verification.
A Sensible Rollout Order
If you are starting from a slow network, work in this order:
- Confirm hosting headroom and PHP version.
- Prune network-activated plugins to what every subsite genuinely needs.
- Set up page caching and object caching at the network level.
- Clean the database and cap revisions network-wide.
- Replace WP-Cron with a real cron job.
- Audit your heaviest subsites individually.
- Fix redirects, SSL, and CDN coverage for mapped domains.
Each step is independently verifiable — test the network’s busiest subsites after each one — so if something regresses, you know exactly which change caused it.
The Bottom Line
Multisite speed is platform speed. You are not optimizing one website; you are maintaining a shared platform that many websites depend on. That means the highest-leverage work is always the work that helps every subsite at once: better hosting headroom, network-level caching, a clean shared database, and a real cron job. Per-site fixes matter, but they matter most when they remove a single bad actor dragging the whole network down.
Treat the network like infrastructure, test every change on one subsite before rolling it out to all of them, and a multisite network can be just as fast as any single WordPress site — it just demands more discipline to keep it that way.
