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

Announcements

• Welcome to our new members of #core-performance
• End of Year Performance Hallway Hangout scheduled for Dec 7, 2023 at 16:00 UTC

Priority Projects

Server Response Time

Link to roadmap projects and link to the GitHub project board

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

• @joemcgill Main thing happening here at the moment is the ongoing template loading work, captured in this tracking issue
• @thekt12 Did some profiling for #58196 Performance metrics didn’t show any improvement which is kind of not what was observed in blackfire. https://github.com/WordPress/wordpress-develop/pull/5281#issuecomment-1830164940
  • @joemcgill That’s interesting. I wonder if it’s due to profilers like Blackfire not getting the benefits of the opcode cache? I can try to reproduce locally
  • @thekt12 I am not so sure about that. May be you could try and see what you observer.
  • @joemcgill Will do. I like the removal of the file_exists check and memoizing the path list regardless, so we may want to commit this anyway as a test to see if we could cache this for longer than the current request?
  • @thekt12 Yes we can do that
  • @johnbillion Last time I did some profiling with Blackfire I also saw a very different scale of improvements compared to profiling the code in PHP without it. It has a much greater overhead than I expected.

Database Optimization

Link to roadmap projects and link to the GitHub project board

Contributors: @mukesh27 @thekt12

• @mukesh27 I worked following PRs:
  • Set autoload=no for previous theme after switching themes – Ready for review
  • Set autoload to ‘no’ for previously activated themes using upgrade routine – Ready for review
• @thekt12 not a performance related thing but still something introduced by caching #59661
  • 2nd scenario in this – https://core.trac.wordpress.org/ticket/59661#comment:7 is something I feel is hard to solve, I just wanted to know do we add dev note in such a scenario.
• @pbearne Mad Idea (may not be new): Could we store all the files in site in a cache and then only check file exists if not in cache and invalidate when we fail to open a file that cache said it had and was missing
• @joemcgill file_exists checks have shown to really not be that expensive in production due to the opcode cache, but there are places where we could avoid using them and instead read the file in a try/catch block and handle the errors gracefully.
  • @pbearne I like that approach
  • @joemcgill props to @dmsnell for suggesting it a few weeks back
• @joemcgill For longer-term caching of file content that is expensive to read and parse (e.g., block patterns, etc.) this issue is worth following: #59719

JavaScript & CSS

Link to roadmap project and link to the GitHub project board

Contributors: @mukesh27 @westonruter @flixos90

• @joemcgill Last week I resolved #58632 as maybelater based on @westonruter analysis that showed that >86% of inline scripts are printed before the script they’re attached to, so making inline scripts deferrable do not seem like a priority for now. Better to document for developers how to use this feature in a way that ensures they’re not forcing their scripts to be blocking. I think we can conduct another analysis in the future to see how often async/defer scripts are being downgraded to blocking scripts due to this problem, using the data-wp-strategy attribute we add to mark intended strategy for debugging purposes

Images

Link to roadmap projects and link to the GitHub project board

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

• @westonruter Image Loading Optimization is now working end-to-end! After the pull requests for detection and storage have been merged, I’ve now got drafted a PR for the optimization piece. It’s nearing ready for review, hopefully today.
• @joemcgill I’ve got a draft of a proposal for updating our default sizes attribute in progress using the layout properties from theme.json an observation is that it would be really nice to find a more declarative way to understand the root padding values that are currently referenced in theme.json by their CSS variable names. Not sure if anyone is aware of any other conversations related to that idea that have been started elsewhere.
• @joemcgill Meanwhile, I noticed several places where Gutenberg is setting images as background CSS, where our optimizations are not being applied. That could be worth an exploration to see how we can optimize.
  • @joemcgill Some examples:
  • BG Image Support feature
  • Cover blocks
  • Media & Text
  • @swissspidy https://developer.mozilla.org/en-US/docs/Web/CSS/image/image-set Though not using background images would be nicer I think
  • @joemcgill Yeah, could be, although I think BG images are a bit easier to control when used as decorative elements and not as content, as is the case for things like cover images.
  • @westonruter cf. https://github.com/WordPress/gutenberg/pull/53934#issuecomment-1756213964 The parallax effect requires a BG image unfortunately.
• @westonruter I’m intending to target this as well with Image Loading Optimization
  • @joemcgill I can open a tracking issue in our performance repo
• @westonruter At the moment it’s just targeting img elements to optimize, but it has the pieces to also preload background images.
• @joemcgill I’m more concerned about the use of very large file sizes, but proper resource hinting would be good to handle as well
• @swissspidy Speaking of very large file sizes, I’m looking into the client-side image compression work in GB, to see what can be done for 6.5
  • @dmsnell not sure if you know libvips or not, but I noticed they have a WASM build. it’s killer feature, in my opinion, is the ability to stream image operations and avoid loading entire large images in memory at once. Also it’s just a really high quality library

Measurement

Link to roadmap projects and link to the GitHub project board

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

• @adamsilverstein I’ve been working on getting plugin checker / automated performance testing adoption, making some slow progress
• @joemcgill There was a strange issue with @mukesh27 PR earlier today. The Performance Test failed due to twentytwentyone not being available. There is a new PR running now that I’m watching to see if it also suffers from the same issue. Something we may need to triage today
  • New PR: https://github.com/WordPress/wordpress-develop/actions/runs/7021802039/job/19104724606?pr=5712
  • See Slack thread for in-depth discussion

Ecosystem Tools

Link to roadmap projects and link to the GitHub repo

Contributors: @mukesh27 @swissspidy @westonruter

• @mukesh27 working on Working on issue Implement readme parser check in trunk for Plugin Checker

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

• No updates this week

Open Floor

• @adamsilverstein I have a couple of items. First, I wanted to share this Issue on WooCommerce – https://github.com/woocommerce/woocommerce/issues/41556 which reports some compatibility issues after they moved a script to the header and used defer (originally it was in the footer)
  • … after they adopted the script strategy feature
  • some of the issues may be fixed “upstream” or they may revert the change. in any case, I think it is interesting to see the challenges large plugins like this have making a change/adopting a new approach
• @adamsilverstein 2nd: I have created a proposal for an oEmbed optimization module for the PL plugin – https://github.com/WordPress/performance/issues/888 appreciate any feedback
• @pbearne #42441 has moved on, do we need a proposal for this to go into core?
  • @swissspidy To me that ticket is the proposal 
  • @flixos90 Yeah, I don’t think it needs a proposal. Just potentially further discussion on the ticket. I left some thoughts there last week
  • @joemcgill I’d like to get feedback from more folks outside this group. I’m still personally uneasy about making this decision without more input outside this group. I’d raise it in a dev-chat at minimum

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

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