Performance Chat Summary: 12 September 2023

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

Table of Contents

Toggle

Announcements

Welcome to our new members of #core-performance

Priority Projects

Server Response Time

Link to roadmap projects

Contributors: @joemcgill @spacedmonkey @aristath @swissspidy @thekt12 @mukesh27

@spacedmonkey
- Ready for review
  - https://github.com/WordPress/wordpress-develop/pull/4460
  - https://core.trac.wordpress.org/ticket/58329
- Working on
  - https://core.trac.wordpress.org/ticket/59310
- Committed
  - https://github.com/WordPress/wordpress-develop/commit/bd594f72a83e0512d60aec5436ab653ed5966678
@thekt12 I have addressed #58682, got some initial review changes. I’ll commence my work on #58319
@mukesh27 Working on #22192, PR is ready for review https://github.com/WordPress/wordpress-develop/pull/5139/
@flixos90 I left a comment on https://core.trac.wordpress.org/ticket/55996#comment:39 yesterday that I would like to get other people’s thoughts on. Revisiting that ticket, I’m not sure the original direction is really where we want to go
- @spacedmonkey Code reviewed the draft PR. The biggest issue is the name of the filter as that is already used
@flixos90 I also implemented two proof of concept PRs with alternative ways to address some of the related problems
@joemcgill Last week, I updated the overview ticket we had in the performance repo for improving template loading and created two new tickets, #59314 and #59315 related to that work. Right now, our team has a lot already in progress for the 6.4 milestone, and with it being a shorter release cycle, I’ve moved those two tickets to future release, but would like to prioritize them earlier. If anyone ends up having capacity to work on them during this milestone, I think we could consider moving them in.
@joemcgill I’m planning on taking another swing at #57789 this week, with the intent to try to make the changes in the Gutenberg plugin prior to getting them into core, as discussed originally with @oandregal
- @spacedmonkey I am worried about making that cache persistant. It hard to know when the theme.json file has been updated? What if someone ftp updates the file? A lot of the WordPress code base guess that files could change. But many hosts lock this down, like VIP GO. I wonder if we could have a new flag to say that files cannot be updated
- @joemcgill That’s part of what needs to be solved. There are several cache invalidation issues that need to be addressed, but honestly, the FTP use case is a lower concern for me so long as any persistence is flushable. I think anyone who is manually updating files is already needing to run cache flushes as a part of their workflow at times.

Database Optimization

Link to roadmap projects

Contributors: @spacedmonkey

@spacedmonkey
- Ready for review
- Committed
  - https://github.com/WordPress/wordpress-develop/commit/827a560adef5e5f1d9fea1788b58aab9c4752a10
  - https://github.com/WordPress/wordpress-develop/commit/e619082f8ab3f5054158395be291071e20366691

JavaScript & CSS

Link to roadmap project

Contributors: @mukesh27 @10upsimon @adamsilverstein @westonruter

@westonruter [Committed] (https://core.trac.wordpress.org/changeset/56556) use of the `defer` loading strategy for bundled themes. See #59316
@spacedmonkey In need of review https://github.com/WordPress/wordpress-develop/pull/4824
@10upsimon No updates from my side on this one at present, but I do wonder if we need to exercise due diligence and reach out to some of the larger orgs like WP Engine around “bad” docs on deferred/async script implementation especially as it will break fully once we solve the manual construction of script tags. Specifically, this documentation page: https://wpengine.com/resources/defer-parsing-javascript-wordpress/
- Tagged @adamsilverstein in this comment
@westonruter To this end, the PR for elimination of manual construction of script tags needs feedback. Ticket: https://core.trac.wordpress.org/ticket/58664 I’m thinking the scope should be reduced to just the frontend, leaving the admin for a future release

Images

Link to roadmap projects

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

@spacedmonkey In need of review https://github.com/WordPress/wordpress-develop/pull/4797 – This PR just needs testing and CR. Be a nice simple one to get into WP 6.4
@flixos90 I’m looking for feedback/review of https://github.com/WordPress/wordpress-develop/pull/4973 which I updated last week. Also see https://core.trac.wordpress.org/ticket/58853
@pereirinha I had a sync yesterday to flush out https://core.trac.wordpress.org/ticket/58892. I think I’m set for success now
- as for https://core.trac.wordpress.org/ticket/58893 I did open a PR and there’s some feedback already. But I haven’t had the chance to loop back.
@mukesh27 I’m working on #58894

Measurement

Link to roadmap projects

Contributors: @adamsilverstein @joemcgill @mukesh27 @swissspidy

@joemcgill Pascal recently updated the Performance workflow to show the relative change of a specific PR compared with the trunk, which will show in the action summary. (example)
- I think there’s still some room for us to improve the understandability and accuracy of those tables, but this is a much easier way to spot performance issues at a glance on PRs. Should be really helpful for reviewers

Ecosystem Tools

Link to roadmap projects

Contributors: @mukesh27 @swissspidy @westonruter

No updates this week

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

@10upsimon Arrived at a working UI for managing standalone plugins within the WPP settings screen
- Transitioning to issues related to the migration aspect, i.e raising correct admin notices, enhancing the UI within the WPP settings screen to be more indicative of what current active modules have standalone plugins that should be activated instead, and so on.
  - @flixos90 Regarding the second point, not sure at what stage that exploration is at, but I think it would be great for the first PR to be only about the general UI, without the migration aspects, to limit scope