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

Announcements

• Welcome to our new members of #core-performance
• WordPress 6.4 release is today

Priority Projects

Server Response Time

Link to roadmap projects and link to the GitHub project board

Contributors: @joemcgill @swissspidy @thekt12 @mukesh27 @pereirinha

• @thekt12 working on #59314 Research showed that there is very little benefit going ahead with file_exists caching
  and it’s not easy to cache locate_block_template()
  • @joemcgill I think we can probably close #59314 as a wontfix as well, but was waiting to see what the results were of the research you were doing into replacing all of the file_exists checks in core with your PoC. Did you ever run any numbers for that?
  • @thekt12 ran into issues while doing it so stopped in between. Will try that again this week
  • @joemcgill Sounds good. I think I’ll close that ticket regardless, and if you notice that it’s worth attempting to replace the native file_exists implementation then we can open a new ticket for that.
• @thekt12 also reviewing #45601
• @mukesh27 For #59315 I ran function benchmark, which indicated a ~3% performance improvement for the function. Given this result, we recommend closing this ticket with a wontfix resolution
• @swissspidy Regarding i18n performance, still planning a blog post after 6.4 is out

Database Optimization

Link to roadmap projects and link to the GitHub project board

Contributors: @mukesh27 @thekt12

• @mukesh27 for #56912 we are waiting for @spacedmonkey feedback
  • @spacedmonkey suggest to keep it open and punt to a future release
  • @flixos90 I’m not sure about the site_icon option. I reviewed that when I looked at the ticket recently, and it’s autoloaded as far as I can tell. That’s why I am thinking there is no outstanding work to do
• @thekt12 This was already ready during 6.4, I feel this is ready to be merged for 6.5 given a second review.
   https://github.com/WordPress/wordpress-develop/pull/5295 It’s a small bug fix
  • @joemcgill I can give it a fresh look and commit it if it looks good to go

JavaScript & CSS

Link to roadmap project and link to the GitHub project board

Contributors: @mukesh27 @10upsimon @westonruter

• @joemcgill The project board still has this leftover effort for async/defer, which includes #59301. I assume that’s not something actively being worked on?
  • @westonruter correct, not a priority

Images

Link to roadmap projects and link to the GitHub project board

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill @pereirinha @westonruter

• @westonruter For Image Loading Optimization (overview issue), the initial pull request for LCP and lazy-loading detection (i.e. page metrics) has been merged into the feature branch (feature/image-loading-optimization). I’m working on the next pull request for page metrics storage which I hope to have ready for review by EOD today. With detection and storage in place, I’ll move on to applying them to actually apply the optimizations on pages.
  • @joemcgill One question I had about 878 is why you decided to register a separate post type for the storage, rather than post meta? Just curious, really.
  • @westonruter Good question. The reason is that URLs needing to be optimized are more than just singular posts, where postmeta is not available. It’s similar to oEmbed Caches in core, where we have a custom post type for that as well
• @joemcgill On a separate topic, I’ve started some initial research into ways we might be able to improve the accuracy of the algorithm we use to determine the sizes attribute that core adds to images. This could be an important optimization if we can be more accurate and potentially avoid serving larger than necessary images to site visitors.
• @westonruter On the previous topic…which relates to this, the detection logic is capturing the bounding rect for each image in the viewport, so this could feed into the sizes calculation.
  • @joemcgill Oh sure…if we could do front-end calculation of the image dimensions, the sizes attribute could be much more accurate.
• @pbearne Added Backgrounds to images got a plug by Kevin Powell https://www.youtube.com/watch?v=345V2MU3E_w&ab_channel=KevinPowell

Measurement

Link to roadmap projects and link to the GitHub project board

Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy @flixos90

• @swissspidy My intro blog post about performance testing should be ready soon, just needs some final polish
• @swissspidy Opened a PR to expand core performance tests to cover localized sites, wp-admin, and memory usage
• @adamsilverstein One small update from Drupal land where they have been working on a similar effort to add automated performance testing… They recently landed their first test collection piece in core with data going to Grafana – https://www.drupal.org/project/drupal/issues/3391689
• @flixos90 I am looking at metrics (mostly field) a lot these days, for visibility I am resharing the TTFB impact analysis I conducted: https://wordpress.slack.com/archives/C02KGN5K076/p1698947714789279
  It begs the question how much WordPress core is in a position to affect TTFB in the field, vs how much TTFB is impacted by other factors outside of our control (e.g. hosting stack, network connection etc.)
• @joemcgill I’ve spent a lot of time over the past week getting into the weeds of how we’ve been benchmarking WP versions, in preparation for the 6.4 release. It’s been a helpful exploration and we’ve made improvements to the https://github.com/swissspidy/compare-wp-performance workflow and added the ability to add variance statistics to the benchmarks taken by our benchmark CLI tools. I’ll write up some more details and add them to the conversation in https://github.com/WordPress/performance/issues/849
• @flixos90 I am also researching a couple other things related to our team’s potential impact on CWV through LCP, e.g. given we have mostly spent time on improving LCP, how much would that allow us to improve overall CWV passing rate of WordPress sites? And the same for TTFB (which, spoiler alert, seems to be a major bottleneck for TTFB)
  • @flixos90 I am going to prepare some of those stats to be a bit more presentable, but from what I am seeing so far, it seems that improving TTFB by let’s say 40% (which obviously is a very ambitious goal) would improve the actual LCP passing rate from the current ~40% to ~60%, which would be huge. Note that ~60% is also the current LCP passing rate of all non-WordPress sites in the HTTP Archive / CrUX dataset. So is TTFB our main issue in WordPress?
  • @flixos90 It would certainly make sense, since TTFB is the metric with the lowest passing rate for WordPress sites. So this probably isn’t even news, but I think it’s a good other angle to look at the situation from. Improving TTFB would have major impact on LCP, and that would then have major impact on CWV. But easier said than done

Ecosystem Tools

Link to roadmap projects and link to the GitHub repo

Contributors: @mukesh27 @swissspidy @westonruter

• @mukesh27 for the Plugin Checker
  • Add link to Plugin Editor for each found issue to jump user to file and line of code – Merged 
  • Improve behaviour for single-file plugins – Ready for review 
  • Add missing @since annotation – Ready for review
• @swissspidy Regarding Plugin Check, I added support for a new --exclude-checks CLI option, which is now already available via the Plugin Check GitHub Action as well.

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

• @10upsimon I am iterating on the PR to have it ready for re-review by end of the week

Open Floor

• @pbearne I was  on a client site last week and noticed that there was a load of get_options calls to missing options each taking 0.002. I wonder if we could work out a way to return early
  • @joemcgill Do these not get picked up by the not_options cache? Or did that not apply in this case?
  • @pbearne didn’t seem to be so, filled up the queries
  • @joemcgill get_option should add any not found option to the cache here, unless there is a bug that causes it to get skipped. If the site isn’t using a persistent object cache and it’s only called once, then that optimization won’t really matter, but otherwise it should.
• @dmsnell I started working with someone to work on running the Gutenberg E2E suite against the Playground with Core’s trunk. My schedule was a bit off because of a meetup we had a couple weeks ago and a small vacation I took afterwards.

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

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