<div style="text-align:center"></div><div>
<p><a href="https://make.wordpress.org/core/2023/05/01/performance-chat-agenda-2-may-2023/">Meeting agenda here</a> and the full chat log is available <a href="https://wordpress.slack.com/archives/C02KGN5K076/p1683039685722399">beginning here on Slack</a>.</p>
<h2 class="wp-block-heading">Announcements</h2>
<ul>
<li><a href="https://make.wordpress.org/core/2023/05/02/proposal-for-enhancing-lcp-image-performance-with-fetchpriority/">Proposal</a> for using <code>fetchpriority</code> to enhance LCP image performance published</li>
</ul>
<h2 class="wp-block-heading" id="focus-group-updates">Priority Projects</h2>
<h3 class="wp-block-heading" id="images">Server Response Time</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-server-response-time">Link to roadmap projects</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> <a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> <a href="https://profiles.wordpress.org/aristath/" class="mention"><span class="mentions-prefix">@</span>aristath</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: Committed <a href="https://core.trac.wordpress.org/changeset/55701">[55701]</a> and <a href="https://core.trac.wordpress.org/changeset/55702">[55702]</a></li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> has been working on <a href="https://core.trac.wordpress.org/ticket/58196">#58196</a>
<ul>
<li>Could have the possibility to have 6-10% of server time for block themes</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: 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 <code>trunk</code>) and didn’t see any performance impact</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: I think it related to changes in trunk</li>
<li><a href="https://profiles.wordpress.org/johnbillion/" class="mention"><span class="mentions-prefix">@</span>johnbillion</a>: The ticket is now about adding caching (see <a href="https://core.trac.wordpress.org/ticket/58196#comment:9">new comment</a> and <a href="https://github.com/WordPress/wordpress-develop/pull/4397">new PR</a>)</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> and <a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> to follow up with additional benchmarks to determine why the benchmark results differ so much</li>
</ul>
</li>
</ul>
<h3 class="wp-block-heading" id="images">Database Optimization</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-database-optimization">Link to roadmap projects</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/aristath/" class="mention"><span class="mentions-prefix">@</span>aristath</a> <a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> <a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a> <a href="https://profiles.wordpress.org/rjasdfiii/" class="mention"><span class="mentions-prefix">@</span>rjasdfiii</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> plans to commit lazy loading of comment meta everywhere, today or tomorrow
<ul>
<li>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</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/xavivars/" class="mention"><span class="mentions-prefix">@</span>xavivars</a> had a couple of comments regarding the SQLite integration
<ul>
<li><a href="https://profiles.wordpress.org/xavivars/" class="mention"><span class="mentions-prefix">@</span>xavivars</a>: 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</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Yes, just to recap the above conversation from last week: The SQLite plugin / 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 <code>WordPress/performance</code> repository and the Performance Lab plugin</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Probably best to raise in the plugin’s <a href="https://github.com/WordPress/sqlite-database-integration">GitHub repository</a></li>
<li><a href="https://profiles.wordpress.org/xavivars/" class="mention"><span class="mentions-prefix">@</span>xavivars</a>: It may be worth to remove it from <a rel="noreferrer noopener" href="https://make.wordpress.org/performance/roadmap-2023/#category-database-optimization" target="_blank">https://make.wordpress.org/performance/roadmap-2023/#category-database-optimization</a> (or make that decision explicit in the roadmap)</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: 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.</li>
</ul>
</li>
</ul>
<h3 class="wp-block-heading" id="object-caching">JavaScript &#038; CSS</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-javascript-css">Link to roadmap project</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/mukesh27/" class="mention"><span class="mentions-prefix">@</span>mukesh27</a> <a href="https://profiles.wordpress.org/10upsimon/" class="mention"><span class="mentions-prefix">@</span>10upsimon</a> <a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> would like to share that there is now a pull request for the new script loading strategy <a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4391" target="_blank">https://github.com/WordPress/wordpress-develop/pull/4391</a>
<ul>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a>: In that pull request for Script Loading Strategies, <a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4391#discussion_r1179857620" target="_blank">identified</a> what may be missing support for <code>async</code> scripts having dependencies. I put together an <a rel="noreferrer noopener" href="https://async-library-script-loading-demo.glitch.me/" target="_blank">Async Library Script Loading Demo</a> that demonstrates how <code>async</code> scripts could indeed have dependencies. So I’d like it if anyone could affirm my findings for the need for <code>async</code> 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.</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: 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. 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 <code>async</code> with dependencies could only be the first iteration</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a>: From what I can see, it’s more about just copying the same logic in place for <code>defer</code>. Currently there’s a check that just bails <code>async</code> entirely if there are <code>deps</code></li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: When the current implementation was originally defined, it was noted that by default <code>async</code> scripts don’t execute necessarily in the same order their tags are printed on the page.</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a>: 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</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Yeah, but I feel that is what complicates things. We would have to assume the script that uses <code>async</code> does the right thing, whereas so far with how the strategies are handled, WordPress will ensure it loads things in the right order</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a>: Since it is opt-in by developers, I don’t see it being an issue.</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: 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</li>
<li>To be discussed further</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a>: Another point I wanted to raise: for that same pull request, I also <a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4391#issuecomment-1526689240" target="_blank">proposed</a> the <a rel="noreferrer noopener" href="https://github.com/10up/wordpress-develop/pull/58" target="_blank">elimination of manual script tag construction</a> in <code>WP_Scripts</code> to improve readability, increase robustness, and facilitate CSP in scripts printed by WordPress core. Any concerns about using those script tag construction helpers in <code>WP_Scripts</code>? It’s not clear why they weren’t utilized when they were introduced.</li>
<li><a href="https://profiles.wordpress.org/johnbillion/" class="mention"><span class="mentions-prefix">@</span>johnbillion</a>: +1 to that, those functions haven’t gotten much use since they were introduced</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Yeah I agree we should definitely use them</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: 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</li>
</ul>
</li>
</ul>
<h3 class="wp-block-heading" id="measurement">Images</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-images">Link to roadmap projects</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> <a href="https://profiles.wordpress.org/thekt12/" class="mention"><span class="mentions-prefix">@</span>thekt12</a> <a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a> <a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: Last week I opened and milestoned several Trac tickets to enhance core’s lazy-loading logic:
<ul>
<li><a href="https://core.trac.wordpress.org/ticket/58211">#58211</a></li>
<li><a href="https://core.trac.wordpress.org/ticket/58212">#58212</a></li>
<li><a href="https://core.trac.wordpress.org/ticket/58089">#58089</a></li>
<li><a href="https://core.trac.wordpress.org/ticket/56588">#56588</a></li>
<li><a href="https://core.trac.wordpress.org/ticket/58213">#58213</a></li>
<li>These enhancements will benefit an eventual <code>fetchpriority</code> implementation as well. The idea is that the latter should therefore only happen after those enhancements have landed.</li>
</ul>
</li>
</ul>
<h3 class="wp-block-heading" id="javascript">Measurement</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-measurement">Link to roadmap projects</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/adamsilverstein/" class="mention"><span class="mentions-prefix">@</span>adamsilverstein</a> <a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a> <a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> <a href="https://profiles.wordpress.org/mukesh27/" class="mention"><span class="mentions-prefix">@</span>mukesh27</a></p>
<ul>
<li>No updates</li>
</ul>
<h3 class="wp-block-heading">Ecosystem Tools</h3>
<p><a href="https://make.wordpress.org/performance/roadmap-2023/#category-ecosystem-tools">Link to roadmap projects</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/joegrainger/" class="mention"><span class="mentions-prefix">@</span>joegrainger</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: There is still some work going on in the plugin check repository project <a rel="noreferrer noopener" href="https://github.com/orgs/10up/projects/12/views/1" target="_blank">https://github.com/orgs/10up/projects/12/views/1</a>. 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 <code>WordPress</code> GitHub organization</li>
</ul>
<h3 class="wp-block-heading" id="infrastructure">Creating Standalone Plugins</h3>
<p><a href="https://github.com/WordPress/performance/issues/656">Link to GitHub overview issue</a></p>
<p>Contributors: <a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> <a href="https://profiles.wordpress.org/mukesh27/" class="mention"><span class="mentions-prefix">@</span>mukesh27</a> <a href="https://profiles.wordpress.org/10upsimon/" class="mention"><span class="mentions-prefix">@</span>10upsimon</a></p>
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: 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</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a>: 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 <a rel="noreferrer noopener" href="https://github.com/WordPress/performance/issues/656" target="_blank">overview issue</a> description for sub-issues</li>
</ul>
<h1 class="wp-block-heading">Open Floor</h1>
<ul>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a>: On the topic of CSS, there’s Felix’s <a rel="noreferrer noopener" href="https://github.com/WordPress/gutenberg/issues/49927" target="_blank">Gutenberg issue</a> 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 <a rel="noreferrer noopener" href="https://github.com/WordPress/gutenberg/issues/49927#issuecomment-1528174046" target="_blank">challenges with inlining CSS with rendered blocks</a>. I suggested a (probably controversial) <a rel="noreferrer noopener" href="https://github.com/WordPress/gutenberg/issues/49927#issuecomment-1528183246" target="_blank">alternative</a> using output buffering. Here’s a <a rel="noreferrer noopener" href="https://github.com/WordPress/gutenberg/issues/49927#issuecomment-1528630855" target="_blank">proof of concept plugin</a>. Maybe page output buffering now would be less controversial since it’s essentially how block themes are working?
<ul>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: 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 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.</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a>: Inlining I think is a no-go, for the reasons I <a rel="noreferrer noopener" href="https://github.com/WordPress/gutenberg/issues/49927#issuecomment-1528174046" target="_blank">identified</a></li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: Could we inline that at the start / end of post content?</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a>: That would <em>probably</em> resolve the issue with inlining breaking CSS selectors. But not all. For example, if you have <code>div.entry-content > p:first-child</code>, 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</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a>: 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.</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a>: 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 <code>ob</code>, but rather just storing the content in memory for <code>do_blocks</code>). If output buffering could be used in classic themes, then we’d be able to hoist footer styles to the <code>head</code> in the same way, easily.</li>
</ul>
</li>
</ul>
<p><strong>Our next chat will be held on <a href="https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230509T1500"><abbr class="date" title="2023-05-09T15:00:00+00:00">Tuesday, May 9, 2023 at 15:00 UTC</abbr></a> in the <a href="https://wordpress.slack.com/messages/core-performance/">#core-performance channel</a> in <a href="https://make.wordpress.org/chat/">Slack</a>.</strong></p>
<p class="o2-appended-tags"><a href="https://make.wordpress.org/core/tag/core-performance/" class="tag"><span class="tag-prefix">#</span>core-performance</a>, <a href="https://make.wordpress.org/core/tag/performance/" class="tag"><span class="tag-prefix">#</span>performance</a>, <a href="https://make.wordpress.org/core/tag/performance-chat/" class="tag"><span class="tag-prefix">#</span>performance-chat</a>, <a href="https://make.wordpress.org/core/tag/summary/" class="tag"><span class="tag-prefix">#</span>summary</a></p>
</div>

As October winds down, so too does Blocktober, Tammie Lister’s month-long challenge to create a…
The WordPress Foundation and WooCommerce have joined Automattic and Matt Mullenweg in countersuing WP Engine,…
The first-ever CloudFest USA Hackathon, taking place November 4 in Miami, will bring together contributors…
Canada’s largest gathering of WordPress enthusiasts drew a strong turnout at Carleton University last weekend,…
WooCommerce 10.3 was released this week, introducing one of the most requested features for store…
Automattic has hired GiveWP co-founder Devin Walker as Artistic Director for Jetpack, where he will…