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

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

  • N/A

Feedback requested

Site Health

N/A

GitHub project

Feedback requested

Measurement

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
  • N/A

Feedback requested

JavaScript

@aristath @sergiomdgomes

GitHub project

  • N/A

Feedback requested

Infrastructure

@flixos90

GitHub project

  • N/A

Feedback requested

Open Floor

  • @adamsilverstein: fetchpriority module 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=lazy attribute from images we expect will be the LCP image; so we should be able to apply the fetchpriority=high to 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_default function to determine whether we want to use the fetchpriority  attribute or not, right? if so, i think this won’t work because it will return false (which is when we want to add the fetchpriority attribute) 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 add fetchpriority="high" if not
      • @adamsilverstein: was thinking the latter, running on the same hook where loading=lazy is added, but later
    • @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
    • @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

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

#performance, #performance-chat, #summary

Leave a Reply

Your email address will not be published.