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
- @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
- See above
- Needs Discussion (8 issues)
Object Cache
- @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
- See above
- 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
- @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
- 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?
- @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
- Have a bunch of SQL server tests that say “ask your hosting provider to…” – should we abandon those?
Feedback requested
- Needs Discussion (7 issues)
Measurement
N/A
- 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
- Needs Discussion (5 issues)
- Needs Review (1 issue)
JavaScript
- @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
- Tree-shaking block styles on the frontend #41020
- Needs Discussion (2 issues)
- Needs Review (3 issues)
Infrastructure
- @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
- See above
- Needs Discussion (4 issues)
- Needs Review (1 issue)
- Needs Testing (1 issue)
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?
- @alaca: Not sure
- @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
- @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:
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