If you think WordPress Core Performance is just about installing a caching plugin and walking away, you haven’t spent enough time in the Trac weeds. Real performance—the kind that survives at scale—is built in the foundations, usually by devs arguing over micro-optimizations that most people never see.
In our latest performance chat, we tackled some messy but necessary upgrades. Specifically, we’re looking at how to bridge the gap between legacy “classic” scripts and modern script modules, alongside the reality check of using AI in a senior-level development workflow. Furthermore, we discussed the “both/and” approach to micro-optimizations that can shave precious milliseconds off the WordPress startup cost.
The Script Module Dependency Hack (Ticket #61500)
One of the biggest headaches in WordPress Core Performance right now is the CodeMirror upgrade. We want to use modern script modules, but the dependency system for classic scripts doesn’t naturally play nice with them. Weston Ruter shared a clever, if slightly “hacky,” workaround: registering an empty script module that acts as a bridge.
The logic is simple: you create a “dummy” module that declares the dependencies you actually need, then enqueue that module alongside your classic script. It’s the kind of technical debt we accept to keep the platform moving forward without breaking legacy implementations. Consequently, this ensures that the correct module context is available even when enqueuing scripts the “old” way.
<?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 Dev Workflow: A Word of Caution
We need to talk about GitHub Copilot and the Gemini CLI. I use these tools daily, and as Weston noted, they are “immensely useful” for first-pass implementations. However, we also shared a few “war stories” that should make any senior dev pause. In contrast to a traditional linter, AI can be confidently wrong.
D.M. Snell shared an anecdote where Copilot repeatedly reintroduced a PCRE-related bug even after it was fixed. The AI “hallucinated” the defect back into the PR because the surrounding code hadn’t changed enough to shift its context. Therefore, while these tools are great for drafting code on public transit (as Weston did for a Performance Lab fix), they require a heavy hand in review. If you aren’t reading every line of generated code, you are just shipping future technical debt.
If you’re looking to optimize your site’s speed beyond just script enqueuing, check out my guide on WordPress Performance Optimization and Speculative Loading.
Micro-Optimizations and Startup Costs
Is saving 1ms during WordPress startup worth the effort? In a high-traffic environment, absolutely. We’ve been looking at memoizing wp_normalize_path. It’s a classic micro-optimization, but when you’re dealing with massive sites, those milliseconds compound. Some argued for replacing PCRE calls entirely, while others favored simple caching.
The consensus? It’s a “both/and” situation. Caching provides the most immediate benefit at a fraction of the implementation cost, but cleaning up the underlying regex logic is the “correct” long-term play. In WordPress Core Performance, we often have to do both to ensure stability across different hosting environments. You can follow the progress of these optimizations on the official WordPress Trac.
Look, if this WordPress Core Performance stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Pragmatic Takeaway
Performance isn’t a “one-and-done” task. It’s a constant battle against bloat, whether that bloat comes from messy script dependencies or AI-generated bugs. We’re pushing toward WordPress 7.0 with a focus on reliable detection and smarter prefetching. Stay technical, read the source, and don’t trust the AI blindly.
” ,keyphrase:
