Performance team meeting summary 20 September 2022
Meeting agenda here and the full chat log is available beginning here on Slack.
Announcements
- @shetheliving: Mission and philosophies review
- Drafting a Handbook for our site
- Please review and leave comments on the doc with your thoughts
- Drafting a Handbook for our site
Focus group updates
Images
@adamsilverstein @mikeschroder
- @adamsilverstein: WebP feature was reverted following Matt’s post. Still trying to determine what a canonical plugin is and if it would work for WebP by default. Still have some fixes to land for 6.1 around image quality when WebPs are output via Performance Lab plugin.
- @spacedmonkey: Next steps for Dominant color feature
- We’ve run out of time to merge before Beta 1 cutoff
- Feedback process was a lot slower than we thought it would be
- Should continue to work on this and try to get it in for 6.2
- @pbearne: Version with theme flag could be merged
- @spacedmonkey: Merging now doesn’t feel great as there are still unanswered questions. Code is ready, but not sure what feedback will push this across the line. May need to push early in 6.2 cycle and see what happens.
- @flixos90: Feels like another merge proposal post with a concrete timeline on a merge date could be good to put out right after 6.1, so people can provide any additional feedback. Should also note the new theme support flag approach.
Feedback requested
- See above
- Needs Discussion (9 issues)
- Needs Review (2 issues)
- Needs Dev (1 issue)
Object Cache
- @mehulkaklotar: Working on #53450 and it is ready for review here
- @spacedmonkey: Merged:
- @spacedmonkey: Focusing on dev notes next week
Feedback requested
- See above
- Needs Discussion (4 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: #56040 and #56041 (two Site Health checks from Performance Lab) have been merged for 6.1 and dev notes are in progress
- @mukesh27: PR #543 for adding
can-load.php
to these Health Checks is ready for review
Feedback requested
- Needs Discussion (8 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.
- @flixos90: Working on a proposal to integrate the Server Timing API into Performance Lab. We have a lack of awareness for how WP is performing server-side and this simple piece of infrastructure would allow us to measure specific features/modules of the plugin to see who they are affecting PHP performance. Should an open an issue this week or next.
- @mehulkaklotar: Continuing to work on a proposal for the plugin performance checker tool
Feedback requested
- Needs Discussion (5 issues)
- Needs Review (1 issue)
JavaScript
- N/A
Feedback requested
- Tree-shaking block styles on the frontend #41020
- Needs Discussion (2 issues)
- Needs Review (3 issues)
Infrastructure
- Bumping minimum requirement to WP 6.0 – @flixos90
- @olliejones: Stats show that 44% of sites are on pre-6.0 versions, does it make sense to leave them behind?
- @flixos90: Because this is a feature plugin, implications here are quite different from WP overall – see https://github.com/WordPress/performance/blob/trunk/docs/Version-support-policy.md#wordpress-core-versions
- @masteradhoc: Don’t think a lot of users on older versions would be using a feature plugin, seems like a different target group
- @markjaquith: Yeah, suspect that the sites using this plugin are more likely to be using 6.0x and even if not, the goal of the plugin is to move things forward
- @robinwpdeveloper: Also think this is a good call
- Vote here by next Friday, September 30
- @flixos90: Ran into this bug yesterday during the release, which we should fix before the next one
- @mukesh27: Fix broken command for readme changelog #542 and Add JavaScript coding standard workflow #515 need review
Feedback requested
- See above
- Needs Discussion (5 issues)
- Needs Review (3 issues)
- Needs Decision (1 issue)
Discussion: Module proposal: Optimized autoloaded options
- Options are autoloaded by default, and most options stay autoloaded even after the plugin or theme that uses them has been deactivated
- This autoloading has a cost in terms of the performance of the query that loads autoloaded options, and also because the values of these options are kept in memory
- Discussed a lot of ways of addressing this at WordCamp US, and the most promising path that would have the most benefit for the most users (and fits in with this group’s philosophy on focusing on automated fixes instead of introducing new APIs) is to dynamically move options in and out of the “autoload” pool based on usage
- Options that are used *and* are not past a certain size cutoff should be autoloaded, but large options and options that are not used, should not be autoloaded
- Proof of concept is linked in the ticket and we’re looking for additional feedback
- @pbearne already brought up the issue of options that are queried BEFORE a module could start “listening” for them to be called, but there are undoubtedly other gotchas and opportunities here
- Especially useful would be help in developing a strategy for measuring the performance of this fix for various sizes of autoloaded options
- @flixos90: Could leverage the Server Timing API (noted above) to measure the time the autoloaded options query takes, for example
- @pbearne: Think that both @markjaquith‘s and my fixes can be used as they work best for different configurations
- @spacedmonkey: Could we start adding a limit to the number of autoloaded options, say 250 rows? Or is the issue size in terms of memory?
- @pbearne: If we can load just what we need, the SQL time is less
- @markjaquith: We do this to avoid hundreds of individual queries
- @rickjames: Is “autoloading” the thing that PHP can do for include files? I thought it was so slow as to be better to always include everything
- @markjaquith: No, this is about quering the
wp_options
table forautoload = 'yes'
- @markjaquith: No, this is about quering the
- @rickjames: That gets to the lack of adequate indexes for the
wp_options
table; a simple change can speed upSELECT
s- @markjaquith: There’s already an index, it’s more about the volume of data being transferred
- @eugenemanuilov: Think we should move from defining which option is autoload-able in the database table to the option registration in WP, so a plugin/theme owner will need to register an option similarly to how settings are registered with
register_setting
and define whether an option is autoload-able there - @flixos90: Both proposals at a high level have the idea of querying what is needed, but the newer proposal does it globally while still keeping a single place of storage while the latter was aimed at having different “options lists” per template/page. The latter would be great, but it comes with heavy storage implications, so the newer proposal is probably the best place to start since it has no additional storage implications.
- @markjaquith: Do think that the issue is data, not rows – evicting autoloaded options could help wtih both
- @rmccue: Have run into performance problems with pulling autoloaded options from object cache, so agreed that this is an issue
- @markjaquith: Also issue with memcache’s default config being size-limited
- @spacedmonkey: Could we use
register_settings
to define if an option should be autoloaded?- @markjaquith: Won’t help existing sites
- @rmccue: Core problem is that
autoload
is true by default, which is what causes issues - @markjaquith: Two approaches – @pbearne optimized for “literally just what this page needs”; my POC was for “never autoload things that aren’t used”
- @spacedmonkey: So will we store an array of used options in options table?
- @markjaquith: Current implementation only stores timestamp of last calibration, but with some additional storage we could minimize dynamic re-adding of autoloaded options
- @rmccue: Autoloading options should minimize DB/cache calls, but not necessarily replace them. The heuristic of what should be autoloaded is key to this proposal.
- @markjaquith: To me, it’s “things that are used and aren’t unreasonably large.” Can also honor
autoload='no'
while not honoringautoload='yes'
as chosen by developers.
- @markjaquith: To me, it’s “things that are used and aren’t unreasonably large.” Can also honor
- @spacedmonkey: Don’t love the idea of storing an array of keys. How do you generate the array? What is the average page load?
- @rmccue: To move forward, we need a concrete proposal for how the heuristic works. Will look into the network saturation problems we’ve run into get an idea of what “unreasonable” might lok like.
- Next steps: @markjaquith will work on detailing the heuristic further in #526 and when it’s ready, we’ll schedule another discussion for a future chat
Our next chat will be held on Tuesday, September 27, 2022 at 11am EDT in the #core-performance channel in Slack.
#core-js, #core-media, #performance, #performance-chat, #summary, #hosting-community