<div style="text-align:center"></div><div>
<p><a href="https://make.wordpress.org/core/2023/05/09/performance-chat-agenda-09-may-2023/">Meeting agenda here</a> and the full chat log is available <a href="https://wordpress.slack.com/archives/C02KGN5K076/p1683644466202769">beginning here on Slack</a>.</p>
<h2 class="wp-block-heading">Announcements</h2>
<ul>
<li>n/a</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> has a number of PRs that are nearly ready to commit:
<ul>
<li><a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4128" target="_blank">https://github.com/WordPress/wordpress-develop/pull/4128</a></li>
<li><a rel="noreferrer noopener" aria-describedby="qtip-27" href="https://github.com/WordPress/wordpress-develop/pull/4382" target="_blank">https://github.com/WordPress/wordpress-develop/pull/4382</a></li>
<li><a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4417" target="_blank">https://github.com/WordPress/wordpress-develop/pull/4417</a></li>
<li><a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4412" target="_blank">https://github.com/WordPress/wordpress-develop/pull/4412</a></li>
<li><a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4411" target="_blank">https://github.com/WordPress/wordpress-develop/pull/4411</a></li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> I’m waiting on some final feedback, but am close to being able to share the results of the performance research I finished up a few weeks ago. The highlights from that research are that there may be some good opportunities to look into the way template rendering is being handled in both classic and block themes, and also some bottlenecks I observed with translations in classic themes
<ul>
<li><a href="https://profiles.wordpress.org/swissspidy/" class="mention"><span class="mentions-prefix">@</span>swissspidy</a> Curious about the translations part and how it only affects classic themes</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> Same! I noticed a very large difference between the two architectures. Not sure why that is happening, so it would be really useful to look into.</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> This is a follow on from get_pages -> get_posts <a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4386" target="_blank">https://github.com/WordPress/wordpress-develop/pull/4386</a> – Add filter to allow developers to change params to WP_Query, an ask from ployglot</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> I opened this as well <a href="https://core.trac.wordpress.org/changeset/58277">[58277]</a> TLDR, saves around 600+ calls to wp_cache_get that are not needed
<ul>
<li>Numbers are very very promising in blackfire but not as much in benchmarks, still working this out</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> updates above</li>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a> I’ve been working on object cache instrumentation, no big results to report</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> There a project afoot to add a spec for getting object cache information <a href="https://github.com/rhubarbgroup/wp-object-cache-info-spec">https://github.com/rhubarbgroup/wp-object-cache-info-spec</a>
<ul>
<li><a href="https://profiles.wordpress.org/olliejones/" class="mention"><span class="mentions-prefix">@</span>olliejones</a> A new revision of this is coming soon, from me</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> Basically add a <code>wp_cache_info</code> function to core and allow WP CLI, query monitor and other tools to understand the cache implementation</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>One agenda item here today Discussion this week on CSP/async concerns in <a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4391" target="_blank">https://github.com/WordPress/wordpress-develop/pull/4391</a></li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> I left some more <a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4391#issuecomment-1536869109" target="_blank">feedback</a> related to compatibility with Content-Security-Policy and the deferred inline scripts: the current implementation has a vulnerability related to CSP nonces, and it also blocks Strict CSP by requiring <code>’unsafe-hashes’</code> due to the <code>onload</code> attribute. I provided recommendations for how to address these issues and have been <a rel="noreferrer noopener" href="https://github.com/WordPress/wordpress-develop/pull/4391#issuecomment-1538572942" target="_blank">discussing</a> with <a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a></li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> One of my questions about the CSP concerns you raised, <a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> is whether this whole class of problem would be eliminated if we were to change the way we are approaching <code>async</code> dependencies, or if the problem exists with <code>defer</code> as well? For example, if we weren’t concerned about maintaining loading order (because with <code>async</code> it shouldn’t matter if the scripts are well constructed) then we wouldn’t need to control loading inline scripts so they run after their dependencies.</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> Yes, the problem with CSP nonces exists for deferred inline scripts for <code>defer</code> scripts as well</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> Ok, so I’ll need to double check whether it still makes sense for us to control the loading order there, and if so, then work on implementing one of your suggestions. Your explanation and research here has been really valuable, so thank you!</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> If we eliminate special support for deferred inline <code>after</code> scripts for <code>async</code> scripts, then we can get rid of the <code>onload</code> attribute and just use <code>addEventListener('load')</code> in an <code>after</code> script.</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> Being unfamiliar with “it also blocks Strict CSP by requiring <code>’unsafe-hashes’</code> due to the <code>onload</code> attribute” can you elaborate or share a link with how the <code>onload</code> attribute causes a problem there?”</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> sure, CSP’s security model relies on nonces and hashes. For nonces, all <code>script</code> elements on a page should have a <code>nonce</code> attribute which matches a <code>nonce</code> value passed in the <code>Content-Security-Policy</code> response header. However, such nonces are not possible to be attached to event handler attributes, like <code>onload</code></li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> Your suggestion with <code>addEventListener('load')</code> is problematic if it is wrapped around the inline script because it changes the scope of the code within. This was ruled out as an option early on in the design of this API because of that</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> Actually not quite because the callback passed to <code>addEventListener('load')</code> still just calls <code>wpLoadAfterScripts(handle)</code> In the same way that <code>onload="wpLoadAfterScripts(handle)"</code> is now</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> Ah, so you mean WP core would handle that event listener on its own?</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> It’s just that this change is not compatible with <code>async</code> scripts, but it does work for <code>defer</code> scripts</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> That is the part I don’t understand, why wouldn’t that work for <code>async</code> whereas <code>onload</code> would?</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> Because <code>async</code> scripts can load immediately before the rest of the document loads. Example: <a rel="noreferrer noopener" href="https://async-script-load-event-listener-test.glitch.me/?delay=500" target="_blank">https://async-script-load-event-listener-test.glitch.me/?delay=500</a></li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> I think the approach of the event listener is definitely preferable, as <code>defer</code> is more important to holistically support at this point, as it works in a simpler way with the current way core handles dependencies
<ul>
<li>That would mean we keep <code>defer</code> functioning like it does now, but will have to (continue to) rethink <code>async</code> support, which I think is okay. I’d also like to throw out there a consideration of potentially only launching with <code>defer</code> in the first version of this</li>
<li>That would give us time to decouple the <code>async</code> exploration</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> Apart from getting into the weeds about how to best address the CSP issue, I do think it’s worth a broader discussion about whether our current approach to <code>async</code> scripts is too conservative (mostly to try and help developers avoid loading errors with dependencies).</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> I think the concerns we based the current implementation from are valid, but maybe a bit heavy handed, so I’m open to us being less concerned with load order concerns if everyone is agreed.</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> </li>
<li>My impression is that <code>async</code> scripts are currently quite rare compared to <code>defer</code> scripts. It’s even rarer that <code>async</code> scripts would depend on each other. But in the cases where they do have dependencies (e.g. AMP) then the loading order is handled in the scripts themselves, and not by source order in the page. Other cases of async scripts having dependencies, e.g. Google Analytics, it’s also handled by the library and loading order doesn’t matter</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> My concern with loosening that is around developer education. We would need to be very clear on what applying <code>async</code> to a script implies. Core would handle <code>defer</code> to always work (make it blocking if needed), but for <code>async</code> it would indeed be on the plugin / theme developer if we loosen the current limits</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> I think that it would be a reasonable position to take, that if you are registering a script that is <code>async</code> or depends on an <code>async</code> script, then it is your responsibility to manage the load order concerns. But agree that dev ed would be important</li>
<li><a href="https://profiles.wordpress.org/spacedmonkey/" class="mention"><span class="mentions-prefix">@</span>spacedmonkey</a> FYI, gutenberg will likely needed deferred scripts for Interactivity API runtime ( I guess is part of co-op editting ). See <a rel="noreferrer noopener" href="https://github.com/WordPress/gutenberg/pull/49994" target="_blank">https://github.com/WordPress/gutenberg/pull/49994</a></li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> Fortunately, there are ample educational materials out there for how <code>async</code> behaves. And devs should only use it if they know what they are doing.
<ul>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> That’s what concerns me </li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> Yep! But as this would be somewhat new for WP script enqueueing, we should support that with some WP-focused documentation as well.</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> Unless someone feel strongly that we should NOT make this the responsibility of the developer, <a href="https://profiles.wordpress.org/10upsimon/" class="mention"><span class="mentions-prefix">@</span>10upsimon</a> and I can work on updating the current approach to allow for a less strict implementation.</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> I think this still deserves more discussion, also with the other now additional consideration that inline scripts would also be responsibility of the developer</li>
<li><a href="https://profiles.wordpress.org/westonruter/" class="mention"><span class="mentions-prefix">@</span>westonruter</a> What’s certain is that while we would promote <code>defer</code>, we would need to be very clear in the docs that <code>async</code> order is not predictable. So while <code>defer</code> can often be applied to all scripts, this is definitely not the case for <code>async</code>.</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> Happy to make it a future agenda item here. We’ll also be looking for feedback when we post on make core about the feature and can address it there as well.</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> But more importantly, what about decoupling this discussion? I suggested that above: I think we’re all pretty clear what should happen with <code>defer</code>, but we need to discuss <code>async</code> more
<ul>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> agreed</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> Why not remove all <code>async</code> support from the current PR and keep that for an iteration? This allows us to iterate on what is already clear, and gives us time to approach the other problem separately</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> I think we should save that option for if we can’t come to resolution in the next few weeks.</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> That’s fair, though I want to make sure we don’t come to early conclusions and eagerly update the PR with something that is then still being discussed</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> It’s clear that we’re basically “going back to the drawing board” with <code>async</code>. So one could argue that topic is not yet ready for engineering. Having that discussion and providing related comments on the PR makes it more difficult for the folks working on the code to focus on the improvements to the PR that are clear
<ul>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> I disagree that we’re going back to the drawing board, but am happy to pick this up async so we can move on with this conversation</li>
<li><a href="https://profiles.wordpress.org/flixos90/" class="mention"><span class="mentions-prefix">@</span>flixos90</a> We are changing the design of how <code>async</code> support works from how it was designed, that’s what I mean by that. Which of course is not a bad thing, but we’re not ready to write code for that because of it still being discussed</li>
<li><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> Yeah, but it seems like a rather small change that will result in reducing the logic we’ve implemented, not adding a lot more, so I’m not all that concerned as long as we get consensus on the correct approach.</li>
</ul>
</li>
<li><a href="https://profiles.wordpress.org/clarkeemily/" class="mention"><span class="mentions-prefix">@</span>clarkeemily</a> I’d like to suggest picking this up async, perhaps on the GitHub issue? We can also add an agenda item to revisit this time next week too if no conclusion is drawn on the GH issue? We have a few more project updates to go through, so we can circle back async</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> Just a quick reminder that the Fetchpriority standalone plugin was published on Friday, the Fetchpriority standalone plugin was approved for <a rel="noreferrer noopener" href="https://wordpress.org/" target="_blank">wordpress.org</a>. Since we already have the infrastructure for it set up in <code>WordPress/performance</code>, and since we’ve already established that it works with the WebP Uploads standalone plugin, I’m going to go ahead and publish a first version now. Will share progress here</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><a href="https://profiles.wordpress.org/joemcgill/" class="mention"><span class="mentions-prefix">@</span>joemcgill</a> I plan to open a few tickets for some enhancements we’d like to make to the automated performance tooling we added to core during the 6.2 milestone, but no immediate work happening there.</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>@joegrainer I have been away the past week so not much to update here from me but I will be working through the issues raised in the Plugin Checker Milestone 1 Review/QA. We have made some progress and closed a few of these out already. You can follow all progress on the <a rel="noreferrer noopener" href="https://github.com/10up/plugin-check/" target="_blank">GitHub repo</a> here. Thanks!</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> Just the above, <a rel="noreferrer noopener" href="https://wordpress.org/plugins/fetchpriority/" target="_blank">Fetchpriority</a> was published, and following that I submitted Dominant Color Images for plugin review (which is expected to take 25+ days, so we’ll have some time to wait)</li>
<li><a href="https://profiles.wordpress.org/mukesh27/" class="mention"><span class="mentions-prefix">@</span>mukesh27</a> The PR <a rel="noreferrer noopener" href="https://github.com/WordPress/performance/pull/710" target="_blank">Use dynamic version from </a><code>plugins.json</code><a rel="noreferrer noopener" href="https://github.com/WordPress/performance/pull/710" target="_blank"> for manual workflow #710</a> ready for review</li>
</ul>
<h1 class="wp-block-heading">Open Floor</h1>
<ul>
<li><a href="https://profiles.wordpress.org/thelovekesh/" class="mention"><span class="mentions-prefix">@</span>thelovekesh</a> Since the performance plugin is expanding in terms of the number of classes, functions, and hooks it contains, I believe it would be great to start documenting things so that plugin and theme developers may use them. We can start using the phpdoc-parser to automatically create the necessary documentation from code comments when a release is made and the same can be deployed to the GitHub pages site(<a rel="noreferrer noopener" href="https://wordpress.github.io/performance/" target="_blank">https://wordpress.github.io/performance/</a>) or to <a rel="noreferrer noopener" href="https://wordpress.org/" target="_blank">WordPress.org</a>.</li>
</ul>
<p><strong>Our next chat will be held on <a href="https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230516T1500"><abbr class="date" title="2023-05-16T15:00:00+00:00">Tuesday, May 16, 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…