WordPress Multisite Speed Checker

1. WordPress Multisite Database Schema & Table Scaling

A WordPress Multisite install is not one database logically split by site — it's a single physical MySQL database holding a full, separate table set for every sub-site, all queried through the same connection pool. The network registry lives in two global tables, wp_site and wp_blogs, which map each sub-site to its own table prefix. As documented in WordPress Multisite Documentation, the first site created (site ID 1) keeps the familiar base wp_ prefix, while every additional sub-site gets a numbered set — wp_2_posts, wp_2_options, wp_3_posts, wp_3_postmeta, and so on. A 200-site network can easily carry well over a thousand tables in a single schema.

Not everything is duplicated, though. wp_users and wp_usermeta are global — every sub-site authenticates against the same user table, which enables single sign-on across the network but also means user-table bloat or a slow login query can affect every sub-site at once. Network administration adds its own overhead too, in the form of wp_sitemeta (network-wide options) and wp_registration_log (signup tracking) — tables that don't exist on a standalone, single-site WordPress install at all.

2. Subdomain vs. Subfolder Routing Latency

Multisite can route sub-sites two ways: subdomains (site2.network.com), which require wildcard DNS and, historically, a sunrise.php domain-mapping drop-in, or subfolders (network.com/site2/), which rely on rewrite rules within a single domain. In practice, neither routing style meaningfully changes response speed — both ultimately hit the exact same MySQL instance and the exact same PHP worker pool on the origin server. The routing layer only decides how the request URL is parsed to pick a table prefix; it adds negligible overhead compared to shared-resource contention between sub-sites.

Find ideal hosting architectures in our WordPress Hosting Recommendation Quiz.

3. Auditing Database Size & Table Bloat

Multisite networks tend to accumulate database bloat faster than single-site installs simply because more sites are generating post revisions, orphaned transients, and postmeta rows in parallel, all inside one shared schema. Estimate database table bloat in our WordPress Database Size Analyzer.

4. Decoupling Multisite via Nimbica Static Edge

Nimbica pre-renders WordPress Multisite child sites into static HTML served from 300+ global edge locations, completely eliminating shared database lock contention.

How This Multisite Speed Checker Works, With a Worked Example

When you submit a URL, the tool performs a single live HTTP fetch of that page and times the full round trip from request to first byte received (TTFB). It then scans the raw returned HTML for text signatures commonly associated with Multisite installs: the literal string "wp-blogs," the legacy "blogs.dir" upload path used before WordPress 3.5 introduced per-site upload folders, and the word "network," which frequently appears in network-admin links, network-wide navigation menus, or asset URLs on Multisite front ends. A match on any of these flags the site as a Multisite candidate; no match reports standard single-site routing.

As an illustrative example: scanning a hypothetical agency network at network-example.com might return a TTFB of 340ms, an HTTP 200 status, and "Multisite Network Asset Signatures Detected" because the homepage footer links to /wp-admin/network/. A TTFB in that range combined with a positive Multisite signature is worth investigating further — it suggests checking whether other sub-sites on the same network are competing for the same PHP workers or database connections, rather than assuming the homepage itself is simply unoptimized.

Practical Use Cases

• Agencies auditing a prospective Multisite client: Before onboarding a university, franchise, or publisher network running dozens of sub-sites, run a quick TTFB baseline to see whether the origin server is already under load before taking on optimization work.
• Developers isolating a "why is only this one sub-site slow" ticket: A TTFB reading on the affected sub-site, compared against a reading on the network's flagship site, helps confirm whether a slowdown is sub-site-specific (a bad plugin on that blog) or network-wide (shared database or server contention).
• Hosting migration decisions: Comparing TTFB readings before and after moving a Multisite network to a host with more PHP workers or a managed MySQL tier gives a concrete before/after data point.

Common Mistakes, Limitations & Edge Cases

This checker reports a useful external signal, not a full server-side network audit, and it has real blind spots worth understanding before relying on the result:

• Single-sample TTFB is noisy: One fetch reflects DNS lookup time, TLS handshake, any CDN/proxy in front of the origin, and momentary server load — not a stable average. Run the check a few times across different times of day before drawing conclusions.
• Text-signature detection is heuristic, not authoritative: The word "network" appears on plenty of ordinary sites (restaurant networks, ad networks, social network icons) with no relation to WordPress Multisite, which can produce false positives. Cached, minified, or domain-mapped Multisite front ends often never render the literal strings the tool looks for, producing false negatives — a "Single Site" result does not prove a network isn't running Multisite underneath.
• No direct database access: The tool cannot query wp_blogs, count sub-sites, or measure actual MySQL query time — that level of detail requires server or wp-admin access, which an external URL check cannot obtain.
• One URL, one moment in time: The result reflects only the specific page fetched at the moment of the request; it says nothing about how that origin performs under concurrent traffic from multiple sub-sites at once.