If you’ve been tracking the latest WordPress Core Performance discussions, you know we’re reaching a critical turning point for the platform. WordPress 7.0 is promising real-time collaboration—think Google Docs style editing—but as a senior developer, I can tell you that the “how” matters much more than the “what.” Right now, the technical implementation is causing some serious headaches for anyone relying on persistent object caching.
WordPress Core Performance: The Caching Conflict
The biggest red flag from the February 24th performance chat is Ticket #64696. Specifically, the current real-time collaboration prototype uses HTTP polling to track “awareness states” (who is editing what). These updates can happen up to four times per second. Because these states were being stored as post meta, every single poll triggered an update to the last_changed value in the cache.
Consequently, if you have a persistent object cache (like Redis or Memcached) enabled, the cache for that post—and potentially all its meta—is being invalidated several times a second. For high-traffic editorial sites, this is essentially a performance suicide note. It’s a classic example of a “shiny new feature” colliding with the boring, essential infrastructure of a stable site. Furthermore, I’ve seen sites crawl to a halt because of 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.
}
The Database Solution
The good news is that the core team isn’t ignoring this. Matt Mullenweg recently approved the creation of a purpose-built database table for sync storage. This is a rare move—WordPress hasn’t added a new core table since 2015—but it’s necessary. By moving the awareness data out of the meta table, we can keep WordPress Core Performance high without sacrificing the new collaboration features.
If you want to dig deeper into how these core shifts affect your site speed, check out my previous take on WordPress Core Performance: Real Talk on Scripts and AI.
Security and Release Updates
Beyond the architectural debates, there are some immediate updates you need to ship. A security issue was responsibly disclosed and patched for the Embed Optimizer plugin (part of the Performance Lab suite). If you’re running any Performance Lab modules, you should be checking for updates immediately. We’re also looking at a general release of several performance plugins this coming Thursday.
We’re also seeing progress on Ticket #64087 and #64620, which turned out to be duplicates. A unified patch is in the works, and testers are needed to ensure the refactor doesn’t introduce regressions in how we handle global script loading. You can read more about similar scaling issues in my analysis of WooCommerce 10.6 performance updates.
Look, if this WordPress Core 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 takeaway here is simple: never assume a core update is “performance neutral.” The move toward real-time collaboration is the biggest architectural shift we’ve seen in years. If you are running an enterprise-level site, you need to monitor your object cache hit rates closely as these features roll out in the 7.0 beta cycle. Specifically, watch for “last_changed” spikes in your Redis monitors.
