WordPress 7.0 RC1 moved from March 19 to March 24 after problems with real-time collaboration performance, client-side media optimization, and release package size. The collaboration issue shows why a visible feature can force a deep storage decision late in a release.
Real-time collaboration uses CRDTs and HTTP polling. Synchronization data was stored in post_meta, so every update invalidated WordPress post-query caches. One editor generated a poll each second; two editors produced four. On a busy site, enabling collaboration could effectively undermine persistent post caching.
The proposed direction was to move RTC data into a dedicated table, isolating volatile synchronization writes from content queries. That is a significant architectural change between beta and release candidate. The project instead disabled collaboration by default for RC1, including installations that had enabled it during beta, and deferred the default decision.
What polling does to the post cache
Peter Wilson documented on Trac that, with RTC on and the editor open, WordPress behaves as if persistent post-query caches were off. Presence (wp_sync_awareness) and updates (wp_sync_update) live in post_meta. Any write there fires broad invalidation, including queries that have no relation to the open post.
One editor: one poll per second. Two: four per second. On a fresh install, Wilson measured 60 requests a minute and 110 to 120 KB just from opening Hello World. With two collaborators, on the order of 480 requests a minute and about 900 KB. Heartbeat, which core already uses for locking, fires at most every 10 seconds and slows down when the tab is in the background. RTC, in the form he found, kept going every second with the tab open and nobody typing.
In the hosting team meeting, GoDaddy described uncacheable requests every 250 ms per editor. WP Engine pointed to resource contention and race risk. On a site with an object cache, the feature on becomes an invalidation generator while someone leaves Gutenberg open.
When to turn collaboration on for a site that already has traffic
In RC1 the feature ships off. Opt-in under Settings, Writing. Anyone who enabled it in beta finds it off after the update. On a site with a persistent object cache and page cache in front, that default is the only one that makes sense until the new table exists in the package you will actually run.
Turn RTC on where coediting is routine: a newsroom, an agency, a team on the same post. A single-author site, a store, marketing with one editor at a time pays for the poll and gains little. There is a narrow case, raised on Trac, of someone who opens the same post in several tabs or devices. Even there, measure before it becomes policy.
With the feature on and the editor open, compare invalidation rate, object-cache hit ratio, requests per minute on the sync endpoint, database CPU and I/O, and the same front URL with the editor closed. If the public post listing melts because someone went to lunch with Gutenberg open, the operational cost has already shown up.
The dedicated table and what RC1 still leaves open
The technical direction is a table only for sync, discussed as wp_collaboration. Matt Mullenweg, generally opposed to new core tables, accepted this one as a primitive for future collaboration and sync. The last addition in that spirit was wp_termmeta, in 4.4, in December 2015.
Moving sync out of post_meta avoids the invalidation hooks, reduces the race of two editors writing in the same millisecond, and makes compacting old data an atomic operation. Between beta and RC, that is a heavy change. That is why the default waited for RC2.
Multisite still has an edge: a subsite administrator can turn RTC on without being able to run a database upgrade. There is also a separate-ticket idea of marking some post_meta keys as non-queryable so they do not invalidate cache. Wilson preferred not to mix that into the current fix. Do not enable it on a network until the schema path is clear in the release notes you will apply.
9 April at WordCamp Asia is a ship calendar. Default on or off is an architecture decision. The two can diverge.
Test with an idle editor and the cache on
Make WordPress Test asked for exercise with real content, more than one collaborator, custom blocks, and plugins. HTTP polling has lag. The feature channel and the GitHub tracking issue exist for what stalls and what flows.
For a site that already serves traffic, the useful test starts thin: one editor, then two, object cache on, a page-cache plugin in front, Heartbeat at current behavior. Leave the editor open ten minutes without typing. If polling does not cool down in the candidate package, turn the feature on only with a scheduled window and a rollback.
A client-side change already reduces polling when the tab is inactive, and the rate should become filterable for hosts. Neither replaces leaving post_meta. Until the table exists in the zip you will update, treat real-time collaboration as opt-in, even if Gutenberg phase 3 remains the 7.0 headline.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
