Performance Chat Summary: 10 October 2023

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

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

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

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

Leave a Reply

Your email address will not be published. Required fields are marked *