Performance team meeting summary 9 August 2022

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

Announcements

  • @shetheliving: Team Rep elections
    • We’ll follow the process previously used by the core team, outlined here
    • Bethany will add a nominations post to https://make.wordpress.org/performance/ this week

Focus group updates

Images

@adamsilverstein @mikeschroder

GitHub project

  • @adamsilverstein: Working to complete several follow-up patches for WebP support. A couple of small fixes were committed last week, and the remaining patches are on track to land in the next week. The Pull Requests section at the top of https://core.trac.wordpress.org/ticket/55443 is a good way to check progress, since follow-up patches are boing worked on in PRs linked to this ticket.
  • @mukeshpanchal27: Working on:
    • Core patch follow-up – WebP compatibility: add fallback for non-supporting browsers to core – PR #3034 ready for review
    • Enhance JS replacement mechanism for WebP to JPEG to more reliably replace full file name – Merged in plugin
  • @erikyo: Noting that WebP conversion feature currently only works for JPGs, but in the future hope to also use PNG with Performance Lab and maybe a way to filter the input format is needed
  • @adamsilverstein: If you used the mapping to create WebP from PNG uploads, the replacement code won’t work. We should be able to address, though our initial implementation is focused on JPEG > WebP. @erikyo will comment on the linked PR for further discussion.
  • @mehulkaklotar: Working on core patches for WebP uploads, ready for review: https://github.com/WordPress/wordpress-develop/pull/3030 and https://github.com/WordPress/wordpress-develop/pull/3048. Also working on https://core.trac.wordpress.org/ticket/45471 to allow caching of parse_blocks results.
  • @joegrainger: Working on plans for regenerate existing images module
  • @shetheliving: Should have a core feature proposal up for this in the next week

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

  • @spacedmonkey out through 5 September
  • @tillkruess: Merged two PRs last week: https://github.com/wordPress/wordpress-develop/pull/2967 and https://github.com/WordPress/wordpress-develop/pull/2969
  • @pbearne: Not sure where the dominant color proposal is going, do we have the support to get it into core? Want to make sure it’s moving along
    • @flixos90 to review PRs this week, but welcome others too, as well: https://github.com/WordPress/wordpress-develop/pull/2907 https://github.com/WordPress/wordpress-develop/pull/2906
  • @itmapl: Interested in resolving https://core.trac.wordpress.org/ticket/32052; PR is here: https://github.com/WordPress/WordPress/pull/610. Open to comments on the solution so we can move forward.

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
  • @shetheliving: Discussion in #326 Update Settings language for health checks. #423 about naming conventions; @olliejones will update the PR
  • @furi3r: Working on porting Site Health modules to core and there’s some new feedback in https://github.com/WordPress/wordpress-develop/pull/2890 and https://github.com/WordPress/wordpress-develop/pull/2894 which is raising some concerns:
    • Asking to move Object Cache Check to Async test. Should we do this on the plugin level first and then move it to core, or directly there?
      • @shetheliving: Thinking we should update in the plugin first, then port to the core PR once it’s merged; @flixos90 agrees
    • Use of custom filters, instead of using site_status_test_result filter.=
    • Asking to remove the color scheme we have used for alerts (green, yellow, green), and instead use same one for label (performance uses blue)
    • @adamsilverstein: Looks like valuable feedback on the PRs, suggest keep working there with @clorith and others to find a good solution
  • @olliejones: Still looking at the SQL database health checks. Pretty sure we can check for misconfigured/slow/ancient MySQL/MariaDB, but none of this is actionable by a site owner. Do we want to proceed with health checks that aren’t actionable by “typical” users?
    • @shetheliving: Based on our discussion last week, seems like no – we want to focus on health checks that are actionable by typical (i.e. not developers, not ops people) users
  • @olliejones: Is there any way to move forward with MySQL optimization work in a way that can make it to core eventually?
    • Have a bunch of SQL server tests that say “ask your hosting provider to…” – should we abandon those?
      • @shetheliving: Those are okay because they provide an action that anyone can take, asking their hosting provider
      • @flashusb agrees
    • @zero4281: Does the Health Check module have hooks to add in additional more advanced health checks? If it did, Ollie could add those checks to his custom plugin
      • @flashusb: Yes, there is a hook to add custom checks, not a separate tab though
    • @furi3r: Agree we should expand Site Health use to more technical users, maybe a new tab? If we want to achieve bigger results, we shouldn’t limit ourselves
      • @ankitgade: Could be a separate tab, something like “Advanced Site Health Check”
    • @olliejones: Would be great to find a way to address these MySQL optimization issues, maybe the Woo team should address it?
    • @johnbillion: Did you move the MySQL optimization work to your plugin?
      • @olliejones: Yes, been in the plugin for over a year now. Can add custom health checks just like Yoast did.
      • @johnbillion: Think the best approach is to continue work in the plugin, including the health checks, and propose any changes that need to be made in core to facilitate them
      • @olliejones: There are possible core changes but they’re very difficult to pull off because many users are still stuck on MySQL 5.5
      • @johnbillion: Happy to review the plugin and help create performance benchmarks for the changes

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
  • @shetheliving: Reminder about the performance testing environment work started back in March: https://make.wordpress.org/core/2022/03/22/performance-team-meeting-summary-22-march-2022/. This has stalled out since then; if anyone is interested in picking it back up, let us know.

Feedback requested

JavaScript

@aristath @sergiomdgomes

GitHub project

  • @adamsilverstein: Resource preloading landed in https://core.trac.wordpress.org/ticket/42438. Some follow-up work for this work includes considering a more declarative API (currently it is implemented as a filter) and first party usage, e.g. applying preload to core resources in both wp-admin and (core) themes

Feedback requested

Infrastructure

@flixos90

GitHub project

  • @flixos90: Notable PR is https://github.com/WordPress/performance/pull/458, which enhances plugin uninstall to better support multisite. Next Performance Lab 1.4.0 will be released on Monday; please finalize any PRs by tomorrow.

Feedback requested

Open Floor

  • @shetheliving: I’ll be offline on medical leave August 22 through September 9; please ping @flixos90 or @mukesh27 during that time if you need help with anything
  • @alaca: SVG uploads
    • @alaca: Would like to discuss possible approaches. The idea to allow only static XML files for now is great, but I think we can do more – which depends on the approach we want to take when detecting the dynamic file. Two possible approaches:
      • 1) We have a list of keywords that shouldn’t be in the document, we can just check that, and prevent document upload if we find something inside the document
      • 2) Parse the document to see what’s in there, but then we have an opportunity to do more, such as sanitization.
    • @alaca: Each one of the third party solutions out there is using the same library for SVG sanitization; it’s great and battle tested. Want to use the same approach and simplify the implementation a bit with one simple class.
    • @olliejones: Are there exploit vulnerabilities stemming from parsing XML?
    • @masteradhoc: Want to be able to upload any SVGs that I have and have WP sanitize them for me if there’s an issue
    • @erikyo: I use a completely different approach in https://github.com/erikyo/OH-MY-SVG; they aren’t stored in the Media Library, but there are advantages like being able to edit them
    • @masteradhoc: Think not having them in the Media Library would be confusing
    • @erikyo: If they’re stored in the Media Library they can be processed by ImageMagick

Our next chat will be held on Tuesday, August 16, 2022 at 11am EDT in the #core-performance channel in Slack.

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

Leave a Reply

Your email address will not be published.