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

Announcements

• Welcome to our new members of #core-performance
• Last week we reached over 1,000 members of our channel
• WordCamp US is coming up Sep 17-20 in Portland, Oregon – we will have a performance table at Contributor Day with Adam
• WordPress 6.7 Beta 1 is October 1

Priority Items

• WordPress performance Trac tickets
  • Current release (6.7)
  • Future releases
• Performance Lab plugin (and other performance plugins)
  • Next milestone
  • Clarification on September release date due to clash with WordCamp US
• Active priority projects
  • Project board

WordPress Performance Trac Tickets

• There are currently 21 performance issues in 6.7
• @mukesh27 for #61847 the Auto Sizes for Lazy-loaded Images PR has already been reviewed by Joe and Felix. We’re now waiting for @joemcgill feedback on whether we need a filter to remove the auto keyword from the sizes attribute or not other then that it ready for merge.
• @pbearne will work on #61103 to be ready for another review
• @mukesh27 advised #61436 is close to being merged, @flixos90 will take ownership

Performance Lab Plugin (and other Performance Plugins)

• Performance Lab plugin and the following performance plugins:
  • Enhanced Responsive Images
  • Embed Optimizer
  • Image Prioritizer
  • Image Placeholders
  • Modern Image Formats
  • Optimization Detective (Developer Preview)
  • Performant Translations
  • Speculative Loading

• Discussed the next Performance Lab release moving a week later to Sep 23 due to WordCamp US
• @flixos90 While not related to WordPress/performance, I spent some time last week documenting the processes for how the Plugin Checker works, see https://github.com/WordPress/plugin-check/issues/597 and https://docs.google.com/document/d/1wDGZBwWB2WAxfbHE3lygIzQFK8IssCa5apOyaBolukQ/edit. Since the logic is quite complex to follow with the different possible scenarios, this is probably valuable to have as a reference, so please have a look if you’re interested, should help any contributor to PCP
  • Eventually, after ironing out remaining questions and functional quirks, we could add a version of that to the docs folder of the repository

Active Priority Projects

Investigate INP Improvements

• No updates this week

Improving the calculation of image size attributes

• @joemcgill I created https://github.com/WordPress/performance/issues/1511 as a stub issue to represent the next big effort related to improving image sizes improvements, and have been supporting @mukesh27 with defining a set of approaches to consider for moving that project forward, which is very close to being ready for feedback.

Enable Client Side Modern Image Generation

• @swissspidy Working on Gutenberg PRs for media, but currently focusing on my WCUS talk

Enhance Onboarding Experience of Performance Lab Plugin

• @flixos90 last week we informally chatted a bit more about asking some attendees at the WCUS booth to test using the PL plugin, to see how they experience the onboarding, where they may be confused or have questions. So that’s definitely something we’re going to incorporate in the Google booth section for performance – primarily for attendees that may not be familiar with the plugin yet, or at least haven’t used it before

Open Floor

• Discussion around this Slack thread for persistent object cache
  • @westonruter I suppose the test for object caching should only be prominent if a site does not have page caching. A site may not use page caching due to it being highly dynamic or acquiring users to be logged in. For such a site, object caching would perhaps be the next best thing instead of page caching.
  • @joemcgill There are so many “it depends” scenarios when it comes to what caching strategy is best. For example, if you’re running a site like a store that needs to serve dynamic data and can’t use a full page cache, an object cache will reduce the load on the DB, which should speed up requests. However, if you run a site that can make use of a full page cache, that will usually be better because it avoids any need for the server to load data from the DB and render the page at all. For many sites, full page cache is probably a more meaningful strategy. Setting up an object cache is more complex and usually is not something folks will set up themselves—instead, relying on whatever their host has set up.
  • @joemcgill It’s possible that the Site Health message could be improved so most site owners aren’t confused by the nuances of all these options and focus only on the things that most people can actually affect, e.g., setting up a full-page caching solution. Hosts can also modify Core’s default site health checks to give better guidance on their hardware. Possibly something to chat about with the #hosting team
  • @paaljoachim asked What can he do from the sideline? Should I mention this discussion in the hosting channel? Something else? Should I leave it up to you in this channel to followup on this?
  • @thelovekesh As the number of plugins in the PL mono-repo grows, CI times are increasing accordingly. To address this, we should update our workflows to:
    • 1. Run tests only for the plugin whose files have been updated.
    • 2. Apply the same approach for linting and static analysis.
  • This issue also impacts local development, particularly with PHPStan. While linting is fast with each commit(pre-commit hook), static analysis still runs across the entire codebase.
    • @westonruter Good idea, although there are risks for doing this when there are plugin dependencies. Like if someone changes code in Optimization Detective which Image Prioritizer depends on, then this might slip under the radar. We could specifically account for plugin dependencies

Our next chat will be held on Tuesday, September 10, 2024 at 15:00 UTC in the #core-performance channel in Slack.

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