Performance Chat Summary: 18 October 2022
Meeting agenda here and the full chat log is available beginning here on Slack.
Announcements
- @shetheliving: Reminder: Focus area updates vote and call for leads
- @shetheliving: Upcoming time change
- Europe changes w/c 30 October before US does – Nov 1 meeting will be one hour later at Tuesday, November 1, 2022 at 12:00 PM EDT
- US changes w/c 6 November – meeting will shift ahead by one hour to stay at our regular time, so Nov 8 meeting will be at Tuesday, November 8, 2022 at 10:00 AM EST
- @shetheliving: New Handbook on our Core Performance site
- Some new content, some ported over from the
/docsfolder of the Performance Lab plugin. If you have changes or updates, please contact Bethany directly; workflow for updates to come. - @flixos90: All new documentation related to Performance Lab should go into this Handbook, not
/docsas that folder has been removed
- Some new content, some ported over from the
Focus area updates
Images
@adamsilverstein @mikeschroder
- @flixos90: Found a bug during yesterday’s release party where the WebP upload configuration checkbox is not displaying in Settings > Media on multisites
- @joegrainger: #527 and #537 we’re part of the 1.6.0 release yesterday, which bring us to parity with the planned WebP implementation in core
Feedback requested
- See above
- Needs Discussion (9 issues)
- Needs Review (1 issue)
Object Cache
- @spacedmonkey: Just committed https://github.com/WordPress/wordpress-develop/commit/7b176e6deaeb54249f7096c8ef8415d3edb46e39
- @spacedmonkey: Spent some time testing RC2 and seeing better numbers for page performance than for Beta2. Regression appears to have come from a change to PHP related to Gutenberg. Numbers are better than Beta2 but not as good as 6.0 – 0.6325s for Beta2, 0.4014s for RC2, and 0.2929s for 6.0.
- @flixos90: We’ve been working on a separate performance analysis comparing 6.1 RC1 to 6.0 and will follow up today to do RC2. Unfortunately results haven’t been looking as good as 6.0 in our analysis, either. Hopefully RC2 is improving in our tests, too.
- @spacedmonkey: Have been using Blackfire for testing. You can get a free open source license; if anyone is interested, can help them get set up.
- @flixos90: Been using WebPageTest in combination with custom-measured
Server Timings, so these two analyses can complement each other well. - @spacedmonkey: Don’t think we will have time to fix these issues before 6.1 release; these would require big changes so doesn’t feel like a good idea to get merges committed without testing. Maybe possible for 6.1.1.
- @aristath: Been using Xdebug and webgrind and pushed a few tweaks to core in the last few weeks as the result of those tests. Setup instructions are here if anyone’s interested in getting started easily.
- @johnbillion: For anyone who wants timing information and doesn’t have access to Xdebug/Cachegrind/XHProf/Blackfire etc., you can do rough timing with the Query Monitor plugin
- @spacedmonkey: One issue I’ve found is that a lot of code related to
theme.jsonis being loaded even if the active theme does not support these features - @mukesh27: Agreed
- @spacedmonkey: Would like to work on conditionally loading these features on classic themes; much of this has been an issue since 5.9
- @johnbillion: There are a few issues on that topic in the Gutenberg repo, e.g. https://github.com/WordPress/gutenberg/issues/38299
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: Yesterday’s Performance Lab release included functionality to only load the two new SH checks that will be in 6.1 (persistent cache and full page cache) when they are not available in core: https://github.com/WordPress/performance/pull/543
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
Feedback requested
- Needs Discussion (5 issues)
- Needs Review (1 issue)
JavaScript
- No updates
Feedback requested
- Tree-shaking block styles on the frontend #41020
- Needs Discussion (2 issues)
- Needs Review (3 issues)
Infrastructure
- @flixos90: Got 4 non-critical debug warnings during the release deployment yesterday, which we should look into: https://github.com/WordPress/performance/issues/561
- @flixos90: Want to highlight the
Server-TimingAPI proposal again. Been working on a proof of concept in https://github.com/WordPress/performance/pull/553 which would be great to get some first reviews on. Also added some example usage code and linked a Gist with several examples for how we could leverage that API to expose specific timings. Exact API seems a bit clunky to use and already have some ideas on how to simplify it better to fit the usage. Still works well technically though, so it’s okay to be reviewed.
Feedback requested
- See above
- Needs Discussion (6 issues)
- Needs Review (3 issues)
Module proposal: SQLite – @aristath
- @shetheliving: Related to the broader proposal to make WP officially support SQLite
- @aristath: The SQLite implementation can be found on the PR linked above. A couple of minor issues with the implementation, but they don’t have anything to do with the SQLite code itself. The issues I have in that PR are related to the module’s activation and deactivation: when enabling/disabling the module, WP switches DBs and subsequently all options regarding the activation/deactivation of the module are difficult to handle because on option-save, we switch databases. It’s a solvable UX issue, but could definitely use some assistance. At this stage, believe it’s time to start collaborating on the PR, test it, and merge relatively early so we can urge more people to test.
- @flixos90: Re-sharing one idea mentioned when discussing this previously (see Slack): Present a warning that this will result in an empty DB. If the user clicks Activate, show a modal where they have to enter SQLite config data, then put that into
wp-config.phpand install the DB before they activate. This way, they could remain on the same screen and continue to use WP or deactivate if they want to. Would avoid an overly confusing experience. - @aristath: Added a note next to the module (not a modal). SQLite doesn’t currently require any user-provided config, so didn’t want to make things more complicated. Agree that we should have something more user-friendly and be clear about what will happen and why.
- @flixos90: So there would not be any constant to add to
wp-config.php? - @aristath: At this stage, no – the module automatically copies a
db.phpfile inwp-content, assuming that if the file is there, you want to use SQLite. On deactivation of the module, the file is deleted so you go back to your MySQL database. - @flixos90: There are other use-cases for
db.php, though, so wary of the existence of the file being the only thing that we rely on. Should probably also back up any existingdb.phpfile in case and restore it on deactivation of the module.- @rickjames: Will there be a migration path from SQLite to MySQL? Thinking of a case where someone starts out with a “small” site but it grows “too big” for SQLite
- @aristath: If SQLite is included in core, there will definitely be a migration path. Most likely it would be in the form a canonical plugin and not core. Don’t think it will be the nightmare we envision it to be – just connect both DBs and copy data between them.
- @aristath: If they have a different
db.phpfile, then they’re already using a custom DB somehow – if it’s detected, the module does not overwrite and instead exits
- @rickjames: Will there be a migration path from SQLite to MySQL? Thinking of a case where someone starts out with a “small” site but it grows “too big” for SQLite
- @rickjames: Don’t think there is any way to keep the DBs “in sync”
- @aristath: There is a way, but wouldn’t want to do it. This is intended to be a module to test the stability of SQLite in WP and work toward implementation in core. Not intended to take care of syncing dbs, using them to back up data, etc.
- @shetheliving: Feel free to leave comments on https://github.com/WordPress/performance/pull/547 and we can always discuss this further in a future chat, as well
Our next chat will be held on Tuesday, October 25, 2022 at 11am EDT in the #core-performance channel in Slack.
#core-js, #core-media, #performance, #performance-chat, #summary, #hosting-community
