WordPress 7.0 Performance: What Developers Should Actually Test

WordPress 7.0 shipped on May 20, 2026 with a redesigned administration experience, new AI-related foundations, and a broad developer toolbox. Performance is part of that platform story, but the most useful question is not “Is WordPress 7 faster?” It is “Which Core changes affect this site, and what still depends on its theme, plugins, hosting, and content?”

Core can remove overhead and improve defaults. It cannot make an oversized hero image, duplicate tracking stack, slow third-party API, or poorly designed query disappear.

Performance is a release sequence, not one switch

The work visible in WordPress 7.0 builds on earlier Core releases. Recent cycles have addressed image loading, Largest Contentful Paint heuristics, render-blocking resources, block styles, script modules, database queries, caching, and scheduled tasks. Some improvements benefit sites automatically; others provide APIs or defaults that themes and plugins must use correctly.

This matters when measuring an upgrade. A site moving from an older branch to 7.0 may receive several generations of changes at once. A site already on the latest 6.9 release may see a smaller difference. Attribute results to a controlled before-and-after test, not the version number alone.

Asset loading still deserves inspection

Block-based rendering allows WordPress to understand which components appear on a page. In principle, that supports loading only relevant styles and scripts. In practice, themes and plugins can enqueue global assets, duplicate libraries, inject inline configuration, or depend on compatibility layers.

After upgrading, inspect the actual network waterfall:

• which CSS files block rendering;
• whether block styles are loaded only when needed;
• which scripts execute before interaction;
• whether modules and classic scripts are duplicated;
• which assets come from plugins rather than Core; and
• whether cache headers and compression are correct.

Counting requests is not enough. A small necessary request can be cheaper than a large combined file full of unused code.

Script modules and dynamic behavior

The modern WordPress JavaScript architecture increasingly uses modules and APIs that support more deliberate dependency loading. That can reduce unnecessary execution, but only when the application boundary is designed well.

A plugin that ships a large interactive bundle on every route still pays the parsing and execution cost. A builder that emits many small modules may save code on one page while increasing coordination overhead on another. Measure main-thread work, interaction readiness, and real device behavior—not only transfer size.

Developers should also test consent tools, optimization plugins, and security policies. Reordering or delaying a module can break functionality even when a synthetic score improves.

Database and cache improvements need realistic data

Core query and cache work can improve common paths, but a production site's expensive requests often come from custom queries, metadata patterns, search, commerce, multilingual plugins, remote calls, or page-builder data.

Use representative database size and a cold-cache as well as warm-cache test. Record query count, slow queries, object-cache behavior, Time to First Byte, and external request time. A staging site with ten posts and no traffic does not reproduce a content-heavy production system.

Persistent object caching can help repeated database work, but it is not a cure for unbounded queries. Cache invalidation, key growth, and plugin compatibility require observation.

PHP 8.5 support is not an instruction to skip testing

WordPress 6.9 and 7.0 are documented as fully supporting PHP 8.5. WordPress 7.0 also raised its minimum supported PHP version to 7.4, although currently supported PHP branches are the sensible production target.

Core compatibility is only one layer. The site's theme, child theme, plugins, must-use plugins, command-line jobs, and hosting extensions must also support the selected PHP version. Test deprecation logs, scheduled jobs, image processing, email, REST endpoints, and administrative workflows.

A newer PHP runtime can improve performance and security, but an upgrade should be treated as a platform change with rollback—not as a benchmark shortcut.

Why themes and plugins still dominate

Real WordPress performance is an emergent property of the whole site. Common bottlenecks include:

• unoptimized responsive images;
• excessive DOM and deeply nested builder output;
• fonts and icons loaded globally;
• render-blocking theme assets;
• duplicate animation and slider libraries;
• third-party advertising, chat, consent, or analytics scripts;
• uncached remote API requests;
• expensive custom queries; and
• plugin features enabled on routes that do not use them.

Core cannot know that a particular carousel is unnecessary or that a marketing tag provides little value. Those remain design and governance decisions.

What builder and child-theme developers should test

For a Bricks or child-theme project, I would compare the same production-like page before and after the upgrade, with caches controlled. The test set would include:

1. a representative landing page with its real hero media;
2. a long content page;
3. search or archive output;
4. a form and its validation path;
5. an authenticated editor workflow; and
6. scheduled or integration tasks.

Measure server response, LCP, Interaction to Next Paint, Cumulative Layout Shift, transferred bytes, script execution, query behavior, and error logs. Then inspect visual and functional regressions. A faster page with a broken menu is not an improvement.

Test the child theme without optimization plugins once, then add caching and minification back in stages. That separates Core behavior from transformations applied later in the delivery pipeline.

A future-first optimization strategy

Keep page-specific assets page-specific. Use responsive media with explicit dimensions. Prefer native browser capabilities over heavy libraries. Budget third-party scripts. Maintain supported PHP and database versions. Profile before adding a cache. Remove code and features that no longer serve the page.

Most importantly, preserve a repeatable baseline. Performance work becomes reliable when the team can answer what changed, on which route, under which cache state, and on what device profile.

Faster defaults still require architecture

WordPress 7.0 advances the platform, and current PHP support gives developers a healthier runtime target. Neither changes the central performance truth: Core supplies the foundation, while the site's architecture determines what users download, execute, query, and see.

Upgrade for maintained software and platform capability. Measure the result. Then optimize the theme, plugins, content, and integrations that actually dominate the experience.