WordPress 7.0 ships tomorrow, so the performance chat had moved past speculation and into final hardening. The WordPress 7.0 performance work has been aimed at efficiency for classic themes as much as block themes, which matters because classic themes still run most of the client sites I touch.
I have spent a good chunk of my 14 years in this ecosystem cleaning up after “performance” plugins that made sites slower. So watching the Core Performance team go after block styles in classic themes and lock down the monorepo against supply chain attacks is welcome. It is the unglamorous work that keeps a site from breaking when someone runs a routine npm install.
Classic themes and the block style bottleneck
Classic themes and block styles have been a sore spot for several releases. Weston Ruter shared updates on a plugin that combines core block assets, which has mattered a lot for sites sitting right at the 7.0 boundary. The team also worked on on-demand block stylesheet loading, so it behaves more predictably on themes still built around PHP templates.
On a classic theme, WordPress 7.0 performance changes mean a page using a paragraph and an image no longer pulls in the whole block library’s CSS. That cuts render-blocking stylesheets, which is where Largest Contentful Paint (LCP) usually suffers. For wider context on the release, there is a pragmatic guide to WordPress 7.0 features.
Performance Lab: PHP 7.4 and security hardening
The Performance Lab monorepo is finally raising its minimum supported PHP version from 7.2 to 7.4. Yes, it is 2026, and yes, 7.2 was still in there; legacy hosting is stubborn. Aligning with the WordPress 7.0 performance baseline made the bump worth doing, both for newer language features and for keeping the codebase maintainable.
The build process got tightened too. A new .npmrc file sets ignore-scripts = true, which stops a malicious package from executing code during install. The trade-off is that you now run npm run prepare yourself for things like Husky hooks. One extra command, and worth it.
The FTP filesystem gotcha
Plugin installs that fail on one host and work everywhere else are a familiar kind of misery. Weston shared a fix for PR #2482, which covered Performance Lab plugins failing to install when WordPress used FTP filesystem methods such as ftpext or ftpsockets.
That tends to show up on restricted hosting where the server cannot write to disk directly. The fix keeps the new “Connectors” screen in core working for people on older stacks. The WP_Filesystem API is still one of the gnarlier corners of core, future-facing releases or not.
AI-driven recommendations
Adam Silverstein opened an issue about AI-based performance recommendations. With the wider AI framework arriving in WordPress 7.0, the idea is to hand users advice, and in some cases automated fixes, based on their own site configuration. The mechanism is the Model Context Protocol (MCP), which gives AI tools enough site context to say something specific rather than generic. Our analysis of WordPress core performance and auto-sizes covers more of the optimization roadmap.
If WordPress 7.0 performance work is eating your dev hours, I can take it on. WordPress has been my day job since the 4.x days.
What to check before tomorrow
Most of the 7.0 performance story is a leaner core engine rather than new blocks. Between the Performance Lab PHP 7.4 minimum and the fix to how block styles are enqueued on classic themes, the theme of this cycle is stability. If you run a monorepo or a high-traffic site, look at the new npm settings and check your PHP version before the update lands tomorrow.
