Real-time samenwerking in WordPress 7.0: wat hosting moet voorbereiden

De grote feature van WordPress 7.0 is niet de AI Connectors-pagina. Het is real-time samenwerking: meerdere mensen tegelijk aan dezelfde pagina of post werken, met live cursors, aanwezigheidsindicatoren en automatische conflictresolutie via Yjs, een CRDT-framework (conflict-free replicated data type). Google Docs-gedrag, maar dan in WordPress.

De meeste berichtgeving tot nu toe ging over wat RTC betekent voor redacties. Dat is een verhaal over workflow. Dit is een verhaal over infrastructuur. Want vanuit hostingperspectief introduceert RTC een belastingpatroon dat WordPress nog nooit heeft gegenereerd: continue, write-heavy polling vanuit de admin op secondeniveau, gericht op de database, langs elke cachelaag die WordPress snel maakt.

TL;DR

• WordPress 7.0 RTC pollt de server elke 1 seconde tijdens gezamenlijk bewerken (ter vergelijking: de Heartbeat API doet dat elke 15 seconden). De standaardlimiet is 2 gelijktijdige editors per post, instelbaar via wp-config.php
• De oorspronkelijke opslag in postmeta maakte de persistent post cache onklaar bij elke schrijfactie. Een nieuwe wp_collaboration-databasetabel moet dat verhelpen, maar het belastingpatroon zelf is fundamenteel nieuw
• HTTP-polling is het standaardtransport en werkt op elke host. WebSocket-transports zijn beschikbaar via het sync.providers-filter en draaien al in productie bij WordPress VIP
• Shared hostingomgevingen krijgen te maken met een ander resourceprofiel: continue uncacheable requests vanuit de editor op een frequentie die geen enkele eerdere WordPress-feature produceerde
• De release wordt eind mei 2026 verwacht. Het herziene schema wordt uiterlijk 22 april bekendgemaakt

Inhoudsopgave

• Het belastingpatroon dat er nog niet was
• Waarom postmeta brak en wat het vervangt
• HTTP-polling: de rekensom voor shared hosting
• WebSocket-transports als onderscheidend vermogen
• Wat je nu al kunt voorbereiden
• Wanneer dit geen probleem is
• De kern

Het belastingpatroon dat er nog niet was

Tot nu toe was het zwaarste periodieke verzoek dat WordPress vanuit de admin genereerde de Heartbeat API. Heartbeat stuurt elke 15 seconden een POST naar admin-ajax.php op bewerkingsschermen, voor autosave, postvergrendeling en real-time notificaties. Elke puls vereist een volledige PHP-bootstrap: core, actieve plugins, thema. Op shared hosting met 10 gelijktijdige editors is dat 40 uncacheable requests per minuut. Genoeg om problemen te veroorzaken op kleine plannen, en precies de reden dat het throttlen van Heartbeat al jaren standaardadvies is.

RTC is een andere categorie. Wanneer twee mensen dezelfde post bewerken, pollt het standaard HTTP-transport elke 1 seconde. Bij solo-bewerking elke 4 seconden. Dit zijn REST API-calls die Yjs-documentupdates en awareness-data (cursors, aanwezigheid) meesturen, en net als Heartbeat zijn ze niet te cachen. Maar anders dan Heartbeat draaien ze met 15x de frequentie tijdens gezamenlijke sessies.

Dat is relevant omdat WordPress-hosting gebouwd is rond een read-heavy profiel. Bezoekers laden de website, Nginx of Varnish serveert een gecachete pagina, PHP wordt niet wakker. De editor was altijd al de uitzondering, de plek waar cache misses plaatsvinden, maar in bescheiden mate. RTC verandert "bescheiden" in "continu."

Waarom postmeta brak en wat het vervangt

De oorspronkelijke RTC-implementatie sloeg syncdata op (cursors, incrementele contentwijzigingen, aanwezigheidsinformatie) in de WordPress postmeta-tabel. Functioneel werkte dat prima. Architectureel was het een probleem.

WordPress vuurde cache-invalidating hooks af bij elke wijziging in postmeta. Met RTC die meerdere keren per seconde naar postmeta schreef tijdens actief bewerken, werd de persistent object cache (Redis, Memcached) van elke post met actieve collaborators continu ongeldig gemaakt. Niet alleen de cache voor die specifieke postmeta. De site-brede post query caches. Voor een CMS dat leunt op object caching voor snelheid, is dat niet iets wat je kunt uitrollen naar 43% van het web.

