The full chat log is available beginning here on Slack.

WordPress Performance Trac tickets

• @westonruter The second beta of 6.8 was just released.
• @westonruter There are 5 performance tickets in the milestone.
  • @johnbillion RE #63026, this is an issue with the performance of the tests due to the high number of user fixtures, all of which generate and hash a password for the user with each fixture. The regular performance tests are not indicatiny any general performance regression. I think we can therefore remove the performance
    focus unless there’s an objection.

Performance Lab plugins

Discussing the upcoming release scheduled for Monday, Mar 17, 2025 at 17:00 UTC.

• @westonruter Let’s start with the upcoming set of Performance Lab releases which is due March 17th.
• @westonruter As noted by @flixos90, this release won’t actually include any update to the Performance Lab plugin itself. Instead there will be updates to Optimization Detective, Image Prioritizer, Embed Optimizer, Speculative Loading, and Modern Image Formats. Therefore, he suggests that we take this as an opportunity move away from using the PL’s version for the release tags. In reality this should have been done long ago when we split up the plugin into standalone plugins. So instead of the release branch being release/4.0.0 it could instead be release/20250317. The title of the release then I suppose would be 2025-03-17 as well.
• @mukesh27 Does the release triggered manually as we didn’t release PL plugin?
  • @westonruter The GHA workflow doesn’t depend on releasing the PL plugin anymore, right? I mean, ever since the plugin was split into standalone plugins, I don’t think this was the case
• @flixos90 It would feel a bit odd to have a release called 2025-03-17 in the GitHub releases page, but I’d argue that’s only because of the previous releases using the PL version number. It’s already odd now in that each release is labelled by the PL version number, but actually includes multiple releases using different versions. So I think that would be fine.
• @westonruter We can include a note in the release description that explains the naming convention change.
• @mukesh27 What happens in the future if we find ourselves in the same situation? Will we use the release date again?
• @westonruter Yeah, I think we’ll use dates from now on.
  • @flixos90 Are you saying we should use dates for the release branches and GH releases going forward even when PL is among the released plugins? If we are going to do that, we should modify the documentation in the Core Performance Handbook.
  • @westonruter Yes, I think we should use dates going forward.
  • @swissspidy Agreed. Would be even more confusing otherwise.
• @westonruter There are 4 milestones for Monday which have issues/PRs:
  • speculation-rules 1.5.0
  • webp-uploads 2.5.1
  • embed-optimizer 1.0.0-beta2
  • optimization-detective 1.0.0-beta3
• @westonruter Looks like Modern Image Formats primarily just needs a couple tweaks prior to merging one PR. It looks like the other PR will need to get bumped.
• @flixos90 Regarding the changed branch naming and release naming strategy, anyone up for updating the Make Core Performance Handbook documentation accordingly?
  • @westonruter I can do it. I typically tweak the handbook after going through the release based on how it went.
• @mukesh27 I have to share update on the accurate sizes project: I picked it up and started working on it this week. The PR #1795 adds the ancestor block context and is ready for review.

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

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