WordPress 7.0 is promising real-time collaboration, the Google Docs style of editing where two people work in the same post at once. The feature itself is fine. How the prototype stores its state is not, at least not if you run a persistent object cache. That was the sore point in the latest WordPress Core Performance discussion.
WordPress core performance: the caching conflict
The one to read from the February 24th performance chat is Ticket #64696. The collaboration prototype uses HTTP polling to track awareness states, meaning who is editing what, and those updates can fire up to four times per second. Those states were being stored as post meta, so every poll bumped the last_changed value in the cache.
So with a persistent object cache in front of the database, Redis or Memcached, the cache for that post and possibly all of its meta gets thrown out several times a second. On a busy editorial site that is not a small tax. I have watched sites crawl under much lighter meta polling than this.
<?php
/**
* Illustrating why the current awareness state storage is problematic
* for WordPress Core Performance.
*/
function bbioon_visualize_cache_invalidation( $post_id ) {
// In the current RTC implementation, this runs 1-4x per second
update_post_meta( $post_id, '_wp_sync_awareness', time() );
// THE GOTCHA:
// update_post_meta() calls wp_cache_set_posts_last_changed()
// This invalidates the entire meta cache group for this post ID.
// Result: Your persistent object cache becomes a bottleneck, not a helper.
}
A new core table instead
Matt Mullenweg has approved a purpose-built database table for sync storage. That is rare. WordPress has not added a new core table since 2015, and nobody adds one lightly. Moving the awareness data out of the meta table keeps the cache out of the blast radius, so WordPress Core Performance and the collaboration work can both move forward.
I wrote about the script loading and AI side of these core shifts earlier, in WordPress Core Performance: Real Talk on Scripts and AI.
Security and release updates
Two things to actually do this week. A security issue in the Embed Optimizer plugin, part of the Performance Lab suite, was disclosed responsibly and patched, so update it if you have any Performance Lab modules running. A general release of several performance plugins is also planned for Thursday.
Tickets #64087 and #64620 turned out to be duplicates, and they are being folded into a single patch. It touches global script loading, so it needs testers before anyone can trust it not to regress. I covered similar scaling problems in my write-up of WooCommerce 10.6 performance updates.
If this kind of WordPress core performance triage is eating your dev hours, I take that work on. I have been wrestling with WordPress since the 4.x days.
What to watch
Do not assume a core release is performance neutral just because nobody said otherwise. Real-time collaboration is the largest architectural change WordPress has taken on in years, and the 7.0 beta cycle is when it lands on your servers. Watch your object cache hit rate, and watch for “last_changed” spikes in your Redis monitoring.
