WordPress multisite performance vraagt om een andere aanpak dan die van een single site. Waar je bij één website vaak met standaard caching en een nette hosting al een heel eind komt, draait een multisite-netwerk op gedeelde resources die snel een bottleneck vormen. Eén trage site kan het hele netwerk vertragen, en optimalisaties die op een single site prima werken, kunnen op multisite juist averechts uitpakken.
In dit artikel lees je wat er technisch anders is aan multisite, waar de grootste performance-valkuilen zitten en hoe je ze oplost. Van database-structuur tot caching, plugins en server-setup.
Wat maakt multisite technisch anders?
Een WordPress multisite draait op één codebase, één wp-config.php en één database. Maar binnen die database krijgt elke subsite zijn eigen set tabellen. Een subsite met ID 2 heeft bijvoorbeeld wp_2_posts, wp_2_options en wp_2_postmeta. Alleen de echt gedeelde tabellen (zoals wp_users en wp_usermeta) blijven ongeprefixt.
Dit betekent dat je database explosief groeit in aantal tabellen. Een netwerk met 200 subsites heeft al snel 2.000+ tabellen. MySQL kan daar prima mee omgaan, maar je hosting en backup-tools niet altijd.
Daarnaast laadt WordPress bij elk request informatie over het hele netwerk via wp_sitemeta en wp_blogs. Deze queries draaien op elke pagina op elke subsite. Als je netwerk groeit, groeit de overhead mee.
Wil je de basis van een WordPress-request begrijpen, lees dan eerst wat er gebeurt tijdens een WordPress request. Die kennis helpt om multisite-specifieke bottlenecks te herkennen.
De database: je grootste bottleneck
Bij een single site kun je MySQL vaak op standaardinstellingen laten draaien. Bij multisite niet. Het aantal tabellen, de grootte van wp_options per subsite en de complexe queries op het netwerkniveau maken databasetuning essentieel.
Tabellen per subsite
Elke keer dat een subsite wordt aangemaakt, krijgt deze een eigen set van zo'n 10 tabellen. Bij 500 subsites zit je op 5.000 tabellen. MySQL heeft een table_open_cache setting die bepaalt hoeveel tabellen tegelijk open kunnen zijn. Staat deze te laag, dan moet MySQL continu tabellen openen en sluiten, een zware operatie.
Voor een grote multisite verhoog je deze waarde fors:
table_open_cache = 8000
table_definition_cache = 4000
open_files_limit = 65535
Autoloaded options per site
Elke subsite heeft zijn eigen wp_X_options tabel met autoloaded options. Een plugin die op één site 2 MB aan autoloaded data toevoegt, doet dat op elke actieve site. Bij 100 sites heb je ineens 200 MB aan autoload-data die bij elk request geladen kan worden (per site, niet gedeeld).
Lees autoloaded options: stille performance killer voor een diepgaande aanpak, bij multisite moet je dit per subsite uitvoeren, of via een netwerkbreed script.
MySQL tuning
Algemene MySQL-optimalisatie voor WordPress is bij multisite nog belangrijker. Verhoog je innodb_buffer_pool_size tot minstens 50-70% van je beschikbare RAM. Bij veel subsites wil je dat zoveel mogelijk tabellen in-memory beschikbaar zijn.
Caching werkt anders op multisite
Caching lijkt simpel, maar op multisite zitten er gemene valkuilen. Elke cache-laag moet weten bij welke site de data hoort.
Object caching en key prefixing
Gebruik je Redis object caching, dan moet de plugin correct WP_CACHE_KEY_SALT of een vergelijkbare prefix gebruiken per site. Zonder prefixing kunnen subsites elkaars cachewaardes opvragen of overschrijven.
De meeste moderne Redis-plugins (zoals Redis Object Cache van Till Krüss) ondersteunen multisite out of the box. Controleer dit in je wp-config.php:
define('WP_CACHE_KEY_SALT', 'jouwnetwerk_');
Zonder deze salt delen alle sites één cache-namespace. Dat kan werken als je expliciet wilt dat bepaalde data gedeeld wordt, maar meestal wil je isolatie.
Full page caching
Bij full page caching via NGINX of plugins moet je cache-keys uitbreiden met de hostname. NGINX doet dit standaard via $host in de fastcgi_cache_key, maar dubbelcheck je config. Een verkeerde key betekent dat site-a.nl de cached versie van site-b.nl te zien krijgt.
Cache invalidatie
Op multisite wil je dat een update op subsite 5 alleen de cache van subsite 5 leeggooit. Veel plugins hebben een "purge all" optie die álle sites leegt, funest bij hoge traffic. Kies voor caching-oplossingen die per-site invalidation ondersteunen.
Plugins: het veelvoud-probleem
Een plugin die op een single site 50ms extra toevoegt aan elk request, doet dat op multisite ook. Per site. Per request. Bij 100 actieve subsites met gemiddeld 10 requests per minuut is dat 50 seconden aan extra CPU-tijd per minuut, alleen voor die ene plugin.
Network-activated vs per-site
Network-activated plugins laden op elk request op elke site. Dat is handig voor beheer, maar rampzalig als de plugin op de meeste sites niet nodig is. Vraag jezelf bij elke plugin af: moet deze echt netwerkbreed aan?
Plugins die je beter per-site activeert:
- Contactformulieren (niet elke site heeft ze nodig)
- Shop-functionaliteit (WooCommerce alleen op shop-sites)
- Page builders (als niet elke site dezelfde builder gebruikt)
- SEO-plugins (tenzij je centrale SEO-governance wilt)
Plugins identificeren die traagheid veroorzaken
Gebruik Query Monitor netwerkbreed en schakel het per subsite in waar je performance verdacht vindt. Lees debugging van trage plugins voor de methodiek. Op multisite wil je bovendien weten of een plugin per-site overhead toevoegt of netwerkbreed query't.
Server-architectuur voor multisite
Voor een klein multisite-netwerk volstaat één server. Zodra je richting tientallen actieve sites met verkeer gaat, moet je de architectuur herzien.
PHP-FPM pools
Bij single sites kun je met één PHP-FPM pool uitkomen. Op multisite wil je vaak meerdere pools overwegen, vooral als bepaalde sites piekverkeer hebben. Door grote sites in een aparte pool te draaien, voorkom je dat zij alle workers opslokken en de rest van het netwerk plat leggen.
PHP-FPM tuning voor WordPress geldt nog sterker voor multisite: reken voldoende workers per actieve site, en monitor je pm.max_children scherp.
Opslag en uploads
Elke subsite krijgt een eigen map in wp-content/uploads/sites/X/. Bij veel sites en veel media wordt dit zwaar op disk I/O. Overweeg een object storage (S3, Cloudflare R2) voor media via een plugin als WP Offload Media.
Bij een multi-server setup is gedeelde opslag sowieso een must, de uploads-map moet via NFS of objectstorage beschikbaar zijn voor alle webservers.
Netwerkbreed monitoren
Op een single site voldoet één monitoringsetup. Op multisite wil je inzicht per subsite, én op netwerkniveau.
Wat je minimaal wilt weten:
- TTFB per subsite, welke sites zijn traag en welke niet?
- Queries per request per subsite, afwijkers wijzen op plugin- of content-problemen
- Autoload-size per subsite, volg de groei over tijd
- Storage per subsite, uploads en database
- Actieve plugins per subsite, onderhoudsinzicht
Tools als New Relic, Blackfire of een zelfgehoste APM zoals Tideways kunnen per-site metrics leveren. Combineer dit met goede WordPress-loganalyse om trends te spotten.
CDN en edge caching
Een CDN zoals Cloudflare is voor multisite bijna verplicht. Al je subsites profiteren tegelijk van edge caching, en je verlicht de origin-server enorm.
Let op deze punten:
- Domein-mapping: als elke subsite een eigen domein heeft, moet elk domein door de CDN geleid worden. Cloudflare SaaS of een wildcard-SSL setup is vaak de oplossing.
- Cache rules per site: niet elke site heeft dezelfde cache-strategie nodig. Een shop wil geen agressieve HTML-caching, een blog wel.
- Page rules limieten: bij veel sites loop je op het gratis Cloudflare-plan snel tegen de 3-page-rules limiet aan. Upgrade of gebruik Cloudflare Workers voor meer flexibiliteit.
Wanneer multisite niet meer werkt
Multisite is krachtig, maar niet oneindig schaalbaar. Overweeg splitsen naar losse installaties als:
- Meer dan 500 actieve subsites met significant verkeer
- Sites vereisen sterk verschillende PHP-versies of plugins
- Eigenaren willen onafhankelijk beheer en hostingkeuzes
- Performance-issues op één site andere sites structureel raken
- Security-isolatie kritisch is (bijvoorbeeld gevoelige klantdata per site)
Voor de middelgrote netwerken, 10 tot 200 sites met gedeeld beheer, blijft multisite de efficiëntste keuze qua onderhoud. Mits goed getuned. Overweeg ook WordPress zonder plugins als filosofie: hoe minder plugins je netwerkbreed activeert, hoe sneller je netwerk blijft.
Praktische checklist voor multisite performance
Gebruik deze checklist als je een multisite-netwerk optimaliseert:
- MySQL getuned met verhoogde
table_open_cacheeninnodb_buffer_pool_size - Autoloaded options per subsite opgeschoond
- Redis object caching met correcte
WP_CACHE_KEY_SALT - Full page caching met hostname in cache-key
- Network-activated plugins kritisch tegen het licht gehouden
- PHP-FPM pools afgestemd op verwacht verkeer
- CDN met correcte per-site cache rules
- Media op object storage voor multi-server setups
- Per-site monitoring met TTFB, queries en autoload-grootte
- Backup-strategie die omgaat met duizenden tabellen
Doorloop je deze checklist, dan haal je verreweg de meeste multisite-specifieke bottlenecks eruit. Voor verdere verdieping op Core Web Vitals geldt dat de meeste single-site adviezen ook voor multisite werken, de uitdaging zit bijna altijd in de gedeelde laag.
Veelgestelde vragen
Wat is WordPress multisite precies? WordPress multisite is een functie waarmee je meerdere websites draait vanuit één WordPress-installatie. Alle sites delen de core, plugins, thema's en database, maar hebben elk hun eigen content en instellingen.
Is een multisite sneller of trager dan losse sites? Een multisite is niet inherent trager, maar schaalt anders. Bij veel sites of veel verkeer kan de gedeelde database een bottleneck worden. Met de juiste caching-strategie en databaseoptimalisatie blijft een multisite snel.
Werkt Redis object caching goed met multisite? Ja, maar je moet zorgen voor correcte cache key prefixing per site. Zonder goede isolatie kunnen sites elkaars cache overschrijven of vervuilen. De meeste Redis-plugins ondersteunen multisite native.
Hoeveel sites kan één WordPress multisite aan? Dat hangt af van je server, database en content. Technisch draaien multisites met duizenden subsites, maar de praktijk is vaak beperkt tot een paar honderd actieve sites voordat performance een serieuze uitdaging wordt.
Moet ik overstappen van multisite naar losse installaties? Alleen als je sites totaal verschillende functionaliteit of eigenaren hebben. Voor netwerken met gedeeld beheer en vergelijkbare functionaliteit blijft multisite efficiënter qua onderhoud, ook als je tegen performance-grenzen aanloopt.