- Team rep nomination reminder, please add your nominations for Performance Team Rep by Friday, February 24 2023
- Next steps on sharing the public roadmap for 2023 now the GitHub issue has been closed
- Next steps on creating standalone plugins [summarized in this GitHub issue]
- The performance team received feedback from Matt and Josepha regarding the 3 approaches in this comment
- @flixos90 As such, we should move forward with option 2. While that’s not the same option we initially voted for, I think that’s still a great option, and it’s great that we now have a clear path forward
- As mentioned before, Option 2 is technically a bit more work than Option 1, but it effectively includes the work we would need to do for Option 1 as well. So I think it makes sense to do this work in two stages
- @flixos90 has opened a couple of follow up issues as well as this overview issue to keep track of all the work: https://github.com/WordPress/performance/issues/656
- Call to please review and share any ideas or feedback you have on GitHub (either in the overview issue if it’s high level feedback, or on the specific issues if it’s a more concrete feedback regarding one of the tasks)
- The idea is that for milestone 1, which is already fairly well defined, to get it across the finish line by end of March
- So at that point we would have the standalone plugins available already, which is a big step regarding the overall effort
Focus area updates
- @adamsilverstein out this week following WC Asia
- @tillkruess we’ve been working on a few Trac issues around object caching
- See above
- Needs Discussion (5 issues)
- @joegrainger we are working towards completing the infrastructure for the Plugin Checker over the coming weeks. Once done we will reach a major milestone where we’ll have a working plugin running with some initial checks. You can see progress on the GitHub repo here. Feel free to leave any thoughts/ideas you may have in that repo too.
- @joemcgill sharing on behalf of @mukesh27 who is out for WC Asia
- he is very close to having the automated performance measurements workflow implementation for WP Core ready to share. There is one new requirement that needs to be addressed, which we discovered when coordinating with @youknowriad about logging data with the dashboard he’s set up at https://www.codevitals.run/project/2. Hoping to have that wrapped up later this week.
- @joemcgill Also, I opened an initial draft PR for adding XHProf support directly in the
wp-envpackage. I’m planning on making updates to that approach this week that would simplify setting up XHGui for analyzing profiling data, but am already able to use this setup to do profiling of WP, which has been useful in testing for possible regressions in 6.2.
JS & CSS
- No updates
- @olliejones work proceeds on the SQLite integration
- @clarkeemily spotted a few new issues added recently re. SQLite integration which I added to the
[Focus] Databaselabel [see here]
- @joemcgill There were also a few issues that came up during the Performance Lab release party yesterday, that I wanted to make sure we get added
- @flixos90 No updates from my end, other than the news I already shared about creating standalone plugins and unbundling the Performance Lab plugin, and that version 2.0.0 was released yesterday
- @olliejones The drop-in method of loading run-early code is reaching the limit of its flexibility. And the workarounds are, imho, too brittle to release broadly; they’ll drive site owners ’round the bend.
- A lot of this performance work will depend on run-early code. Can we imagine a more extensible way of handling it that will work better when, say, 50% of all sites use SQLite, and they all use other drop-in activated features?
- It will likely take some sort of core change to improve this corner of WordPress. What’s the process for working out all that stuff?
- It might be as simple as modifying the mu-plugin load order so some of them load early.
- @joemcgill I think it’s a great question, and one that we could begin thinking about by focusing on examples of where the current functionality of WP is limiting our ability to deliver the kind of user-facing improvements we’re trying to make. If solving an underlying architectural issue unblocks a whole lot of other improvements, then I think it’s worth prioritizing, but hard to say without concrete examples.
- @olliejones the following come to mind:
- Collisions between the performanceServer timing part of PL and various persistent object caches.
- Collision between Query Monitor and the SQLite integration
- And, conceptually it should be possible to run both Query Monitor and SQLite integration, and activate/deactivate them in whatever order the site owner wants. (except obvs deactivating SQLite on a install that uses it would break it.). The same logic applies to object caching.
- @olliejones to create an issue to capture next steps here
- @joemcgill flagged a critical issue to address this week https://core.trac.wordpress.org/ticket/57150