WordPress 7.0 is close, and the performance team’s latest numbers are not comfortable reading if you track WordPress Core Performance. Time to First Byte is running about 10% worse than 6.9. LCP looks steady, which puts the extra cost on the PHP side, and the core team is still working out where exactly it goes.
As I noted while testing the Presence API, 7.0 carries a lot of new machinery. Shipping features without paying for them in cycles has never been easy in core, so it is worth knowing where those cycles go before this reaches production.
Where the 10% goes
Core contributors flagged the 10% TTFB hit in benchmarking. TTFB-LCP does not show the same regression, so the problem sits in server-side execution. My first suspects in that situation are a bloated bootstrap phase or inefficient metadata handling, occasionally a race condition in a new hook. On a busy WooCommerce site, 10% more TTFB shows up in the bounce rate.
Ticket #65165 covers script modules that depend on classic scripts. Dynamic imports help WordPress Core Performance because they do not block, but the dependency logic has to stay cheap. Resolve those dependencies with extra database queries or heavy PHP during the head render and you hand back whatever the non-blocking load saved you.
Preload headers and Nginx 502s
Part of the chat covered where <link rel="preload"> tags actually land. Appending them late in the <head> does nothing once the server has already flushed the first chunk of HTML. HTTP Link headers are the workaround the core team and plenty of developers use, since they reach the browser before the HTML starts downloading.
The catch shows up when you preload too much. A long Link header can run past the Nginx proxy_buffer_size or fastcgi_buffer_size, and Nginx answers with a 502 Bad Gateway instead of a page. I have seen it on client sites where a performance plugin decided to preload 50 or more 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." );
}
}Polling and real-time collaboration
Ticket #64696 looks at HTTP polling for real-time collaboration. Left unchecked, constant polling will tear through a persistent post cache. It is the same family of problem as when RC1 was delayed for performance reasons. Background polling must not trigger an expensive object cache invalidation on every heartbeat.
If WordPress core performance work is eating your dev hours, hand it over. I have been working with WordPress since the 4.x days.
What to do before 7.0 lands
7.0 is in the freeze period, so nothing new goes in and the remaining work is fixes for regressions like this one. If TTFB matters to your site, benchmark your own stack against the 7.0 RC builds now. Finding out at general release that your Nginx config chokes on the new core headers, or that PHP processing time jumped 10%, is a worse day.
