Performance team meeting summary 28 June 2022

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

Table of Contents

Toggle

Focus group updates

@spacedmonkey: Working on https://github.com/WordPress/gutenberg/pull/40656 and need review on:
@spacedmonkey: Also been contacting hosting companies and asking about object cache implementations. There are a number of hosts who don’t have the latest improvements to object caching like wp_cache_get_multiple. Been contacting them and advising them about the performance improvements that would come with implementation. Implementation eamples: https://github.com/Automattic/wp-memcached/pull/88 and https://github.com/Automattic/wp-memcached/pull/87; recommend Redis Object Cache plugin for Redis

Feedback requested

See list above
Needs Discussion (3 issues)
Needs Review (3 issues)

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: Working on porting Full Page Cache and Persistent Object Cache Health Checks to core in https://github.com/WordPress/performance/issues/391 and drafted proposal post here for review; also pinged the Site Health maintainers to keep them in the loop

Feedback requested

Needs Discussion (5 issues)

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
@flixos90: Working on a blog post for Make about the plugin checker proposal

Feedback requested

Proposal for plugin checker
Measurement overview doc
Capturing front-end performance metrics in WordPress doc (for #s 63/64)
Needs Discussion (5 issues)
Needs Review (1 issue)

JavaScript

@aristath @sergiomdgomes

GitHub project

No updates

Feedback requested

Tree-shaking block styles on the frontend #41020
Needs Discussion (2 issues)
Needs Review (3 issues)

Infrastructure

@flixos90

GitHub project

@shetheliving: Submitted a new PR to update our GitHub Workflow doc with clarification around adding milestones or no milestone to issues and PRs
@flixos90: Released 1.2.0 last Tuesday. Found a few minor Infrastructure bugs during the release party (first three issues in this list, one of which already has a PR). @mukesh27 is also working on Implement mechanism to not load module if core version is available #390, which will give modules control about whether they should load based on current environment factors in a way that makes it apparent to users
- @olliejones: One factor to keep in mind is MySQL/MariaDB version
- @flixos90: New infrastructure is primarily checking to see if something is in and loading via core, so it shouldn’t be loaded via the plugin – but it’s agnostic, so it could check those things
@spacedmonkey: Should we run PHP unit tests against different versions of PHP?
- @flixos90: Good question, worth opening an issue about
- @spacedmonkey: Would be especially useful for #381 Optimize computing dominant color and transparency for images by combining the two functions to ensure that different versions of PHP don’t affect the results of color generation. Core tests against PHP 5.6-8.1.
- @flixos90: Suggest opening an issue to work on it, then we can expand the test coverage for Dominant Color accordingly. Maybe not for every PHP version as that would make tests take a very long time, but we could do certain versions (e.g. 5.6, 7.4, 8.1).

Feedback requested

Needs Discussion (3 issues)
Needs Dev (1 issue)

New module proposal: Performance-oriented indexing for WordPress database tables

@olliejones: Request reviews of the proposal, specifically the Decisions to make section:
- Unlike other modules, this one needs at least some dashboard user interface, to initiate the reindexing of the tables, and to complain if the tables use legacy storage features (MyISAM, COMPACT row format). Where do we put that user interface panel?
- Experience shows that the POC plugin’s wp-cli access is necessary on large sites to do the reindexing without timeouts. Should performance lab get wp-cli access? How about using WP_Cron?
- What should the module do on multisite installations?
@olliejones: This is a bit different from the existing plugin modules because it initiates an operation that might run for a long time – several minutes on a big site. WP-CLI has been very useful in proof-of-concept plugin and could use advice on how to proceed. Wonder if this should be run by the hosting community?
@spacedmonkey: Worth sharing with the hosting community channel?
- @olliejones: Can do that
@flixos90: Adding a UI shouldn’t be a concern for a Performance Lab module; Site Health is almost all UI. Feels like UI would probably be under Tools somewhere. Would it be technically possible to do this spread out through multiple web requests?
@spacedmonkey: Might need Site Health warning saying indexes are not in place
@olliejones: There’s a single ALTER TABLE SQL statement for each table and we need to add/drop all indexes in a single statement. Slowest/biggest table is usually postmeta.
@flixos90: How long would executing this query typically take? If too long, can this SQL statement be sent in a non-blocking way for the PHP process?
- @olliejones: Overall, a few minutes for a postmeta table with a couple of megarows. PHP’s SQL support doesn’t have any fire-and-forget or threading that I know about.
- @flixos90: If that’s true, not sure this would be feasible for core given they take so long to execute. My concern would be PHP timeout. If SQL execution takes several minutes, an AJAX request won’t work for most sites.
- @flixos90: Realistically we wouldn’t be able to send an AJAX request and in that request complete the execution of the SQL statement?
  - @olliejones: AJAX and/or WP Cron might work, but the AJAX request won’t finish until after ALTER TABLE finishes
@pbearne: For core these could run only for new sites and be worth it
- @spacedmonkey: Could adding indexes to new sites be a start?
- @flixos90: If we can determine support on site creation and do it only for new sites as applicable, could still be beneficial without having those concerns from slow SQL queries
@furi3r: How does WooCommerce do it? They run big DB updates on upgrades
- @olliejones: AFAIK, they’re in batches, but we can’t do that for reindexing
@spacedmonkey: See this as two problems: old sites vs. new sites. Changing schema for newly created sites is more simple
- @olliejones: Agreed, but old sites are the ones that have the huge pain points
@olliejones: Plugin already has the WP-CLI stuff, could that be put into a Performance Lab module?
- @flixos90: Since Performance Lab is for future core features, a WP-CLI command doesn’t qualify. Would potentially be a good contribution for the WP-CLI project, though. If we want to build something into core, it needs to work through what core offers, e.g. UI-triggered, AJAX, Cron, etc.
Will pick this back up next week