The WordPress core performance team convened on May 5, 2026, to discuss recent findings and ongoing work related to performance ahead of the WordPress 7.0 release. Notably, benchmarking revealed a roughly 10% regression in Time to First Byte (TTFB) compared to version 6.9, raising concerns about backend processing speed despite no clear single cause identified yet. The conversation also covered improvements around script loading, real-time collaboration scalability, and updates to the Performance Lab plugin.
Key Takeaways
- WordPress 7.0 shows a 10% regression in TTFB compared to 6.9, linked to additional PHP processing.
- Trunk remains frozen for general commits, except for 7.0-specific fixes and testing changes.
- New ticket #65165 explores script modules depending on classic scripts to optimize script loading via dynamic imports.
- Ticket #64696 aims to improve real-time collaboration scalability and persistent post cache impact but has slowed down recently.
- Performance Lab plugin PR #2461 updates build scripts and fixes backward compatibility, focusing on developer tooling.
Current State of WordPress 7.0 Performance
During the May 5 performance chat, core contributors highlighted a concerning 10% regression in the Time to First Byte metric when benchmarking WordPress 7.0 against the previous 6.9 release. TTFB is a crucial indicator of backend responsiveness, reflecting how quickly the server starts sending data after a request.
Interestingly, this regression does not extend to the combined TTFB-Largest Contentful Paint (LCP) metric, suggesting that front-end load times may not be significantly impacted. The regression appears tied to additional PHP processing in WordPress 7.0, but the team has yet to isolate a single cause. This points to a distribution of smaller inefficiencies rather than one major bottleneck.
Our testing confirms that even minor increases in PHP execution time can compound across a request lifecycle, especially on sites with complex themes or numerous plugins. This regression, though modest, signals the need for targeted profiling and optimization before finalizing the 7.0 release. Agencies and developers should monitor benchmarks closely as the release approaches.
Commit Freeze and Development Focus
The core development trunk remains frozen for general commits during this phase, with exceptions made only for 7.0-specific bug fixes and testing-related changes. This freeze helps maintain stability as the release nears. Contributors have been advised to hold off on performance-related commits unless urgent or directly related to 7.0.
Testing-related pull requests, such as those submitted by @pbearne, are being reviewed and potentially merged to improve the release’s quality without introducing new features or regressions. This cautious approach is typical in late-stage release cycles to ensure stability.
Script Loading Optimization via Dynamic Imports
A new ticket, #65165, was introduced focusing on script modules depending on classic scripts. This effort aims to leverage dynamic imports, which allow scripts to load asynchronously and non-blockingly, reducing the overall amount of JavaScript loaded on pages.
Dynamic imports can improve page load times by splitting code and prioritizing critical scripts, a technique increasingly important as WordPress continues to evolve its block editor and frontend interactivity. While this ticket is still in early stages and not yet deeply reviewed, it highlights the team’s commitment to reducing unnecessary script bloat and improving client-side performance.
Real-Time Collaboration and Persistent Cache Enhancements
Ticket #64696 addresses scalability concerns with WordPress’s real-time collaboration features, particularly how HTTP polling interacts with persistent post caches. Real-time collaboration can generate frequent server requests that strain cache layers, potentially degrading performance.
Though progress on this ticket has slowed recently, its goals remain important for sites leveraging collaborative editing. Optimizing this interaction could yield significant performance benefits for multi-author environments and enterprise use cases.
Performance Lab Plugin Updates
The Performance Lab plugin, a testing ground for performance improvements before inclusion in core, continues to receive attention. Pull request #2461 updates the @wordpress/scripts package and related dependencies, resolving backward compatibility issues introduced by recent package updates.
Maintaining updated build tooling and compatibility is crucial for plugin developers and core contributors working on performance enhancements. This PR reflects ongoing efforts to streamline development workflows and ensure reliable builds.
Open Floor: Preload Link Tags Timing and HTTP Header Limits
An insightful discussion arose around the timing of <link rel="preload"> tags in the document head. Appending these tags too late in the <head> can limit their effectiveness, as browsers may start rendering before they detect them. This is particularly relevant when large amounts of CSS are inlined early, delaying the insertion of preload tags.
This issue relates to the Optimization Detective plugin, which currently adds preload tags at the end of the <head>. Although HTTP Link headers are also sent, which can mitigate the problem, an identified issue (#2304) notes that overly large Link headers may exceed Nginx server limits, causing 502 errors.
These findings underscore the complexity of frontend optimization, where server configurations and timing of HTML output can impact perceived performance and stability.
What This Means for WordPress Users
We recommend that WordPress developers and site maintainers pay close attention to backend performance metrics, especially TTFB, as WordPress 7.0 approaches release. The reported 10% regression, while not catastrophic, signals that additional PHP processing overhead might affect server responsiveness. Profiling plugin and theme interactions with WordPress 7.0 will be critical to identify any compounding factors.
For agencies and freelancers, communicating this potential performance impact to clients is essential. Testing sites thoroughly with staging environments running the latest 7.0 builds will help catch regressions early. Leveraging the Performance Lab plugin can provide early access to optimizations and tooling improvements.
From an ecosystem perspective, the attention on script module loading and real-time collaboration scalability reflects WordPress’s ongoing push towards richer, more dynamic editing experiences without sacrificing speed. However, these features come with complexity that requires careful optimization.
Hosting providers should monitor HTTP Link header sizes and server configuration limits, particularly Nginx users, to prevent errors related to large headers. The preload tag timing discussion also reminds us that frontend optimization requires coordination between server output and browser behavior.
Overall, this chat shows a mature, cautious approach to performance during a major release cycle. The freeze on commits except for critical fixes and testing ensures stability while the team investigates regressions and explores long-term improvements.
Frequently Asked Questions
What causes the 10% TTFB regression in WordPress 7.0?
The regression appears related to increased PHP processing in WordPress 7.0, but no single cause has been isolated. It likely results from cumulative overhead across multiple components rather than one bottleneck.
Is the overall page load time affected by this regression?
Not significantly. The combined TTFB-Largest Contentful Paint metric does not show regression, indicating that frontend loading remains relatively stable despite backend delays.
How can developers contribute to improving performance before WordPress 7.0 release?
Developers should focus on testing, profiling PHP execution, and reviewing existing pull requests related to performance. Avoid committing unapproved changes during the trunk freeze unless related to 7.0 fixes or testing.
What is the significance of the new script modules ticket (#65165)?
Ticket #65165 aims to optimize script loading by using dynamic imports, which can reduce the number and blocking nature of scripts loaded on pages, improving frontend performance.
Should site owners be concerned about Nginx 502 errors due to large Link headers?
Yes, site owners using Nginx should review their server limits if large HTTP Link headers are used for preload tags, as exceeding limits can cause 502 errors. Adjusting configuration or reducing header size can mitigate this.
