WordPress 7.0's real-time collaboration: what managed hosts need to prepare

The headline feature of WordPress 7.0 is not the AI Connectors page. It is real-time collaboration: multiple users editing the same post simultaneously, with live cursors, presence indicators, and automatic conflict resolution powered by Yjs, a conflict-free replicated data type (CRDT) framework. Google Docs behavior inside WordPress.

Most of the coverage so far has focused on what RTC means for editorial teams. That is a story about workflow. This is a story about infrastructure. Because from a hosting perspective, RTC introduces a load pattern that WordPress has never generated before: sustained, write-heavy, per-second polling traffic from the admin, aimed at the database, bypassing every cache layer that makes WordPress performant in the first place.

TL;DR

• WordPress 7.0's RTC polls the server every 1 second during collaborative editing (compared to the Heartbeat API's 15 seconds). The default limit is 2 concurrent editors per post, configurable via wp-config.php
• The original postmeta-based storage invalidated persistent post caches on every write. A new wp_collaboration database table is being designed to fix this, but the load pattern itself is fundamentally new
• HTTP polling is the default transport and works on any host. WebSocket-based transports are available via the sync.providers filter and are already running in production at WordPress VIP
• Shared hosting environments face a different resource profile: sustained uncacheable requests from the editor at a frequency no previous WordPress feature has produced
• The release is expected late May 2026. The revised schedule will be announced by April 22

Table of contents

• The load pattern that didn't exist before
• Why postmeta broke and what replaces it
• HTTP polling: the math for shared hosting
• WebSocket transports as a managed-host differentiator
• What to prepare before RTC ships
• When this is not a problem
• Key takeaways

The load pattern that didn't exist before

Until now, the most demanding periodic request WordPress generated from the admin was the Heartbeat API. Heartbeat fires a POST to admin-ajax.php every 15 seconds on post edit screens, handling autosave, post locking, and real-time notifications. Each pulse requires a full PHP bootstrap: core, active plugins, theme. On shared hosting with 10 concurrent editors, that is 40 uncacheable requests per minute. Enough to cause trouble on small plans, which is why throttling Heartbeat has been standard advice for years.

RTC is a different category. When two people edit the same post, the default HTTP polling transport fires every 1 second. When editing alone, every 4 seconds. These are REST API calls that carry Yjs document updates and awareness data (cursors, presence), and like Heartbeat, they cannot be cached. Unlike Heartbeat, they run at 15x the frequency during collaborative sessions.

That matters because WordPress hosting has been designed around a read-heavy profile. Visitors hit the front end, Nginx or Varnish serves a cached page, and PHP never wakes up. The editor has always been the exception, the place where cache misses happen, but at modest rates. RTC changes "modest" to "sustained."

Why postmeta broke and what replaces it

The original RTC implementation stored sync data (cursors, incremental content changes, presence info) in WordPress's postmeta table. Functionally, that worked. Architecturally, it was a problem.

WordPress fires cache-invalidating hooks whenever postmeta changes. With RTC writing to postmeta multiple times per second during active editing, every post with active collaborators had its persistent object cache (Redis, Memcached) invalidated continuously. Not just the cache for that post's meta. The site-wide post query caches. For a CMS that leans on object caching for speed, that is not something you can ship to 43% of the web.

Long-time core committer Peter Wilson, sponsored by Fueled, first identified the issue and proposed a dedicated wp_collaboration table on Trac #64696. WordPress VIP engineer Chris Zarate has been working through the schema details. The rationale, as Wilson put it in the ticket: collaboration state has high churn with frequent writes and deletes, a pattern that fundamentally mismatches the expectations of the post/postmeta tables. A separate table purpose-built for that churn means none of the cache-invalidating hooks fire.

Matt Mullenweg, quoted in the ticket discussion, acknowledged the need:

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

WordPress currently has 12 core database tables. The last time a new one was added was WordPress 4.4 in December 2015, when wp_termmeta was introduced. The bar is high, and the team paused the entire release cycle to get this right rather than bolt it on. I covered the delay in detail in my WordPress 7.0 delay analysis.

HTTP polling: the math for shared hosting

The default HTTP polling transport was a deliberate design choice. It works on any hosting environment without infrastructure changes. No WebSocket support needed, no Node.js sidecar, no persistent connections. That is the right call for WordPress's install base.

But the math is worth running. Consider a shared hosting server with 200 WordPress installations, of which 20 have editorial teams actively using the editor at any given time. Assume an average of 2 collaborators per post (the default limit).

That is 20 active sessions, each polling once per second. Twenty REST API requests per second, each requiring a PHP process, a database round-trip to the wp_collaboration table, and a response. Add the regular Heartbeat requests running alongside (those do not stop), plus any WooCommerce AJAX, and you are looking at a sustained uncacheable load that is qualitatively different from what shared hosts have provisioned for.

