WordPress 7.0 is just around the corner, but the latest news from the performance team is a bit of a wake-up call for those of us tracking WordPress Core Performance. Specifically, there has been a noticeable 10% regression in Time to First Byte (TTFB) compared to version 6.9. While the LCP (Largest Contentful Paint) seems stable, the extra overhead is coming from the PHP processing side, and the core team is currently hunting for the specific bottleneck.
If you have been following my recent updates on testing the Presence API, you know that 7.0 is packing heavy features. However, adding features without a performance tax is a recurring struggle in the core ecosystem. Therefore, it is critical to look at where the cycles are being spent before we ship this to production.
Decoding the 10% TTFB Regression
The 10% hit in TTFB benchmarking was flagged recently by the core contributors. Since TTFB-LCP doesn’t show the same regression, the problem is localized to the server-side execution. In my experience, this usually points to one of three things: a bloated bootstrap phase, inefficient metadata handling, or a race condition in a new hook. For those managing high-traffic WooCommerce sites, a 10% increase in TTFB can be the difference between a sale and a bounce.
Furthermore, ticket #65165 highlights an interesting evolution: script modules depending on classic scripts. While dynamic imports help WordPress Core Performance by being non-blocking, the dependency logic itself needs to be lean. If the dependency resolution adds too many database queries or complex PHP logic during the head render, we lose the speed we gained by going non-blocking.
The Preload Header “Gotcha” and Nginx 502s
One technical nuance discussed in the chat involved the placement of <link rel="preload"> tags. Appending these late in the <head> can be useless if the server has already sent the initial HTML chunk. To combat this, many developers (and the core team) use HTTP Link headers. Specifically, this pushes the preload instructions to the browser before the HTML even starts downloading.
However, there is a major “gotcha” here. If you get too aggressive with preloading every asset, your Link header can exceed the Nginx proxy_buffer_size or fastcgi_buffer_size. Consequently, Nginx will throw a 502 Bad Gateway error because it can’t handle the massive header. I’ve seen this happen on client sites where a performance plugin tried to preload 50+ images at once.
// Concept: Check header size before sending Link preloads
function bbioon_safe_preload_header( $header_content ) {
$max_header_size = 4096; // 4KB is a common safe limit
if ( strlen( $header_content ) < $max_header_size ) {
header( "Link: " . $header_content );
} else {
error_log( "WordPress Core Performance: Preload header too large, skipping push." );
}
}Real-Time Scalability Concerns
Another area under review is ticket #64696, focusing on HTTP polling for real-time collaboration. Constant polling can absolutely wreck persistent post caches if not handled correctly. This is similar to the issues we saw when RC1 was delayed for performance reasons. Specifically, we need to ensure that background polling doesn’t trigger expensive object cache invalidations on every heartbeat.
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.
Core Performance Takeaway
We are in the “freeze” period for WordPress 7.0, which means no new features—only fixes for these regressions. If your site relies on rapid TTFB, you should start benchmarking your specific tech stack against the 7.0 RC builds now. Don’t wait for the general release to find out that your Nginx config is choking on new core headers or that your PHP processing time has jumped by 10%.
