- Blog post was published outlining the WordPress 6.2 server performance analysis summary to identify the biggest opportunities to target for future performance enhancements
- All the lazy-loading PRs were committed last week
- Notable inclusion in 6.3 #58394 resulting in ~7% faster block themes and 2% faster classic themes (full results)
- FWIW, this was one of the issues identified in the server performance analysis, so it’s really nice to see it already being addressed.
- @swissspidy committed two minor changes to i18n that slightly improve performance in some cases:
Server Response Time
- @joemcgill Other than the analysis already posted, I don’t have any further update, other than wanting to identify some epics out of that work that we can start to take action on.
- No updates this week
- @10upsimon Enhancing the Script API with a loading strategy update:
- Most of the core PR feedback items that are unrelated to the topic of defer/async dependencies and inline scripts have been addressed.
- Actioning of remaining points of feedback are largely pending the outcome of a final strategic decision around handling deferred and async dependencies, and inline scripts attached to defer/async scripts.
- Discussions around how best to solve the above are ongoing, with POC’s currently being developed.
- @joemcgill For the initial design for this feature, we intended to support all current use cases that the Script Loader supported, including support for inline scripts when added to a script handle. @westonruter and @10upsimon have been making good progress on improving that implementation, and it would be useful to have the proposed iteration completed, even if we decide to remove those enhancements for the initial commit.
- However, I think we’re close to needing to make a decision about what belongs in the initial commit and what can be left for further iteration. Hopefully we can finalize those decisions this week.
- @joemcgill this week @thekt12 has made good progress on adding
fetchprioritysupport with help from @flixos90. Iterations there could use more eyes as he continues to make progress https://core.trac.wordpress.org/ticket/58235
- No updates this week
- @joegrainger For the Plugin Checker, we are working on the final iterations on the last issue for Milestone 1. Once complete, we will start work on the second phase which will be implementing the initial checks that will be included as part of the plugins first release. You can follow the progress on the GitHub repo here. Thanks!
Creating Standalone Plugins
- @joemcgill Until we have all of the modules published as standalone plugins, we’re blocked on the eventual removal of those modules being bundled with the plugin, which is still the plan.
- @mukesh27 We already release two plugins can we start removing those from PL?
- @joemcgill We can start working on the process, but I think we’ll wait on a PL release that removes all of them until we’ve got the UI and migration path really figured out.
- @mukesh27 Is there any way to get approval for Dominant Colour Images as it blocks Milestone 2 work?
- @joemcgill Nope. Just wait our turn in line, just like all the other plugins
- @flixos90 I think the main priority beyond waiting for the approval is to scope out what we want the user experience for Milestone 2 to be like. We then have to implement that and ship it to allow users to migrate before we actually remove the modules
- @joemcgill Agreed. And, admittedly, a lot of us have been focused on landing some priority features from our roadmap early this release cycle
- A question was posted against the agenda this week asking if we can take a look at https://core.trac.wordpress.org/ticket/49278
- @joemcgill From a quick read of that ticket, it sounds like @peterwilsoncc and @costdev previously determined that the current patch still needs some work before it’s ready to land in core.
- Not sure if @markparnell is interested in picking this back up, or someone else, but it would need to be ready for another review pretty soon if we wanted to land it in 6.3.
- Query before (38 seconds)
- Query after (0.0028 seconds)
- The improvement is significant as per the ticket description
- @joemcgill Meta queries are a complex part of the API and needs to be handled with care. There are times with meta queries that optimizations are proposed where really the design of a WP_Query needs to be reconsidered (not sure about this case).
- There are many other proposals in Trac tickets that are focused at improving performance of meta queries as well, like adding an extra index to core, etc.
- @spacedmonkey Any change would need a lot of unit tests. Unit tests for all query classes. So post, term, comment, site and user.