Meeting agenda here and the full chat log is available beginning here on Slack.
- Proposal for using
fetchpriority to enhance LCP image performance published
Server Response Time
Link to roadmap projects
Contributors: @joemcgill @spacedmonkey @aristath
- @spacedmonkey: Committed  and 
- @spacedmonkey has been working on #58196
- Could have the possibility to have 6-10% of server time for block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. themes
- @flixos90: There are some conflicting metrics on that last one. We have to figure out why your metrics show such good values while mine don’t show any notable change. I tested with 6.2 (not
trunk) and didn’t see any performance impact
- @spacedmonkey: I think it related to changes in trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.
- @johnbillion: The ticket Created for both bug reports and feature development on the bug tracker. is now about adding caching (see new comment and new PR)
- @spacedmonkey and @flixos90 to follow up with additional benchmarks to determine why the benchmark results differ so much
Link to roadmap projects
Contributors: @aristath @spacedmonkey @olliejones @rjasdfiii
- @spacedmonkey plans to commit lazy loading of comment meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. everywhere, today or tomorrow
- All other types, like user and post meta are so heavily used ( user meta == capabilities and post meta, post thumbnails ), that it not really worth lazy loading it
- @xavivars had a couple of comments regarding the SQLite integration
- @xavivars: I know it has been discussed previously that this may not be a “performance” project, but only something related to the work here, so not sure if this is the relevant forum for that, or there’s a better place for it
- @flixos90: Yes, just to recap the above conversation from last week: The SQLite plugin 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party / PL module will going forward no longer be directly associated with the performance team. We’ll still be supporting the project, but it will be decoupled from the
WordPress/performance repository and the Performance Lab plugin
- @flixos90: Probably best to raise in the plugin’s GitHub repository
- @xavivars: It may be worth to remove it from https://make.wordpress.org/performance/roadmap-2023/#category-database-optimization (or make that decision explicit in the roadmap)
- @flixos90: Good point. Let’s raise that again next week when more people are around to discuss. Maybe we could change it to support the project rather than driving it, or something like that.
Link to roadmap project
Contributors: @mukesh27 @10upsimon @adamsilverstein
- @flixos90 would like to share that there is now a pull request for the new script loading strategy https://github.com/WordPress/wordpress-develop/pull/4391
- @westonruter: In that pull request for Script Loading Strategies, identified what may be missing support for
async scripts having dependencies. I put together an Async Library Script Loading Demo that demonstrates how
async scripts could indeed have dependencies. So I’d like it if anyone could affirm my findings for the need for
async scripts to be able to have dependencies/dependents. Feel free to just comment on the PR. Since 10up is not here, it doesn’t make much sense to chat about it right now.
- @flixos90: I’ll have to take a closer look. Let’s continue discussing, but I’d like to note that this could also happen in a separate follow up enhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.. It depends a bit on how complex it is and how much it increases the scope of the current effort I’d say. We can always iterate, and not supporting
async with dependencies could only be the first iteration
- @westonruter: From what I can see, it’s more about just copying the same logic in place for
defer. Currently there’s a check that just bails
async entirely if there are
- @flixos90: When the current implementation was originally defined, it was noted that by default
async scripts don’t execute necessarily in the same order their tags are printed on the page.
- @westonruter: When async scripts have dependencies, the order is explicitly not significant. It’s up to the library to ensure that the logic is executed in the right order. You can see in my demo when you get a chance. So it’s less about the execution order as much as being able to automatically get a bundle of scripts printed
- @flixos90: Yeah, but I feel that is what complicates things. We would have to assume the script that uses
async does the right thing, whereas so far with how the strategies are handled, WordPress will ensure it loads things in the right order
- @westonruter: Since it is opt-in by developers, I don’t see it being an issue.
- @flixos90: I agree that this is something worth supporting in WordPress, but supporting it has different implications for developers than what is supported by the current PR. So I would see that as a separate enhancement as it requires its own level of discussions. On a technical level we could easily support it it seems, but the implications are different
- To be discussed further
- @westonruter: Another point I wanted to raise: for that same pull request, I also proposed the elimination of manual script tag construction in
WP_Scripts to improve readability, increase robustness, and facilitate CSP in scripts printed by WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Any concerns about using those script tag 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.) construction helpers in
WP_Scripts? It’s not clear why they weren’t utilized when they were introduced.
- @johnbillion: +1 to that, those functions haven’t gotten much use since they were introduced
- @flixos90: Yeah I agree we should definitely use them
- @flixos90: It would be great to get additional code review feedback this week, just please be conscious that Simon who has been leading the work on the PR is out this week, so it may only be next week that he’ll get back to it
Link to roadmap projects
Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill
- @flixos90: Last week I opened and milestoned several Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets to enhance core’s lazy-loading logic:
- These enhancements will benefit an eventual
fetchpriority implementation as well. The idea is that the latter should therefore only happen after those enhancements have landed.
Link to roadmap projects
Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27
Link to roadmap projects
- @flixos90: There is still some work going on in the plugin check repository project https://github.com/orgs/10up/projects/12/views/1. It’s close to having a first alpha version that is ready to use, at which point it would be great to move it to the
WordPress GitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ organization
Creating Standalone Plugins
Link to GitHub overview issue
Contributors: @flixos90 @mukesh27 @10upsimon
- @flixos90: We’re still awaiting approval for the Fetchpriority standalone plugin repository, as the plugin review team is currently seeing notable delays. Fingers crossed we get an approval soon
- @flixos90: Other than that, we’ve started thinking about what the implementation for a Milestone 2 (actually removing the modules from PL) could look like, see the overview issue description for sub-issues
- @westonruter: On the topic of CSS, there’s Felix’s Gutenberg issue to load less CSS for core blocks by only printing the CSS for the blocks used on the page, here specifically for classic themes. I identified some challenges with inlining CSS with rendered blocks. I suggested a (probably controversial) alternative using output buffering. Here’s a proof of concept plugin. Maybe page output buffering now would be less controversial since it’s essentially how block themes are working?
- @spacedmonkey: I am not a fan of output style tags inline. I feel like that would have side effects we could do know about. ATM, we have a head and footer styles / scripts. I was wonder if we could add a enqueue after every set of blocks, so widget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. blocks, post content and block theme. If it was an opt-in feature and all core blocks opt-in, that could go a long way.
- @westonruter: Inlining I think is a no-go, for the reasons I identified
- @spacedmonkey: Could we inline that at the start / end of post content?
- @westonruter: That would probably resolve the issue with inlining breaking CSS selectors. But not all. For example, if you have
div.entry-content > p:first-child, inlining would break this (edited). And if the CSS were at the end of the post content, then this would be the same problem as we have right now with the styles being printed in the footer: the potential for flash-of-unstyled-content
- @spacedmonkey: So we need some other hook to output the scripts / styles in. Outside of the context of the content. In block themes we could add that but if might an opt-in for classic themes.
- @westonruter: IMO, an opt-in for classic themes would take a long time to get adoption, and it doesn’t seem quite right if the future focus is on block themes. I’m not sure how the hook would work in practice either. Block themes are able to solve this problem by “output buffering” the content (not using
ob, but rather just storing the content in memory for
do_blocks). If output buffering could be used in classic themes, then we’d be able to hoist footer styles to the
head in the same way, easily.
Our next chat will be held on Tuesday, May 9, 2023 at 15:00 UTC in the #core-performance channel in Slack.