Performance Chat Summary: 6 June 2023

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


Priority Projects

Server Response Time

Link to roadmap projects

Contributors: @joemcgill @spacedmonkey @aristath

Database Optimization

Link to roadmap projects

Contributors: @aristath @spacedmonkey @olliejones @rjasdfiii

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. & CSSCSS Cascading Style Sheets.

Link to roadmap project

Contributors: @mukesh27 @10upsimon @adamsilverstein

  • @spacedmonkey I would love some feedback on
  • @10upsimon Enhancing The WP Scripts APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. with Loading Strategy continues to progress nicely:
    • Continued work on better handling of deferred inline scripts to be strict CSP compliant (in final stages of review)
    • Ongoing work against core PR related to script strategies and the script dependency tree
    • Re-visitation of documentation updates required following recent changes to the body of work introduced via a handful merged PR’s
  • @joemcgill Re Script Loading API: The aim of the current approach is to fully support the Script Loader API, including attached inline styles, while maintaining loading order for backward compatibility so that current blocking scripts can more easily adopt one of the more performant loading strategies. Even though the PR now meets CSP best practices, there is still disagreement about whether this should be included. @westonruter is finishing up some improvements that should finalize the “full” approach. Meanwhile, I’m prepping a path to remove delayed inline handling in order to unblock the main functionality from being committed prior to BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1.
    • Latest delayed inline scripts approach is happening here
    • Issue to remove delayed inline support for a core merge (if needed) is here
    • I think the main question is whether we end up merging the full implementation or a reduced scope version while continuing to decide on the right approach for supporting inline scripts attached to async/defer scripts.


Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

  • @flixos90 I have been reviewing the fetchpriority support PR that @thekt12 has been working on. It’s getting close to the finish line in terms of core implementation. Once that is sorted out, we’ll have to make sure tests pass and add test coverage for the new functions
    • So that’s not quite ready for a full review yet (mostly due to tests), but feel free to take a look at the main code already


Link to roadmap projects

Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27

  • @joemcgill No new updates on automated tests, but we’re hoping to add some documentation about how to perform measurements to the Performance Team handbook in the coming weeks (maybe even in time for contributor day at WCEU)

Ecosystem Tools

Link to roadmap projects

Contributors: @joegrainger

  • @joegrainger For the Plugin Checker, we have completed Milestone 1 and started working on the second phase. This is implementing the initial checks that will be part of the plugins first release. You can follow the progress on the GitHub repo here. Thanks!

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

  • @flixos90 Still awaiting approval of the Dominant Color Images pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party in the plugin repo

Open Floor

  • @spacedmonkey One thing I want to look into after WCEU, is inlining styles. WordPress has ability to inline styles since 5.8. Functionality was added in 5.8 for block styles. But there are other small styles that use this improvement.
    • If you don’t know, in-line styles means outputting css inline in a style tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) over a link tag with an external request. This saves a httpHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. request and faster because of none blocking requests.
    • I am going to create a ticketticket Created for both bug reports and feature development on the bug tracker. and I will share it on this channel if anyone is interested.
    • I also want to document this functionality better for plugin / theme developer are aware of it and start to use it.
    • @10upsimon Curious to hear your thoughts/opinion on potentially also supporting deferred styles @spacedmonkey I know this has come up once or twice in discussions relating to the script loading strategy work. Is this something you feel is worth exploring? Critical CSS is generally inlined, but I feel that non critical css could benefit from deferral in certain situations?
    • @spacedmonkey This is something the team at XWP was looking into a while back. There is a benefit, but you have to know what you are doing. For many plugins and themes, it hard to know when a style is needed. Adding this functionality into core makes sense to me and should works the same way as deferring scripts works.
    • @westonruter Perhaps only feasible to have an API for plugins and themes to register styles that should be delayed.
    • @spacedmonkey The developer api should be the same imo
    • @westonruter Doesn’t seem feasible to do it automatically
    • @10upsimon Certainly would have to be opt-in
    • @joemcgill Finding use cases to defer styles from core would be very helpful to justify a first-party API support
    • @spacedmonkey On a similar note, block themes have ability to load on block styles for blocks core knows are on the page. Would love somehow if that functionality came to classic themes as well. Maybe by parsing all blocks before headers are sent…
    • @westonruter Block themes could actually open up possibilities for automatic delayed styles, come to think of it. If we can determine the blocks that would be in the first viewport, then block styles identified for the page but below the first viewport could be delayed (basically ditto Jonny)
    • @spacedmonkey I haven’t pushed for defer styles as I wanted to see deferred scripts in first. Once scripts is in, we should work on style defer. Even if it is just for constancy
  • @joemcgill Want to make sure that we’re keeping an eye on the performance impact of the new Fonts API that is being worked on for 6.3 in the Gutenberg repo see:

Our next chat will be held on Tuesday, June 13, 2023 at 15:00 UTC in the #core-performance channel in Slack.

#core-performance, #performance, #performance-chat, #summary