Performance team meeting summary 6 September 2022

Performance team meeting summary 6 September 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

  • @spacedmonkey: Committed [54080]
    • @flixos90: would be curious whether this network options API change has actual performance benefits. It’s certainly great from an API perspective to have that better aligned, but since we’re speaking about performance here, I don’t think we really know how that is going to be impacted
    • @spacedmonkey: It reduces the number of queries a lot; it also means if a network option does not exist in the database, it does result in another query (with Jetpack installed, 3 less queries per page just from missed network options); To be sure, performance is not the only reason do this. It removed a lot of code and add benefits, like register_meta, default values, new filters etc.
    • @flixos90: Totally makes sense. If you could support that with some benchmarks for the dev note that would be great and also justify it more from a performance perspective
  • @spacedmonkey: Core PRs #3178 and #2995 are ready for review

Feedback requested

Site Health

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
  • @flixos90: Site Health check for full page cache was merged last week in [54043]
    • There were some follow up quirks to address with some test issues related to some environment edge cases, but those have all been addressed shortly after (see #56041 for more details)

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
  • @mehulkaklotar: working on proposal for Plugin Check plugin, getting ready for reviews from the team

Feedback requested

JavaScript

@aristath @sergiomdgomes

GitHub project

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90: Performance Lab plugin PR #468 needs reviews from people experienced with JavaScript tooling, WebPack etc.
  • @flixos90: Plugin PRs #388 and #510 were completed last week, which are some great little fixes

Feedback requested

Open Floor

  • @pbearne: Dominant Color proposal feedback discussion and next steps
    • @pbearne: The feeling is that this is good idea and we would want it, but the theme should control turning it on; the code to store the dominant color values on image upload into the image meta should run regardless (e.g. that data could also be used in the media library in core)
      • We would hide the dominant color for the front-end behind a theme support flag like add_theme_support( 'dominant-color' );
      • This approach can be seen in core PR #3164
      • @flixos90: I think it makes sense to have the CSS aspect of it controlled by themes. However there is considerable other feedback on the post which focuses on the performance aspect of this feature
    • @flixos90: IMO we should center the conversation around that first, as there was some concern on the post what the real performance impact is (whether it’s perceived or “actual” performance); FWIW I don’t think the single lab test that was conducted and posted on the GitHub issue serves as a meaningful indicator for performance. PageSpeed Insights lab test results vary greatly, even between runs of the same page, so the fact that it was slightly better in one run doesn’t mean anything – which is a shame really, but that’s the case
      • @spacedmonkey: I am not sure I agree with your judgement on this one
      • @flixos90: We would need to do much larger scale tests across a variety of sites to assess a performance impact. Metrics like bytes throughput, database queries etc. are stable, but for things like CWV they vary greatly between each run; If you run let’s say 10 tests, each time before, the other time after, and it’s consistently better with the feature, then there may be something to it. But a single PSI test doesn’t mean anything in terms of CWV and dynamic metrics like FCP, TTFB etc., that’s unfortunately the truth
      • @spacedmonkey: But this change has never been about actual performance improvements, perceived performance was always the goal. Could you spend sometime profiling performance further for us and see what results you get?
        • A follow up analysis with more sample data sets has since been conducted, indicating there is no clear performance impact from the feature, so we probably need to focus on perceived performance indeed
    • @adamsilverstein: the discussion on the ticket centers around perceived performance: based on the approach, I doubt there is much actual performance benefit as measured in the lab. Maybe one thing that is missing from the proposal or the comment thread replies is research/data around the benefits background color provides for perceived load time. Part of the issue may be a lack of prior research?
      • @adamsilverstein: the original idea was a bit different (low quality image placeholders, not dominant color) and had even more tradeoffs/cost to use. the commonality is they help users have a sense of what is going to fill an image space before the image loads
      • @flixos90: I think that’s what is a potential problem here: Most articles that we’ve dug up so far focus on perceived performance of regular images with LQIP. But what we’re doing now is “less” than LQIP, so it’s further away from looking like the final image. I know there were technical complexities that make us chose that path, but I think we need to consider that
      • @spacedmonkey: Dominate color has other benefits and can also be used in styling, contrasting overlays / text for example
      • @adamsilverstein: lack of existing research may be because dominant color is relatively unique/new approach? were there existing examples of it we looked at? maybe we need to conduct some research?
        • @spacedmonkey: Unsplash uses blurhash and fallback to dominant color, Google Images also uses dominant color
      • @masteradhoc: I feel like the way that Google uses it for images is really a good way and can improve the visible speed for the user. I would support to have this into core. Frontend is controlled by themes and wp-admin by default looks quite a good way for me
    • @pbearne: Do we feel that adding dominant color to the media library what a good improvement in itself (e.g. as an improvement to wp-admin)?
      • @adamsilverstein: might be worth bringing up at a media meeting, I like the idea but have some concerns: how would library look with only some images having dominant color generated? is it worth the effort of generating the color on upload only for the media library?
      • @flixos90: a potential concern is that this runs additional processing on image upload. I don’t know how much it impacts upload, and whether it does increase the chance to time out or run into memory limit, but that is quite sensitive. Especially at this point as we are just going to revert the multi MIME image generation for exactly that reason; I think starting with the media library may be a good approach if this additional processing is not a concern
      • @pbearne: it’s actually quite lite on upload compared to the rest of processing

Our next chat will be held on Tuesday, September 13, 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. Required fields are marked *