class="wp-block-list">

@westonruter added two tickets to the milestone yesterday: #43258 and #63007

• @flixos90: #43258 seems like a pretty big change to start working on this late in the cycle. It looks like there’s no PR yet?
• @westonruter: No PR yet, but it has been in Gutenberg (client-side navigation experiment) for awhile now, and in Optimization Detective as well. The patch would be small.
• @flixos90: Since WordPress Core has never included an output buffer (whether for good reasons or not), I think this requires more discussion that would not be possible to have in just a few days.
• @westonruter: I’ll open a PR and we can discuss. If no consensus  then we’ll punt.

@pbearne believes his tickets are ready

• @flixos90: Some PRs like the one on #62124 may be ready, but they haven’t had any reviews from committers yet. So depending on bandwidth, they may not make it

@flixos90: It looks like most of the 6.8 performance enhancements have had some updates in the last few days, so hopefully they’re moving along. I’m going to check in on the ones without recent updates later, and can do another last-minute scrub to either commit or punt on Monday.

@joemcgill is curious about #58001 and #57496, which are both close, but the deadline for Beta 1 is coming very quickly. #58001 was marked early and is at risk of getting punted this week without follow-up.

• @spacedmonkey: I need to add unit tests right? Is there anything else needed?
• @joemcgill: @flixos90 left feedback on the PR that is not resolved, but once you two are happy with it being committed, it seems good to go
• @flixos90: Beyond my feedback that hasn’t been addressed yet, the #58001 PR needs a review by someone else. I explicitly mentioned that the metadata lazyloader changes that are part of it fall outside my domain too much so I wouldn’t be comfortable approving those changes. Alternatively, the PR could be split into two pieces, as I’m happy and more confident to review the WP_User changes
• @joemcgill: Oh right. I’ll look again, but it seemed ok to me. Could be good to get @peterwilsoncc‘s feedback given he’s also looking at #57496.

Performance Lab Plugin (and other performance plugins)

• @flixos90 opened https://github.com/WordPress/performance/pull/1883 yesterday to use the now merged WP Core API for Speculative Loading conditionally if available

Open Floor

• @westonruter: From doing performance audits at WordCamp Asia (and previous WordCamps), something I’ve been seeing more and more being the performance bottleneck is render-blocking stylesheets in the HEAD. This often shows up as a render delay when the LCP element is text, e.g. a paragraph or heading. I started investigating further and I found that Twenty Twenty-Two and Twenty Twenty-Five are not inlining their style.css files when they should be, so I opened this ticket with a patch to implement: #63007
  • @westonruter: When all stylesheets are inclined a dramatic reduction in LCP(-TTFB) results when I tested with a Slow 3G network condition: 4196.1 ms (poor) down to 2230.8 ms (good). Related to that, I found that no stylesheets in core themes are getting minified, so I opened #63012 to address that.
  • @westonruter: Additionally, I think we should investigate increasing the styles_inline_size_limit from 20,000 bytes to maybe 50,000 bytes. I intend to do some benchmarks to show the performance tradeoff of inlining versus having a cached stylesheet for repeat visits. Relatedly, the landing of Speculative Loading means additional byte size of documents with inclined CSS will now result in less of an impact due to prefetching.
  • @spacedmonkey: There is some push back to minify theme css right?
  • @flixos90: I think the concern is related to block themes specifically, since end users are more in touch with them than they were with classic themes, e.g. you can export a theme etc. from making changes in the UI. So the lines between end user and developer territory blur. I’m not sure about whether that should block us from implementing minification, but all I’m saying is the implications differ between block themes and classic themes.
  • @westonruter: But with block themes users don’t edit any CSS file in the Site Editor, right? It’s separate from Global Styles.
  • @flixos90: Worth highlighting https://core.trac.wordpress.org/ticket/58519#comment:2 too (and other comments of similar nature) that highlight that before we allow inlining default theme CSS, we should minify the files to avoid more HTML bloat. So potentially #63007 should depend on #63012.
• @westonruter: I wanted to mention that the talk I gave at WordCamp Asia about Optimization Detective is available: https://weston.ruter.net/2025/02/21/boosting-performance-with-optimization-detective/

Our next chat will be held on Tuesday, Mar 11, 2025 at 16:00 UTC in the #core-performance channel in Slack.

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