I’ve spent the better part of 14 years looking at how WordPress handles data, and if there is one thing I’ve learned, it’s that “custom logic” is often the enemy of scale. The latest WordPress Performance Updates from the February 2026 chat highlight a shift that every senior developer should appreciate: the migration of Site Health tests 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 recent chat, the team discussed PR #10531, which refactors how certain checks are performed. Specifically, moving to WP_Query isn’t just about cleaning up the code; it’s about extensibility. When you use the standard class, you automatically inherit support for persistent object caching and, more importantly, filters.
One “gotcha” mentioned was password-protected posts. Currently, the implementation doesn’t specifically account for them differently than before, but by using the standard API, we at least have a predictable baseline. Specifically, this allows developers to hook into the query via pre_get_posts if they need 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. We’re seeing a push for better CODEOWNERS management for the Modern Image Formats module. This is critical because as AVIF and WebP become the standard, the logic for generating these needs to be bulletproof.
Furthermore, the View Transitions plugin has several open PRs. If you haven’t played with the View Transitions API yet, you’re missing out on a way to make MPA (Multi-Page Application) sites feel like SPAs without the JavaScript overhead. It’s the kind of technical refinement that separates a “built” site from a “crafted” one.
The Developer Workflow: Signal vs. Noise
An interesting “Open Floor” topic was the noise generated by GitHub Slack integrations. Specifically, Dependabot was 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. Therefore, if you are managing a large team, I suggest doing the same. Don’t let your WordPress Performance Updates get buried 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.
Look, if this WordPress Performance Updates stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Takeaway for Developers
The trend is clear: Core is moving away from bespoke SQL and toward standardized, filterable APIs. This makes our jobs easier in the long run, provided we embrace the “WordPress way” of doing things. Stop trying to outsmart the query engine and start leveraging the transients and filters already available in the WP_Query Documentation. Specifically, pay attention to the robustness of page cache detection logic coming in future releases.
