The full chat log is available beginning here on Slack.

WordPress Performance Trac tickets

• @westonruter shared a Trac query covering performance-related tickets milestoned for WordPress 6.9.1 and 7.0.
• @westonruter shared that for ticket #61500, some work was done recently as part of the CodeMirror upgrade effort.
  • @westonruter explained that ideally there would be a declarative way to add script modules as dependencies for classic scripts, and noted that a workable approach is to register an empty script module that declares module dependencies, and then enqueue that module whenever the classic script is enqueued. @westonruter
    shared reference to example diffs demonstrating this workaround and mentioned being glad to find a quick solution.
• @mukesh27 asked whether @westonruter had reviewed the latest comment on #64229, where @wildworks raised a minor point and opened a PR.
  • @westonruter replied that the comment had been seen the night before and initially mentioned not having a patch yet, then noted that a PR already existed and shared PR #10799. @westonruter reviewed the PR, said it looked good, and approved it.
• @westonruter brought up #64066 and shared that @gilbertococchi is actively working on collecting data to support switching to moderate prefetch by default on sites with caching.
  • @westonruter referenced a Slack thread where LCP passing rates for conservative versus moderate prefetch were discussed and noted that additional data is being gathered by flipping a few CrUX-eligible sites from conservative to moderate to compare LCP passing rates and page hit increases over time.
  • @westonruter added that landing #64066 is related to #64370, noting that the latter needs to land to ensure reliable detection.
• @mukesh27 asked about the review status of PR #10606 and mentioned seeing comments from @westonruter.
  • @westonruter replied that the PR had just been closed.

Performance Lab Plugin (and other performance plugins)

• @westonruter shared being behind on PR reviews.
• @mukesh27 mentioned plans to re-review PR #2321.

Open Floor

• @westonruter shared recent experience using GitHub Copilot together with Gemini CLI locally, describing it as immensely useful both for review and implementation work. @westonruter described Copilot as significantly better than a traditional linter during reviews and noted that it can provide strong first-pass implementations. @westonruter shared PR #10778 as an example of using Gemini CLI during the CodeMirror upgrade and explained that a detailed historical and technical specification was provided to the tool.
  • @westonruter also shared that Copilot was used to draft a Performance Lab fix while on public transit using only a phone, referencing PR #2346.
  • @dmsnell cautioned that Copilot can sometimes reintroduce defects during PR reviews, sharing an anecdote where Copilot repeatedly flagged and reintroduced a PCRE-related bug even after it had been fixed.
  • @justlevine added that this behavior can indicate ambiguities in code and suggested that improving self-documentation helps both humans and LLMs.
  • @dmsnell emphasized the need for extra care when LLMs introduce defects, as they can confidently repeat mistakes if the surrounding code does not change enough.
  • @westonruter agreed, noting that while hallucinations occur, the tools still provide good feedback most of the time and help shift focus away from minutiae like coding standards toward higher-level problem solving.
• @dmsnell raised the topic of memoizing wp_normalize_path, noting observed performance improvements of roughly 1ms during WordPress startup in certain environments. @dmsnell explained that while this is a micro-optimization, it can have meaningful impact at scale and shared that @josephscott has been investigating early startup costs using production measurements. @dmsnell mentioned having tested earlier versions without caching and discussed trade-offs between caching and alternative approaches, including replacing PCRE calls and addressing what may be a latent bug.
  • @westonruter asked whether similar performance benefits were observed across different approaches.
  • @dmsnell replied that while direct testing had not yet been done for all variants, prior comparisons suggested the cache provided most of the benefit at a fraction of the cost, and that both approaches could potentially coexist.
  • @westonruter summarized this as a “both/and” situation rather than an either/or choice.

Our next chat will be held on Tuesday, February 10, 2026 at 16:00 UTC in the #core-performance channel in Slack.

#core-performance, #hosting, #performance, #performance-chat, #summary