Performance team meeting summary 3 May 2022

Performance team meeting summary 3 May 2022

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

Focus group updates

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

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
  • @furi3r: PR for Site Health test for full page caching is still open; would love another review to get into the next release@flixos90 will take another look
  • @flixos90: Is there any update on the work to refine the two existing experimental Site Health modules to make them non-experimental and eventually merge to core?
    • @furi3r: We should go over them again and take another look
  • @spacedmonkey: Should we use next week’s meeting to decide what we want to get merged into 6.1
    • @flixos90: Great idea, as well as looking owners for whatever we decide on

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
  • No updates

Feedback requested

JavaScript

@aristath @sergiomdgomes

GitHub project

  • No updates

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90: Decision has been made to follow WP core’s versioning approach for our plugin based on the vote in Define plugin versioning approach #300, so next release will be 1.1.0.
  • @flixos90: The other decision we need to make is about release cadence in Define plugin release cadence #320.
    • Before 1.0.0, we published every two weeks, which is the minimum but requires some additional maintenance and overhead, so a timeline of four weeks or more is probably better. At the same time, we don’t want to go too long and lose momentum.
    • @adamsilverstein: Monthly feels straightforward to keep track of; longer gets more difficult
    • @pbearne: A 4 week cycle feels right to me
    • @eugenemanuliov: Yes, 4 weeks seems to be most appropriate
    • @jeffpaul: 10up open source team checks what’s releasable on the first day of the month and determines if it requires a major, minor, or no release. If there’s a release, it’s done in a subsequent week that month.
    • @flixos90: Could also do monthly, e.g. third Monday of the month. Will add to the options in the issue.
    • Vote is open here until next Monday

Feedback requested

Open floor

  • @jb510: Research: Impact of additional WebP images on upload #289 focuses on the file system impact of WebP. But when an image is uploaded to a post, there is the time it takes the original to upload, but then the user has to wait while additional image sizes are generated and the progress bar for that action completes. We should then consider the impact of WebP generation has on that already sometimes frustrating delay between generating JPEG only vs JPEG+WebP. Want to make sure this is being considered. I recommend moving this to the background.
    • @jeffpaul: Agreed, that UX is quite painful
    • @adamsilverstein: Moving to the background would make sense, as that image generation is slow and can break if you navigate away from the editor. Related Gutenberg issue.
    • @adamsilverstein: Note that the progress bar only shows upload progress, not processing progress
    • @pbearne: Once WP has the image, we should be able to release the editor and do the processing in a new thread
    • @jb510: For scope, consider 1) measuring impact of additional processing/completion time due to WebP and 2) finding a way to move that out of blocking the user from continuing with what they wanted to be doing

Help wanted

#core-js, #core-media, #performance, #performance-chat, #summary

Leave a Reply

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