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

Announcements

• Release the Performance Lab plugin 2.1.0 yesterday

Priority Projects

Server Response Time

Link to roadmap projects

Contributors: @joemcgill @spacedmonkey @aristath

• @spacedmonkey I have been working on profiling translations and looking into how we can make them faster
• @joemcgill working with @spacedmonkey on comparing notes this week on some initial profiling that we’ve done. I’m still struggling a bit to write all of this up in a shareable way, given that I’ve got one arm in a sling, but we should have some good progress to share by next week.
• @spacedmonkey committed the following issues
  • Posts, Post Types: Use WP_Query internally in get_pages
  • Date / Time: Remove usage of mysql2date in generate_postdata method
• @spacedmonkey On autoloading, I did some quick profiling on it and a seeing slower performance after the change. Around 5ms on a home page view.
  • @flixos90 Yeah that covers roughly with benchmarks I had done a few months back
  • @spacedmonkey I tested this – https://github.com/WordPress/wordpress-develop/pull/3470 There maybe benefits for other requests types, like REST APIs
  • @flixos90 Autoloading is tricky. There is probably some memory benefit of not loading as much PHP code, but we’ll have to assess the performance impact more. Of course autoloading is a good practice, but we also need a good argument to support getting this into core. And if it actually slows down server response time, I would say we shouldn’t push it. But more research needs to be done.

Database Optimization

Link to roadmap projects

Contributors: @aristath @spacedmonkey @olliejones @rjasdfiii

• @spacedmonkey I have been working on
  • Only load post thumbnails if present in response
  • Use wp_cache_get_multiple in fill_descendants
  • @joemcgill let’s move these tickets to the 6.3 milestone

JavaScript & CSS

Link to roadmap projects

Contributors: @mukesh27 @10upsimon @adamsilverstein

• @10upsimon gave his update on Enhancing the Scripts API with a loading strategy ahead of time
  • Engineering for the epic as a whole has been completed and is in round 1 of code review and iteration – work can be seen here. We anticipate an iterative feedback and implementation loop to continue into next week, followed by a full and final code and functional review of all work by EOW next week, thus concluding engineering and being in a state to consider and implement a core merge proposal mid-April.
  • A developer testing plan is currently in review, which aims to support testing efforts of all engineering work carried out. This includes validation of all unit tests introduced as part of said work, and defines functional testing approaches, of which popular WordPress themes and plugins are included as part thereof.
  • An approach for documentation (automated/code reference & community) has been discussed and is soon to be executed. Draft documentation items will be produced for review, with the aim of being released as soon after the core merge as possible.

Images

Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

• @adamsilverstein I have an update about the image comparison game/study I ran at WordCamp Asia. In the game people compare two images generated by WordPress to the original uploaded image. The image quality setting between the images varies and the format changes as well, so far I’m testing with WebP and JPEG and quality settings from 70 to 90.
• @adamsilverstein Here is a doc with a summary of the results and a bit of analysis as well as a link to a sheet with the raw data:
  • To summarize the results though:
    • People loved playing the game and also became super engaged about images
    • We didn’t gather enough data to have statistically meaningful results
    • Anecdotally, most people struggled to tell which image was closer to the original
• @joemcgill I’m starting a high-level review of our approach to calculating the sizes attribute for images in WordPress this week. It’s the first step for me to work on ways we can improve some of the base assumptions that the current approach takes and see if we can improve it now that we have more information and block themes.
• @flixos90 I have been researching the remaining problems with lazy-loaded LCP images, with some good findings. I should have something to share in a week or two. Likely this will be in form of a few new Trac tickets with things we should fix. It’s worth noting that still more than 20% of LCP images today are being lazy-loaded with the loading attribute. This is where WordPress core can help.
  • (Additionally ~10% of LCP images today are lazy-loaded through other custom JS technologies, so that’s something where plugins and libraries will have to do the work. Maybe something we can help facilitate)

Measurement

Link to roadmap projects

Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27

• @joemcgill Automated performance timing continues to be collected and was useful while reviewing potential performance regressions during release candidates for 6.2. We are starting to put some thought into what the next improvements should be. If anyone has specific ideas they think should be considered, I’d certainly love input. Will share some ideas in the coming weeks.
• @adamsilverstein I wanted to link to a Drupal ticket where their  team is working on adding automated performance testing for Drupal  core: https://www.drupal.org/project/drupal/issues/3346765. The approach they are taking is quite different, with a plan to store performance traces using a tool like Open Telemetry or “jaeger” (new to me) – although they are starting more simply like we have. I feel like it is worth following their effort as we can always learn from each other

Ecosystem Tools

Link to roadmap projects

Contributors: @joegrainger

• @joegrainger We are working on the final elements on the Plugin Checker infrastructure with plans to complete this by the end of the week. From next week we’ll be performing initial testing and review of the infrastructure before working on the additional checks. Progress as always can be seen on the GitHub repo here. Please feel free to take a look and leave any thoughts/ideas you may have in the repo.

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

• @mukesh27 working with @10upsimon continue to work on Milestone 1 tasks for Creating standalone plugins, and we are near to complete engineering soon. If anyone has some time, then review PR at https://github.com/WordPress/performance/pulls?q=is%3Apr+is%3Aopen+label%3A%22Creating+standalone+plugins%22 and share the feedback.
• @clarkeemily we’re aiming to complete engineering of Milestone 1 issues by end of next week
• @flixos90 The idea is to publish the WebP standalone plugin first, essentially to test that everything is working as expected. If we need to fix something, at least that way we’re only messing with one plugin instead of 4
  • Once we’ve established the publishing workflow functions as expected, we’ll publish the other standalone plugins

New Projects / Proposals

• A polite reminder, our 2023 roadmap is intentionally broad. Despite there being clear workstreams envisioned within the highlighted priorities, the team aims to support contributors with additional related ideas

Open Floor

• n/a

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

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