Meeting agenda here and the full chat log is available beginning here on Slack.
Announcements
Priority Projects
Server Response Time
Link to roadmap projects
Contributors: @joemcgill @spacedmonkey @swissspidy @thekt12 @mukesh27
- @joemcgill Everything planned for 6.4 has been resolved. I’m keep an eye out for issues that come up during the last week of beta and RC. Otherwise, am beginning to start focusing on opportunities for 6.5, like Improving Template Loading and Improvements to the way block widgets are registered (ex: #55595)
- @spacedmonkey
- @mukesh27 #59360 to be committed today. It was reopened for some concern that I’m looking into right now
- @swissspidy Performant Translations is doing well. There are already PRs and tickets for all the relevant areas this touches. I’m working on further simplifying the plugin & core patch. Once 6.4 is released we can continue with the next steps for a 6.5 merge.
- @flixos90 I would like to flag this Slack thread – just spotted this literally 5 minutes ago, but it looks like the most significant performance fix for TT4 caused a bug, which now with the fix for that bug effectively may have reverted almost all the performance benefit
- In my benchmark yesterday, TT4 was about ~10% slower than TT3. Now it’s again ~25% slower
- @spacedmonkey to re-open #59541 to see if it helps
- @joemcgill to run some profiles, but assuming it’s due to
parse_blocks() being called way more often.
- @thekt12 I have picked up https://github.com/WordPress/performance/issues/746 (just a while ago), checking through tickets that are still left
Database Optimization
Link to roadmap projects
Contributors: @spacedmonkey @mukesh27 @thekt12
JavaScript & CSS
Link to roadmap project
Contributors: @mukesh27 @10upsimon @westonruter @spacedmonkey
- @westonruter Yesterday I committed the removal of
unload event listeners and use of pagehide and pageshow where appropriate for #55491 . In the best case this will improve performance by allowing bfcache to speed up page navigations. But as I mentioned before, bfcache is also disabled when Cache-Control: no-store is present, and this was added to all authenticated page requests in 6.3 with #21938. Lastly, the heartbeat script is only used on 0.25% of HTTP Archive pages (which would be unauthenticated). So in practice the performance benefits will be marginal. Nevertheless, the unload event is unreliable so the change is an improvement regardless. - @adamsilverstein I have been working on adoption of the script strategy feature with plugins and have been having some success. Its great how easy it is to layer on the new API without breaking old use cases (especially using `wp_script_add_data`). One potential issue I have discovered that could cause regressions has to do with dependencies and the footer attribute.
- Here is the scenerio:
- Popular plugin “Plugin A” currently enqueues a script on the front end, using `in_footer` => true, so the script is essentially non blocking
- To get a slight performance gain, in WP >= 6.3 the plugin changes `in_footer` to `array( ‘strategy => ‘defer’ )`. Great, now the script is in the header so it can be discovered slightly earlier, and it is marked as `defer` so it is non-blocking.
- Now… along comes “Plugin B”, they enqueue a script that depends on the script from “Plugin A”, and they still use `in_footer => true`. Now the script from “Plugin A” can no longer be deferred, so it is not – however it remains in the header. The result: we now have a new blocking script in the header.
- I wonder if we had considered this during the design? Maybe in my scenario I should instead use `array( ‘strategy => ‘defer’, ‘in_fooer’ => true )`
- @flixos90 I think opening a ticket would be good. If a script has
defer, it should always be fine to load it in the footer (since with defer it only loads after the DOM anyway). So I think that would be a good fix: If a script is in the head and its defer is forced back to blocking, move it to the footer - @adamsilverstein I was thinking that also, but it might have other implications…Also in my testing I noticed that in_footer already has some dependency behavior built in that can move scripts to the header:
Script A is marked for the footer. If script b depends on script a and is marked for the header, script a also gets put in the header - @10upsimon That makes sense @flixos90 I think we only never did that because by design you’d only usually have deferred in the header, generally, correct?
- @flixos90 Not sure, I don’t remember us ever thinking about the head vs footer implication of a deferred script being forced back to blocking. So we may just have missed that consideration. To me what @adamsilverstein pointed out above is something we should be able to fix in a rather straightforward way
- @adamsilverstein yea, I don’t think we considered that exact scenereo, I came across it trying to implement/use the feature
- @flixos90 I think the latter has been the case forever, so that wouldn’t be a regression
- @joemcgill We could do some analysis of how many registered deferred scripts end up in the head, since we added some data attributes to track that sort of thing
- @westonruter We don’t currently capture whether a script was originally registered with
$in_footer in the data attributes like we do with the script strategies though - @flixos90 FWIW I cannot see any concerns with moving a
head defer script to footer from a functional perspective. In both cases it would be loaded after the DOM. Not sure how important the impact research would be for that bug specifically - @adamsilverstein to open a ticket to discuss further
Images
Link to roadmap projects
Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill @pereirinha
- @joemcgill I’m planning to follow up on two things we’ve discussed, related to improving how WordPress calculates the
sizes attribute. - @adamsilverstein I’ve been testing the fetchpriority attribute and wanted to raise some potential issues. First: I created a simple plugin that adds an advanced image control that lets users set the fetchpriority manually for individual images – https://github.com/adamsilverstein/wp-fetchpriority-control
- Noticed a few edge cases with our approach in testing –
- putting images in columns in GB resizes them but only with styles (?) so we still apply fetchpriority – https://wp-sample-pages.instawp.xyz/another-test/ — note that the thumbnail in the first row gets the fetchpriority=high which is probably incorrect
- repeating the same image three times means all three will get the fetchpriority attribute – because our processing tries to skip re-processing duplicate images – https://wp-sample-pages.instawp.xyz/test-post/
- manually setting the fetchpriority for an image causes core to skip it (not change it), but it then applies the attribute to the next image, In this test, I applied fetchpriority=”low” to the first image, and fetchpriority=”high” to the large image below the thumbnails. Core aded the fetchpriority=”high” to the second thumbnail image – https://wp-sample-pages.instawp.xyz/with-manually-set-high-and-low/. If core finds existing fetchpriority=high tagging it should probably avoid adding its own.
- I think these are all addressable in some form and the first may already be covered by an existing ticket; I’ll plan to open tickets for further discussion
- @flixos90 I opened a new ticket yesterday for a recently found limitation of
wp_get_loading_optimization_attributes() when it comes to images in block templates #59577 that affects TT4 - @pereirinha I’m looking for good candidates to pick up, but nothing yet. Happy to assist here.
Measurement
Link to roadmap projects
Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy @flixos90
- @flixos90 Nothing from my end, other than running benchmarks on several tickets this week
- @mukesh27 Planning to run benchmarks for beta 3 tomorrow.
- @swissspidy Continuing working on documenting ways for improving the core performance test setup & reducing test variance. Nothing concrete right now
- @joemcgill Another thing we’ve been discussing for the past few weeks is how to improve the confidence we have in our benchmarking setups. Many of us have been using an automated script that @swissspidy put together to run benchmarks for each release, and we’re getting consistent numbers, but those numbers are showing much bigger performance gains than what @flixos90 has been reporting with his local setup. I’m planning to dig into this a bit more today. @swissspidy I saw that you’re making good progress on converting performance tests to Playwrite. Anything we can help with there?
Ecosystem Tools
Link to roadmap projects
Contributors: @mukesh27 @swissspidy @westonruter
- @mukesh27 For the Plugin Checker: PR Add
Trademarks_Check 285 – Ready for review
Creating Standalone Plugins
Link to GitHub overview issue
Contributors: @flixos90 @mukesh27 @10upsimon
- @10upsimon No major updates from me at the moment, I did decide to refactor some code to be more WordPress’y when it comes to the standalone plug-in card rendering within WPP settings screen, so I’ll open said PR for standalone plug-ins UI soon, via a feature branch.
Open Floor
- @spacedmonkey I am changing roles ( I am leaving XWP ). I will not have sponsored time to work on this project. So as of the end of this week, I will be stepping down from this project. That means I will not be around to answer questions or code review. If you need anything, please message me before the end of the week.
Our next chat will be held on Tuesday, October 17, 2023 at 15:00 UTC in the #core-performance channel in Slack.
#core-performance, #performance, #performance-chat, #summary