The full chat log is available beginning here on Slack.

WordPress Performance Trac tickets

• @westonruter mentioned ticket #63636 related to BFCache was punted due to an unresolved Chromium bug around Clear-Site-Data: "cache" headers.
• @westonruter identified ticket #43258 on output buffering as the current biggest blocker. He explained that while there’s been significant discussion both on the PR #8412 and in Slack, the debate centers around the trade-offs between enabling full-page buffering (to allow post-render optimization) versus keeping the door open for streaming, which could improve initial load performance. He provided further context on how classic themes already stream via procedural rendering, while block themes generally do not.
  • @westonruter noted that while streaming isn’t widely adopted in WordPress today, it could become valuable in the future, and care should be taken not to block its evolution. He also shared a WPDirectory search of flush() usage across core, noting they appear mostly in admin and XML-RPC contexts rather than template rendering.
  • @westonruter asked if anyone has insights into this area and can contribute thoughts on how we can bridge these two perspectives, allowing for a default output buffer while also enabling streaming if the application wants it. He’d be most thankful.
• @b1ink0 brought up PR #9867 related to footer script module support and noted that @jonsurrell had provided thoughts around dependency handling.

Performance Lab Plugin (and other performance plugins)

• @westonruter mentioned new guidance on AI-generated contributions now available in the Performance repo, including a new AGENTS.md file and updated PR template instructions with PR #2193. He explained that this was prompted by a recent increase in AI-assisted PRs, some of which indicated the AI’s output wasn’t being carefully reviewed by the contributor.

Open Floor

• @westonruter introduced Trac ticket #64066, proposing that WordPress default to moderate eagerness for Speculative Loading, when caching is detected. He noted the idea could provide a performance boost in WordPress 7.0 by improving preload efficiency on cached sites, but also acknowledged the need to weigh sustainability concerns around increased server load.
  • @mukesh27 asked whether a second opinion was needed, and whether any Google team members had provided feedback.
  • @westonruter replied that he had received positive input from Google, though their priorities don’t always align with those of hosts and site owners. He noted that moderate eagerness can increase bandwidth usage due to unnecessary preloads and may lead to added hosting costs.
  • @gilbertococchi shared his thoughts, emphasizing that moderate eagerness could be significantly more impactful than conservative loading, especially with Chrome’s recent introduction of a Viewport Heuristic, but stressed the importance of safeguards like persistent object caching to mitigate server load.
  • @mukesh27 summarized that @gilbertococchi was supportive of the proposal and encouraged moving the ticket into the 6.9 milestone for visibility.
  • @westonruter clarified that while he wasn’t necessarily aiming for inclusion in 6.9, he agreed to milestone the ticket for tracking purposes, with the understanding that it may still be punted.

Our next chat will be held on Tuesday, October 21, 2025 at 15:00 UTC in the #core-performance channel in Slack.

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