Performance Chat Summary: 8 August 2023

Meeting agenda here and the full chat log is available beginning here on Slack.

Announcements

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 plugin / PL module).
  • Not directly part of the template loading work, but closely related, @flixos90 shared @oandregal‘s PR to cache block theme template part data from theme.jsonhttps://github.com/WordPress/wordpress-develop/pull/4971
    • @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 Gutenberg release will have defer scripts so hopefully we’ll get some data soon
  • @thekt12 is working on changes related to  https://core.trac.wordpress.org/ticket/58532 (block_has_support performance enhancement).

Database Optimization

Link to roadmap projects

Contributors: @aristath @spacedmonkey @olliejones

JavaScript & CSS

Link to roadmap project

Contributors: @mukesh27 @10upsimon @adamsilverstein @westonruter

  • @10upsimon: New script loading strategy API 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 plugin 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 HTTP 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.)

Images

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 https://github.com/WordPress/wordpress-develop/pull/4973 yesterday which is a PR to fix images within shortcodes to be handled properly with the other content that it is part of (see https://core.trac.wordpress.org/ticket/58853). 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 filter.
    • @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.

Measurement

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 https://github.com/swissspidy/compare-wp-performance, 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 CLI 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 GitHub action I just started building, also building on top of the wpp-research CLI utils: https://github.com/swissspidy/wp-performance-action
  • @joemcgill: There are a number of improvements for the core performance workflow that we’ve identified, but not yet picked up work on, like https://core.trac.wordpress.org/ticket/58358, 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: https://github.com/10up/plugin-check/ 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 UI 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 JS 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

Leave a Reply

Your email address will not be published. Required fields are marked *