Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

• Welcome to our new members of #core-performance
• Reminder on timezone difference for the next 3 weeks, this chat will remain at 16:00 UTC, then it will switch to 15:00 UTC from April 2

Priority Items

Structure:

• WordPress performance Trac tickets discussion
• Performance Lab plugin (and other performance plugins) discussion
• Active priority projects
  • Plugin checker
  • Improve template loading
  • INP opportunities research

WordPress Performance Trac Tickets

• For WordPress 6.5:
  • @joemcgill
    opened #60749
    • @flixos90 asked if this is mostly a memory win?
    • @joemcgill It does seem to be less of an impact on IWT than what I was measuring on Friday. Still not sure what the difference is there, or if there is some caching in play that I had disabled on Friday. Even so, it does make a positive impact and memory consumption can lead to slower IWT. The other place that could use more eyes is trying to identify opportunities to improve the performance of the Navigation block, which went through a bigger refactor during this release, which is leading to longer rendering times. I don’t think we’ve identified any particular flaw thus far
  • @flixos90 working on the ongoing research on potential performance regression that I think is still unresolved [link]
  • @joemcgill will plan on doing another set of benchmarks for RC 2 once it has been released, and can continue
• For Future Releases:
  • We already have 16 items in the 6.6 milestone, but it’s a good time for folks to start thinking about what they are wanting to focus on for the next release.

Performance Lab Plugin (and other Performance Plugins)

• @flixos90 posted an update on what’s next for 3.0 of the Performance Lab plugin:
  • There are a couple new issues defined for the 3.0.0 milestone:
  • https://github.com/WordPress/performance/issues/1029 (PR in progress)
  • https://github.com/WordPress/performance/issues/1030 (ready for engineering once 1029 PR has been merged)
  • https://github.com/WordPress/performance/issues/1031 (ready for PR)
  • https://github.com/WordPress/performance/issues/1032 (requires further discussion)
  • https://github.com/WordPress/performance/issues/1045 (ready for PR once 1031 PR has been merged)
  • https://github.com/WordPress/performance/issues/1046 (requires further discussion, not engineering related)
• @mukesh27 has 2 PRs ready for review:
  • PR #1049 – Fix test-plugins command
  • PR #1048 – Support changing autoload value for largest autoloaded options

Active Priority Projects

Plugin Checker

• Mostly quiet since the 1.0 release. There is the start of a 1.1 milestone, but I think the folks involved in next steps here have been mostly busy with WC Asia and 6.5 release work.

Improve template loading

• @thekt12 is exploring other parts of the ticket #59600   PR https://github.com/WordPress/wordpress-develop/pull/6137
• @joemcgill I see that there is some feedback from @flixos90 that needs to resolve about the filter in https://github.com/WordPress/wordpress-develop/pull/6137
• @thelovekesh PR for 1029 is ready for further review. Also, PR for this issue alters anything related to Site health and not modules.
  • Asked @mukesh27 https://github.com/WordPress/performance/pull/1042#pullrequestreview-1930761224, can we keep this the part of PR where we remove modules completely? @flixos90 already replied

INP research opportunities

• @joemcgill Last item in our active priority projects list: INP opportunities research. I believe @adamsilverstein recently did some research on this, but am unsure if there is anything ready to be shared yet. We can pick this up in a future meeting. That is a good reminder to everyone that INP became a Core Web Vital starting today: https://web.dev/blog/inp-cwv-march-12
  • One of our team goals for this year is to find ways to improve WP this metric, so it’s good to keep in mind.

Open Floor

• @thelovekesh asked Currently when we do a plugin release it triggers two workflows:
  • PL plugin release
  • and Standalone plugin release.
  • Do we always need to trigger the workflow for standalone plugins?
• @flixos90 By default, new versions of standalone plugins are triggered together with the PL plugin release. Other than that, it would need to be the manual workflow. That’s how it works now. There’s certainly things that can be improved. We need to rethink our release strategy, for instance also whether we want to have releases of the standalone plugins tagged on GitHub in addition, which right now is missing
• @thelovekesh We might need to streamline release notes for PL and standalone plugins. Currently we are including them for PL plugin. With https://github.com/WordPress/performance/pull/1033, we are attaching all release assets on specific release.
• @flixos90 Right, the changelog generator also only works for PL right now.
• @pbearne is working down this list in age order to review/renew [link]
  • @flixos90 I gave your PR for limiting autoloaded options size another review last week, it looks really good, just a few minor things. Have you been able to take a look at that? I’d love to commit this early in the 6.6 cycle
  • @joemcgill Something else that would be helpful is that if you run across an issue that you think should be prioritized because it makes a big impact to improve overall performance for end users, please share it in the channel so we can get more eyes on it and get it into a milestone.
  • @pbearne will start with these tickets 18836 ORDER BY RAND() is slow
    If we can get some modified SQL that works
• REMINDER: This meeting will continue at 16:00 UTC for the next 3 weeks, then it will switch to 15:00 UTC from April 2 onwards

Our next chat will be held on Tuesday, March 19, 2024 at 16:00 UTC in the #core-performance channel in Slack.

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