Meeting agenda here and the full chat log is available beginning here on Slack.
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 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 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. theme template part data from
- @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
- @westonruter is looking into measuring script loading strategy adoption. The upcoming Gutenberg 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. https://wordpress.org/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 Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.).
Link to roadmap projects
Contributors: @aristath @spacedmonkey @olliejones
Link to roadmap project
Contributors: @mukesh27 @10upsimon @adamsilverstein @westonruter
- @10upsimon: New script loading strategy API 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
- @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 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 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 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 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 Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/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 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 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 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/ 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 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 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.
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 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
Our next chat will be held on Tuesday, August 15, 2023 at 15:00 UTC in the #core-performance channel in Slack.