The PHP worker model makes this concrete. Each polling request occupies a PHP-FPM worker for the duration of the request. If a shared plan allocates 2 workers per site, and both are tied up serving RTC polling, front-end visitors hit the queue. The site does not crash. It gets slow. And the support tickets start arriving: "My editor is laggy."

To be clear: this is not a flaw in the design. WordPress.com tested aggressive polling intervals (down to 250ms) and found the load manageable on their infrastructure. The point is that WordPress.com infrastructure is not a shared hosting panel with CloudLinux LVE limits and 2 PHP workers per tenant.

WebSocket transports as a managed-host differentiator

This is where the opportunity sits for managed WordPress hosts.

The sync.providers filter is a client-side hook that lets hosts replace the default HTTP polling transport entirely. A custom provider receives the Yjs document and awareness objects and handles sync through whatever transport the host offers. The architecture is clean: implement three functions (send local updates, receive remote updates, report connection status) and return a destroy method for cleanup.

WordPress VIP has already shipped a WebSocket-based provider using y-websocket, the most widely deployed Yjs transport library. It includes a separate Node.js server that handles sync between connected clients. Several VIP customers have been running it in production since October 2025.

The advantage of WebSocket over HTTP polling is structural, not marginal. A persistent connection eliminates the per-second request overhead entirely. No PHP worker is occupied for sync traffic. No REST API round-trips. Updates travel instantly. For editorial teams of 3 or more collaborators, the difference in responsiveness is immediately noticeable.

The trade-off: WebSocket support requires a persistent process (Node.js, Go, or similar) running alongside PHP-FPM. That is trivial on a Kubernetes-based hosting stack. It is not trivial on a cPanel server. The hosting provider has to deploy it, secure it (token-based auth, per-document authorization), and maintain it.

For managed hosts that already run custom infrastructure, this is a natural extension of the product. For budget shared hosts, it is not on the roadmap. That gap is the differentiator.

What to prepare before RTC ships

If you run or manage WordPress hosting infrastructure, there are concrete things to do before the late May release:

1. Benchmark your PHP worker pool under RTC load. Install the WordPress Beta Tester plugin on a staging instance and open collaborative editing sessions while monitoring PHP-FPM worker utilization. The question is not whether your server handles one session. It is whether 20 concurrent sessions on 20 different sites hit the worker ceiling.

2. Test your object cache under RTC writes. If you use Redis or Memcached, verify that the new wp_collaboration table (once the schema is finalized) properly isolates sync writes from the post cache. The whole point of the new table is to stop cache invalidation storms, but your caching configuration might have custom invalidation rules.

3. Decide your WebSocket strategy. Three options: (a) ship it before 7.0 launches and market it, (b) add it to the roadmap as a post-launch feature, or (c) skip it and rely on HTTP polling. Option A is what VIP did. Option C is fine for most shared hosting. But you should decide before the release announcement triggers customer questions.

4. Review PHP-FPM pool sizing for shared tenants. If your plans allocate 2 PHP workers per site, that may be tight for sites with active editorial teams. Consider whether RTC-heavy plans need 4 workers, or whether you throttle RTC polling server-side for lower-tier plans.

5. Document your RTC support tier. Customers will ask. "Does your hosting support WordPress real-time collaboration?" The answer is always yes (HTTP polling works everywhere), but the performance story differs by plan. Write it down before they ask.

When this is not a problem

Not every WordPress site will feel this. RTC has a two-collaborator default limit. Sites where one person edits content, which is the overwhelming majority of WordPress installations, see almost no change. The polling interval drops to 4 seconds with a single user, and no collaboration sync data is generated.

Posts with classic meta boxes disable RTC automatically. That includes many ACF-heavy edit screens, custom admin workflows, and older plugins that register meta boxes the legacy way. If your clients' editors are built on custom fields, they may not encounter RTC at all.

The sites that will feel this are newsrooms, agencies, and content teams with multiple editors working simultaneously. Publishing operations that have been using Google Docs as a workaround and will now move editorial workflow into WordPress. For them, the hosting infrastructure underneath becomes the bottleneck or the enabler.

Key takeaways

• WordPress 7.0's real-time collaboration introduces sustained per-second polling to the admin, a load pattern that no previous WordPress feature generated
• The original postmeta storage broke persistent post caches. A dedicated wp_collaboration table is being designed to isolate sync writes, and the release was delayed to get this right
• HTTP polling works on any host. WebSocket transports via the sync.providers filter are a concrete differentiator for managed hosts, with WordPress VIP already running one in production
• Shared hosts should benchmark PHP worker pools under concurrent RTC sessions. Two workers per site may not be enough for sites with active editorial teams
• Single-editor sites (the majority of WordPress installs) see minimal impact. The infrastructure concern is concentrated on multi-user publishing environments