Core-committer Peter Wilson, gesponsord door Fueled, identificeerde het probleem als eerste en stelde een aparte wp_collaboration-tabel voor op Trac #64696. WordPress VIP-engineer Chris Zarate werkt aan de schemadetails. De onderbouwing, zoals Wilson het formuleerde in het ticket: collaboratiedata heeft veel churn, met frequente writes en deletes. Dat patroon matcht fundamenteel niet met de verwachtingen van de post/postmeta-tabellen. Een aparte tabel die gebouwd is voor dat patroon voorkomt dat de cache-invalidating hooks afgaan.

Matt Mullenweg, geciteerd in de ticketdiscussie, erkende de noodzaak:

"I'm generally against new tables, but this is a useful primitive for all our future real-time collab and sync work."

WordPress heeft op dit moment 12 databasetabellen in de core. De laatste keer dat er een bijkwam was WordPress 4.4 in december 2015, toen wp_termmeta werd geïntroduceerd. De lat ligt hoog, en het team heeft de volledige releasecyclus gepauzeerd om dit goed te doen in plaats van het er last-minute aan te plakken. Ik schreef er eerder over in mijn analyse van het WordPress 7.0-uitstel.

HTTP-polling: de rekensom voor shared hosting

Het standaard HTTP-polling transport was een bewuste keuze. Het werkt op elke hostingomgeving zonder infrastructuurwijzigingen. Geen WebSocket-support nodig, geen Node.js-sidecar, geen persistente verbindingen. Voor de breedte van WordPress's installatiebasis is dat de juiste call.

Maar de rekensom is het maken waard. Neem een shared hostingserver met 200 WordPress-installaties, waarvan er 20 redactieteams hebben die actief in de editor werken. Ga uit van gemiddeld 2 collaborators per post (de standaardlimiet).

Dat zijn 20 actieve sessies die elk per seconde pollen. Twintig REST API-requests per seconde, elk met een PHP-process, een database-roundtrip naar de wp_collaboration-tabel en een response. Tel daar de reguliere Heartbeat-requests bij op (die stoppen niet), plus eventueel WooCommerce AJAX, en je kijkt naar een sustained uncacheable load die kwalitatief anders is dan waarvoor shared hosts zijn ingericht.

Het PHP worker-model maakt dit concreet. Elk pollingverzoek bezet een PHP-FPM worker voor de duur van de request. Als een shared plan 2 workers per site toekent, en beide draaien vol met RTC-polling, dan komen front-end bezoekers in de wachtrij. De site crasht niet. Hij wordt traag. En de supporttickets beginnen: "Mijn editor reageert langzaam."

Even voor de duidelijkheid: dit is geen ontwerpfout. WordPress.com testte agressievere pollingintervallen (tot 250ms) en vond de belasting behapbaar op hun infrastructuur. Het punt is dat WordPress.com-infrastructuur niet hetzelfde is als een shared hostingpanel met CloudLinux LVE-limieten en 2 PHP workers per tenant.

WebSocket-transports als onderscheidend vermogen

Hier zit de kans voor managed WordPress-hosts.

Het sync.providers-filter is een client-side hook waarmee hosts het standaard HTTP-pollingtransport volledig kunnen vervangen. Een custom provider krijgt het Yjs-document en awareness-objecten en handelt sync af via welk transport de host ook aanbiedt. De architectuur is helder: implementeer drie functies (lokale updates versturen, remote updates ontvangen, verbindingsstatus rapporteren) en lever een destroy-methode voor cleanup.

WordPress VIP heeft al een WebSocket-based provider in productie met y-websocket, de meest gebruikte Yjs-transportbibliotheek. Die bevat een aparte Node.js-server die sync afhandelt tussen verbonden clients. Meerdere VIP-klanten draaien het in productie sinds oktober 2025.

Het voordeel van WebSocket boven HTTP-polling is structureel, niet marginaal. Een persistente verbinding elimineert de per-seconde request overhead volledig. Er wordt geen PHP worker bezet voor synctrafiek. Geen REST API-roundtrips. Updates komen direct aan. Voor redactieteams van 3 of meer collaborators is het verschil in responsiviteit meteen merkbaar.

