I’ve spent the better part of 14 years looking at how WordPress handles data, and if there’s one thing I’ve learned, it’s that custom logic is usually the enemy of scale. The February 2026 WordPress Performance Updates chat touched on a change worth knowing about: Site Health tests are migrating toward standard APIs like WP_Query.
In the past, we often saw core or plugins reaching for low-level database calls to check site status. While it felt “lean” at the time, it bypassed the very caching layers that make modern WordPress fast. If you’re interested in how deep this goes, check out my thoughts on Object Caching in Core.
Why Site Health is moving to WP_Query
During the chat, the team discussed PR #10531, which refactors how certain checks run. Moving to WP_Query cleans up the code, but the bigger win is extensibility: the standard class gives you persistent object caching and, more usefully, filters for free.
One gotcha mentioned was password-protected posts. The implementation doesn’t treat them any differently than before, but using the standard API at least gives us a predictable baseline. That also means developers can hook into the query via pre_get_posts to exclude certain content from performance audits.
<?php
/**
* Example of how the new WP_Query approach allows us to
* filter Site Health checks without hacking core files.
*/
function bbioon_filter_performance_checks( $query ) {
if ( ! is_admin() || ! $query->is_main_query() ) {
return;
}
// Only target specific Site Health queries if needed
if ( isset( $query->query_vars['site_health_check'] ) ) {
$query->set( 'post_status', array( 'publish' ) );
}
}
add_action( 'pre_get_posts', 'bbioon_filter_performance_checks' );
Modern Image Formats and View Transitions
These WordPress Performance Updates also touched on the Performance Lab plugin. There’s a push for better CODEOWNERS management on the Modern Image Formats module, which matters because the logic behind generating AVIF and WebP needs to hold up as those formats become the default.
The View Transitions plugin also has several open PRs. If you haven’t tried the View Transitions API, it’s worth a look: it lets MPA (Multi-Page Application) sites feel like SPAs without the JavaScript overhead, and that kind of detail is what makes a site feel finished instead of just functional.
The developer workflow: signal vs. noise
An interesting “Open Floor” topic was the noise generated by GitHub Slack integrations. Dependabot got called out for being a “firehose.” As someone who manages dozens of enterprise WooCommerce builds, I feel this. If your notifications are 90% noise, you’ll miss the 10% that actually breaks your production environment.
The team is considering a separate “firehose” channel for these automated alerts. If you’re managing a large team, I’d do the same. Don’t let your WordPress Performance Updates disappear under a pile of “Package X updated to version 1.0.1” messages. For more on managing core noise, see my article on Scripts and AI in Core.
If this WordPress Performance Updates stuff is eating into your dev hours, let me handle it for you. I’ve been wrestling with WordPress since the 4.x days.
Takeaway for developers
Core is moving away from bespoke SQL queries and toward standardized, filterable APIs. That should make our jobs easier in the long run, as long as we work with the “WordPress way” instead of against it. Use the transients and filters already available in the WP_Query Documentation rather than trying to outsmart the query engine, and keep an eye on how page cache detection logic holds up in future releases.
