If WordPress Core Performance sounds like installing a caching plugin and walking away, you have not spent enough time in the Trac weeds. The performance that survives at scale gets built into the foundations, usually by devs arguing over micro-optimizations nobody else will ever notice.
The latest performance chat covered a few messy upgrades. Most of the time went to bridging legacy “classic” scripts with modern script modules, and to what AI actually does to a senior development workflow. We also went through the “both/and” argument about micro-optimizations that shave milliseconds off WordPress startup.
The script module dependency hack (ticket #61500)
The CodeMirror upgrade is the current headache in WordPress Core Performance. Modern script modules are what we want, but the classic script dependency system does not cooperate with them. Weston Ruter offered a workaround that is clever and a little ugly: register an empty script module and let it act as a bridge.
You create a dummy module that declares the dependencies you actually need, then enqueue it next to your classic script. That keeps the right module context available even when you enqueue things the old way. It is the sort of technical debt we take on so the platform can move without breaking older implementations.
<?php
/**
* Example of bridging classic scripts with module dependencies
*/
function bbioon_bridge_module_dependencies() {
// Register the modern module
wp_register_script_module(
'bbioon-modern-logic',
'/path/to/module.js',
array( 'wp-api-fetch' )
);
// Create an empty "classic" script that depends on the module
wp_register_script(
'bbioon-classic-bridge',
'', // Empty src
array(),
null
);
// When we enqueue the classic script, we manually trigger the module
wp_enqueue_script( 'bbioon-classic-bridge' );
wp_enqueue_script_module( 'bbioon-modern-logic' );
}
add_action( 'wp_enqueue_scripts', 'bbioon_bridge_module_dependencies' );
AI in the dev workflow, with caution
GitHub Copilot and the Gemini CLI came up as well. I use both daily, and Weston called them “immensely useful” for a first-pass implementation, which matches my experience. The war stories are the other half of it. A linter fails in boring, predictable ways, while AI fails confidently.
D.M. Snell described Copilot reintroducing a PCRE-related bug over and over after it had been fixed. The model kept putting the defect back into the PR because the surrounding code had not changed enough to move its context. So the tools are fine for drafting code on public transit, which is how Weston wrote a Performance Lab fix, but they need a heavy hand in review. Skip reading a generated line and you have shipped tomorrow’s technical debt.
If you want to go past script enqueuing on site speed, I have a guide on WordPress Performance Optimization and Speculative Loading.
Micro-optimizations and startup cost
Saving 1ms at startup is worth the effort on a high-traffic site. That is why we have been looking at memoizing wp_normalize_path. It is a textbook micro-optimization, and on a large site those milliseconds add up. Some people argued for dropping the PCRE calls altogether, others wanted plain caching.
We landed on both. Caching gives the biggest immediate win for a fraction of the work, while cleaning up the regex underneath is the correct long-term fix. WordPress Core Performance work usually ends up doing both, because hosting environments differ enough that either one alone is unreliable. The official WordPress Trac tracks where these land.
If this WordPress Core Performance stuff is eating your dev hours, I can take it off your hands. I have been wrestling with WordPress since the 4.x days.
The pragmatic takeaway
Performance is never finished. The bloat just changes shape, from tangled script dependencies one month to AI-generated bugs the next. Work toward WordPress 7.0 is aimed at more reliable detection and smarter prefetching. Read the source, and check whatever the AI hands you.