De trade-off: WebSocket-support vereist een persistent process (Node.js, Go, of iets vergelijkbaars) naast PHP-FPM. Op een Kubernetes-based hostingstack is dat triviaal. Op een cPanel-server niet. De hostingprovider moet het deployen, beveiligen (token-based auth, per-document autorisatie) en onderhouden.

Voor managed hosts die al custom infrastructuur draaien is dit een logische uitbreiding van het product. Voor budgetproviders op shared hosting staat het niet op de roadmap. Die kloof is precies het onderscheidend vermogen.

Wat je nu al kunt voorbereiden

Als je WordPress-hostinginfrastructuur beheert, zijn er concrete dingen die je kunt doen voor de release van eind mei:

1. Benchmark je PHP worker pool onder RTC-load. Installeer de WordPress Beta Tester-plugin op een staging-omgeving en open collaboratieve bewerkingssessies terwijl je PHP-FPM worker-gebruik monitort. De vraag is niet of je server een sessie aankan. Het is of 20 gelijktijdige sessies op 20 verschillende sites het workerplafond raken.

2. Test je object cache onder RTC-writes. Als je Redis of Memcached gebruikt, controleer dan of de nieuwe wp_collaboration-tabel (zodra het schema definitief is) syncwrites goed isoleert van de postcache. Het hele doel van de nieuwe tabel is om cache-invalidation storms te stoppen, maar je cachingconfiguratie heeft misschien custom invalidatieregels.

3. Bepaal je WebSocket-strategie. Drie opties: (a) ship het voor de 7.0-launch en communiceer het, (b) zet het op de roadmap als post-launch feature, of (c) sla het over en vertrouw op HTTP-polling. Optie A is wat VIP deed. Optie C is prima voor de meeste shared hosting. Maar beslis voordat de release-aankondiging de klantvragen triggert.

4. Bekijk je PHP-FPM pool sizing voor shared tenants. Als je plannen 2 PHP workers per site toekennen, kan dat krap worden voor sites met actieve redactieteams. Overweeg of RTC-intensieve plannen 4 workers nodig hebben, of dat je RTC-pollingfrequentie server-side throttlet voor lagere tiers.

5. Documenteer je RTC-ondersteuningsniveau. Klanten gaan vragen stellen. "Werkt real-time samenwerking op jullie hosting?" Het antwoord is altijd ja (HTTP-polling werkt overal), maar het performanceverhaal verschilt per plan. Schrijf het op voor ze het vragen.

Wanneer dit geen probleem is

Niet elke WordPress-site gaat dit merken. RTC heeft een standaardlimiet van twee collaborators. Sites waar een persoon content bewerkt (en dat is de overgrote meerderheid van WordPress-installaties) zien nauwelijks iets. Het pollinginterval zakt naar 4 seconden bij een enkele gebruiker, en er worden geen collaboratie-syncdata gegenereerd.

Posts met classic meta boxes schakelen RTC automatisch uit. Dat geldt voor veel ACF-heavy bewerkingsschermen, custom admin-workflows en oudere plugins die meta boxes op de legacy-manier registreren. Als de editors van je klanten gebouwd zijn op custom fields, komen ze RTC misschien helemaal niet tegen.

De sites die dit wel gaan merken zijn nieuwsredacties, bureaus en contentteams met meerdere editors die tegelijk werken. Uitgeversactiviteiten die Google Docs als workaround gebruikten en nu hun redactieproces naar WordPress verplaatsen. Voor hen wordt de hostinginfrastructuur eronder het knelpunt of de enabler.

De kern

• Real-time samenwerking in WordPress 7.0 introduceert sustained per-seconde polling vanuit de admin. Dat is een belastingpatroon dat geen enkele eerdere WordPress-feature produceerde
• De oorspronkelijke postmeta-opslag brak persistent post caches. Een aparte wp_collaboration-tabel wordt ontworpen om syncwrites te isoleren, en de release is uitgesteld om dit goed te doen
• HTTP-polling werkt op elke host. WebSocket-transports via het sync.providers-filter zijn een concreet onderscheidend vermogen voor managed hosts, met WordPress VIP die er al een in productie draait
• Shared hosts moeten PHP worker pools benchmarken onder gelijktijdige RTC-sessies. Twee workers per site is mogelijk onvoldoende voor sites met actieve redactieteams
• Sites met een enkele editor (de meerderheid van WordPress-installaties) merken minimaal verschil. De infrastructuurzorg concentreert zich op multi-user publishing omgevingen