Performance team meeting summary 23 August 2022
Meeting agenda here and the full chat log is available beginning here on Slack.
Announcements
Focus group updates
Images
@adamsilverstein @mikeschroder
- @adamsilverstein: team has been responding to new feedback on the main multi-mime/WebP ticket from Lead developer @azaozz (and @dd32); preparing a response post to propose possible paths forward and how to address the concerns raised in their comments; committing anything is paused until we are clear on the direction we will take
- @adamsilverstein has also been working on fine tuning the logic to select the correct image processing engine based on mime type in #54476; this could use some additional testing from as many environments as possible
- @joegrainger: Working on finalizing feedback on Regenerate Existing Images module proposal and core patch for Update core functions to support multiple mime types
- @wpgurudev: Working on initial PRs for Regenerate Existing Images module (https://github.com/WordPress/performance/pull/496, https://github.com/WordPress/performance/pull/497)
- @mukesh27: Working on WebP core follow-up patches (https://github.com/WordPress/wordpress-develop/pull/3034, https://github.com/WordPress/wordpress-develop/pull/3036)
Feedback requested
- See above
- Needs Discussion (9 issues)
Object Cache
- N/A
Feedback requested
- Needs Discussion (3 issues)
- Needs Review (1 issue)
Site Health
N/A
- We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
- @furi3r: Both the core PR for persistent object cache check and PR for full page cache check are ready; @flixos90 will review both of these this week again and commit them if they’re good to go
Feedback requested
- Needs Discussion (9 issues)
Measurement
N/A
- We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
- N/A
Feedback requested
- Needs Discussion (5 issues)
- Needs Review (1 issue)
JavaScript
- N/A
Feedback requested
- Needs Discussion (2 issues)
- Needs Review (3 issues)
Infrastructure
- N/A
Feedback requested
- Needs Discussion (5 issues)
- Needs Review (3 issues)
Open Floor
- @adamsilverstein:
fetchprioritymodule proposal- @adamsilverstein: basically the idea here is to give the browser a hint about which image it should prioritize loading
- @adamsilverstein: we already have logic in place in core to exclude the
loading=lazyattribute from images we expect will be the LCP image; so we should be able to apply thefetchpriority=highto those exact image and see improved/prioritized loading for those images; so we shouldn’t need new logic to determine which image to apply the attribute to- @eugenemanuilov: so, we are going to use the
wp_get_loading_attr_defaultfunction to determine whether we want to use thefetchpriorityattribute or not, right? if so, i think this won’t work because it will returnfalse(which is when we want to add thefetchpriorityattribute) only once in the default setup, and most likely that once time will be used when we render a thumbnail - @flixos90: Potentially, definitely something along those lines. Or we could check if the image has
loading="lazy"on it and only addfetchpriority="high"if not - @adamsilverstein: was thinking the latter, running on the same hook where loading=lazy is added, but later
- @eugenemanuilov: so, we are going to use the
- @flixos90: this seems to be a technically rather straightforward potential module for the Performance Lab plugin. As Adam mentioned, the main purpose of the module would be to allow us to test how this behaves and measure the impact in the real world; from there it could be refined as needed and eventually proposed for WordPress core
- @adamsilverstein: this is a “good first module” if someone wants to try to pick it up!
- @olliejones: do you propose to include anything to measure the improvements? Or will measurement be based on lighthouse, etc?
- @flixos90: I think measurement is generally happening outside of the Performance Lab plugin, e.g. using Lighthouse, WebPageTest (for lab tests) or CrUX, HTTP Archive (for field tests)
- @adamsilverstein: the generator tag should indicate the active modules, so part of putting it in a module is helping being able to detect it; that said we could also query for the presence of the fetchpriority attribute itself as well
- @masteradhoc: nice module. Interested to see how this could turn out on real sites and how much it will help. Read this guide some time ago: https://web.dev/priority-hints/; anything planned or could also be useful with the opposite priority?
- @flixos90: Hmm I’m unfamiliar for which cases you would realistically want to use
fetchpriority="low"; at least for images, we already have lazy-loading, so there adding this probably wouldn’t do much, but of course there are other types of resources where the attribute can be added, so maybe there’s some value there
- @flixos90: Hmm I’m unfamiliar for which cases you would realistically want to use
- @adamsilverstein: worth noting we recently added “preload” capabilities to core (#42438), but fetchpriority serves a slightly different use case that should have better results for LCP images
- @olliejones: Database Performance Health Checks module proposal
- @olliejones: This is 100% back end stuff. The DBMS world (MariaDB / MySQL) has lots of new performance-enhancement stuff. I propose pointing out that stuff to site owners. Five tests in this module:
- DBMS server version, with a detail check for the availability of the latest table format.
- DBMS Connect / Query response time test.
- Two tests for latest’n’greatest table formats: one for core tables (incl WooCommerce) and another for plugin tables.
- Finally, a comparison of the data size of the site’s tables with the size of the DBMS server buffer pool, to detect underprovisioned DBMS machines.
- @olliejones: A previous proposal also included instructions for using wp-cli to correct some inefficiencies, but that doesn’t work for Performance Lab: it’s aimed at site owners not server ops people.
- @flixos90: I think there is a lot to unpack here. I wonder if it might be best to start the module with only 1 or 2 of these checks; we could easily make those different checks even different modules, not sure what the benefit would be to having it all in one module except that it’s all related to DBs
- @olliejones: Benefit for one module? simpler Settings page, that’s it (also shared code among the tests, but that’s not so important)
- @flixos90: fair point. But maybe we can still start with a subset of the checks. A bit easier to reason about and focus better. Discussing all these topics at once will be challenging. Maybe you can suggest a first check from the list above to focus on discussing?
- @olliejones: Either Connect/query latency or buffer pool sizing.
- following up on this new module proposal will be the first special agenda item next week
- @olliejones: This is 100% back end stuff. The DBMS world (MariaDB / MySQL) has lots of new performance-enhancement stuff. I propose pointing out that stuff to site owners. Five tests in this module:
Our next chat will be held on Tuesday, August 30, 2022 at 15:00 UTC in the #core-performance channel in Slack.
