@spacedmonkey I would love some feedback on https://core.trac.wordpress.org/ticket/56990
@10upsimon Enhancing The WP Scripts API 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 Beta 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.

Images

Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

@flixos90 I have been reviewing the fetchpriority support PR https://github.com/WordPress/wordpress-develop/pull/4495 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

Measurement

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 plugin 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 tag over a link tag with an external request. This saves a http request and faster because of none blocking requests.
- I am going to create a ticket 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: https://github.com/WordPress/gutenberg/issues/41479#issuecomment-1522427602