WordPress 7.0 changes how the block editor handles concurrent data. Read the docs and Phase 3 looks like a clean upgrade, but the sync provider architecture is where hosting gets interesting: real-time collaboration leans hard on the database and the object cache.
The Core team is asking web hosts to run tests, and it wants the data by end of day on May 4th so the RTC architecture can be locked down. Core features usually get tested in clean, isolated setups. This time the ask is for numbers from shared hosting, VPS boxes and managed platforms before the ship date.
Where WordPress 7.0 RTC gets hard for hosts
Real-time collaboration uses Yjs, which implements conflict-free replicated data types (CRDTs). That settles the question of who edited what, but it costs you server load, because every keystroke turns into a sync event. On high-latency setups, or anywhere with aggressive database locking, that is where race conditions show up.
I wrote about navigating the RTC delay earlier, and performance was the bottleneck then too. If you host busy WooCommerce sites, a badly configured RTC setup can eat your whole PHP worker pool. So test against your real traffic, not a clean install.
Setting up the distributed test suite
The test suite needs only bash, cURL, WP-CLI and patch. Set the ENVIRONMENT_NAME variable so your results get grouped correctly, and leave PHP versions out of that name, since the script tracks those separately. A plain label such as “Shared Performance” or “Managed eCommerce” is enough.
# Example of setting up the environment variables for testing
export ENVIRONMENT_NAME="High-Performance-VPS"
export WP_TEST_BOT_USER="your-bot-account"
export WP_TEST_BOT_PASSWORD="your-application-password"
# Run the performance suite from your terminal
bash ./rtc-test-runner.shIf you have run the PHPUnit host tests before, the same bot accounts work here. Skip the testing and you find out about the incompatibility later, from a queue of tickets about “sync errors” after the release candidate reaches everyone.
What the performance numbers show
The easy assumption is that a normal object cache absorbs the sync load. The data points elsewhere: RTC performance issues mostly trace back to the volume of transient writes. A MariaDB or MySQL config that is not tuned for lots of small, fast writes shows up as a TTFB spike.
The official dev note covers how the Presence API fits into this. Cloning the performance testing repository is worth the time if you want to see how the metrics get aggregated.
If WordPress 7.0 RTC is eating your dev hours, I can take it off your plate. I have been wrestling with WordPress since the 4.x days.
Test before May 4th
May 4th is firm because the Phase 3 architecture gets decided off this data. Core cannot tune for the whole install base without telemetry that looks like the install base, which means your older infrastructure matters more here than your flagship tier. That is where most sites actually run. If your testing bot hits a snag, the #hosting channel on the WordPress Slack is the place to ask.
