WordPress 7.0 is dropping soon, but one major feature is conspicuously absent from the final roadmap. I’m talking about the decision to remove real-time collaboration from WordPress 7.0. As a developer who has spent over a decade wrestling with database bottlenecks, I can tell you: this was the right call. The latest WordPress Real Time Collaboration performance testing data proves that the initial implementation simply wasn’t ready for the variety of hosting environments we deal with daily.
We’ve all seen what happens when a “cool” feature hits a shared hosting environment with a bloated wp_options table. It’s a disaster. Consequently, the core team ran exhaustive tests across eight different hosting environments to find a storage strategy that actually scales. They didn’t just guess; they looked at the raw dispatch times and query counts during sustained 30-second polling windows.
The Four Candidates for RTC Storage
The team tested four distinct approaches to handle the high-frequency data required for real-time awareness (knowing who is editing what). These included:
- post-meta: The baseline approach, which proved to be the slowest.
- custom-table: A dedicated table for RTC data.
- post-meta-transients: Using transients for awareness, but keeping storage in post meta.
- custom-table-with-transients: The eventual winner, combining a lean schema with object cache-backed awareness.
I previously touched on the friction between real-time editing and object caching, and these results confirm those suspicions. Specifically, the custom-table-with-transients approach was approximately 52% faster than the post-meta baseline. Furthermore, it tied for first place in nearly every tested environment.
Why Custom Tables and Transients Won
The magic happens when you separate high-frequency “awareness” data (who is in the editor right now) from persistent storage. When a persistent object cache like Redis is present, both transient-based strategies dropped to a single database query per dispatch. This is a massive win for WordPress Real Time Collaboration performance because it removes the I/O bottleneck entirely for the most frequent requests.
However, even without Redis, the custom table approach cut the query count in half compared to post-meta. This is because the core wp_postmeta table is notoriously inefficient for frequent updates due to its generic key-value structure and lack of specific indexing for RTC-style polling. For a deep dive into the technical benchmarks, you can check the anonymized analysis gist provided by the core contributors.
<?php
/**
* A simplified look at how custom-table-with-transients handles awareness.
* This is a conceptual example of why caching the "awareness" layer
* reduces database load.
*/
function bbioon_check_editor_awareness( $post_id ) {
$cache_key = 'rtc_awareness_' . $post_id;
// Attempt to get the awareness data from the transient (Object Cache)
$active_users = get_transient( $cache_key );
if ( false === $active_users ) {
// Fallback to the custom table only if the cache is empty
global $wpdb;
$table_name = $wpdb->prefix . 'rtc_awareness';
$active_users = $wpdb->get_results(
$wpdb->prepare( "SELECT user_id FROM $table_name WHERE post_id = %d", $post_id )
);
// Store in transient for high-frequency polling
set_transient( $cache_key, $active_users, 30 );
}
return $active_users;
}
The Fall of Post-Meta Transients
One surprising “war story” from the data was the total failure of the post-meta-transients approach on shared hosts without a persistent cache. On one environment, the latency spiked past 26 ms—several times worse than anything else. This happens because the WordPress Transients API falls back to the wp_options table when no object cache is present. If your options table is already struggling, adding high-frequency RTC polling is like pouring gasoline on a fire.
Because of these results, the recommendation is clear: custom-table-with-transients is the only path forward. It degrades gracefully on low-end hosts and screams on managed cloud environments with Redis. We already saw WordPress 7.0 release candidate delays due to performance concerns, and this pivot justifies that caution.
Look, if this WordPress Real Time Collaboration performance stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Technical Takeaway
The removal of RTC from 7.0 isn’t a failure; it’s a sign of maturity in the core development process. We are finally prioritizing architecture over features. By moving to a custom table strategy, WordPress is setting itself up for a future where real-time collaboration doesn’t just work—it scales. If you are building high-traffic features, take a page from this playbook: use custom tables for your schema and persistent transients for your awareness layer.
