Performance Chat Summary: 8 August 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 @swissspidy

  • @joemcgill is working with @mukesh27 on an exploration of ways we can improve performance of the template loading process, which we’ve seen be responsible for a large portion of the overall server response time. Hoping to have something to share later this week. He also plans to do another (smaller) profiling analysis of WP 6.3 after the release today to see if we can identify any optimizations that we can put in place during this release cycle
  • @swissspidy is summarizing the responses to the i18n peformance analysis this week together with some suggested next steps (which is probably going to involve a feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. / PL module).
  • Not directly part of the template loading work, but closely related, @flixos90 shared @oandregal‘s PR to cache blockBlock 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. theme template part data from theme.json
    • @swissspidy: Maybe at some point we can just build some caching into WP_Theme_JSON_Resolver ? Just so we don’t end up with X similar public functions that are just cached wrappers around it
  • @joemcgill: I’m curious if we have thought of ways of evaluating the impact of WP 6.3 using HTTPArchive data, or similar so we can compare real world impact to the benchmarks we’ve been doing?
    • @flixos90: I’m definitely planning to take a closer look once CrUX performance data is available, i.e. starting in September. Separately, we can also measure our success with some more specific not directly performance-related analyses, e.g. check what % of LCP images is lazy-loaded (bad!) or what % of LCP images receives fetchpriority="high" (good!).
    • @westonruter is looking into measuring script loading strategy adoption. The upcoming GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. release will have defer scripts so hopefully we’ll get some data soon
  • @thekt12 is working on changes related to (block_has_support performance enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.).

Database Optimization

Link to roadmap projects

Contributors: @aristath @spacedmonkey @olliejones

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 @westonruter

  • @10upsimon: New script loading strategy 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. will of course be released today with 6.3! The docs team has taken ownership of the documentation document that we drafted (with the intent to update all the necessary areas)
  • @westonruter committed use of defer for the wp-embed script.
  • @westonruter worked queries to determine frequency of themes/plugins adding blocking/async/defer scripts in head/footer. Good news that most sites have embraced $in_footer: around 80% of blocking scripts are in the footer instead of the head. Nevertheless, there are opportunities to engage with the 20% to consider moving blocking head scripts to the footer, or rather add defer and leave in the head. He also queried for the specific themes and plugins that seem to be adding those blocking head scripts, so we can engage with the 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 authors for possible adoption. (The list is in that same PR.)
  • On the emoji loader front, which accounts for a large improvement to LCP-TTFB in 6.3, @westonruter tried querying for 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. Archive for how often sites have the emoji loader enabled. Found that 61.8% indexed sites have it enabled, with the sites not indexed (the long tail) surely having it more commonly enabled (since it is enabled by default). But we should be seeing the large client-side LCP improvement in about two-thirds of sites in HTTP Archive at least.
  • Also, in relation to inline before/after scripts, @westonruter created query to determine counts for inline script types. The vast majority (~90%) are not after inline scripts. So the fact that we didn’t include support for them in 6.3 probably won’t be hurting us. (In that we shouldn’t commonly be seeing fallbacks to to blocking.)


Link to roadmap projects

Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill

  • @pereirinha is making good progress on #58892. Currently going through all the needed updates on testing — removing the deprecated tests and adding updated ones; should have a PR ready toward the EOW.
  • @flixos90 opened yesterday which is a PR to fix images within shortcodes to be handled properly with the other content that it is part of (see This morning there are still test failures, so he’ll take another look shortly, but other than that it’s ready for review.
    • @joemcgill: I planned to write a test to demonstrate the use case I mentioned in that ticket about do_shortcode() when used directly to generate markup that then gets processed again on the_content filterFilter Filters are one of the two types of Hooks They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output..
    • @flixos90: I added a test on the PR covering what I think you meant, but that may not be what you meant, so it would be great if you could take a look.
  • @joemcgill: Still watching browser implementation of auto-sizes for lazy-loaded images, but no updates over the past few weeks.


Link to roadmap projects

Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27 @swissspidy

  • @westonruter added added network condition emulation to the benchmark-web-vitals command. This will allow us to simulate Slow 3G and Fast 3G when benchmarking.
  • @swissspidy recently built, as shared in the performance analysis post; also working on some other stuff for improving the performance testing environment, hope to have something shareable this week.
  • @joemcgill ran into an issue yesterday with the way we’re loading the web-vitals library in the CLICLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. script that causes it to get blocked by some sites with restrictive content security policies (CSP). Reported here. Spent some time trying some workarounds yesterday without success. Will pick this back up, but if anyone has ideas, feel free to jump in.
  • @swissspidy: As a sneak peek for the curious, here’s another GitHubGitHub 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. action I just started building, also building on top of the wpp-research CLI utils:
  • @joemcgill: There are a number of improvements for the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. performance workflow that we’ve identified, but not yet picked up work on, like, which @oandregal recently asked about prioritizing. I’m unsure if/how that relates to the work @swissspidy is doing and if we want to wait until that effort is done before addressing some of these things, or if we want to move forward on these in the mean time?
    • Overview covering those tickets
    • @flixos90: I think we need to review those and discuss what to prioritize. While partially a reusable performance testing workflow may address them in a more efficient way, we also have to consider the trade-off between the “perfect” solution and getting to a working solution for core faster
    • @swissspidy: Yeah so among other things I’m basically looking into tickets like that and for example #58359 to see how best to address them.

Ecosystem Tools

Link to roadmap projects

Contributors: @mukesh27 @swissspidy @westonruter

  • @mukesh27: We just fixed and merged all the Plugin Checker follow-up issues that we found. To stay up-to-date with our progress, follow us on GitHub: We highly value your input! If you have any thoughts, ideas, or feedback, please don’t hesitate to share them on the repository.

Creating Standalone Plugins

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

  • @10upsimon has been working on a POC, have the UIUI User interface working with the current WPP standalone plugins being rendered with various states. He is currently working on A/B testing two approaches and hopes to have some direction by tomorrow:
    • Retrofitting core’s updates.js to work in the UI
    • Custom REST controllers with wpp plugin authored JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. to handle the installlation, activation, deactivation etc.

Open Floor

  • N/A

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

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