Performance Chat Summary: 14 March 2023
Meeting agenda here and the full chat log is available beginning here on Slack.
Announcements
- As agreed in last weeks chat, this week we are following the new agenda structure below that is more aligned with our 2023 roadmap
- During each priority project update, we will aim to tag the individuals who contributed suggestions for that priority project in the 2023 roadmap, to get any updates on progress
Priority Projects
Server Response Time
Contributors: @joemcgill @spacedmonkey @aristath
- @joemcgill Following a week of recovery from a bike accident, I’ve resumed working on gathering some profiling data on the most recent release candidate. I’m hoping to wrap up that work this week and have some new ideas to focus on for the 6.3 cycle
- @spacedmonkey committed:
- https://github.com/WordPress/wordpress-develop/commit/2724a495afb2f7c60d4b2c6b9158c4c82973fb58
- https://github.com/WordPress/wordpress-develop/commit/befb493339512a862a61c16a8a92b5745ee6a109
- https://github.com/WordPress/wordpress-develop/commit/4af22e53d71c23403de49479c2dfe31dd0ba0c05
- https://github.com/WordPress/wordpress-develop/commit/82cd43419448c343cc3df41f6e37c6185e480038
- https://github.com/WordPress/wordpress-develop/commit/c421c7ead6c72ebb448c7a21f6bef3acfaab6a92
- https://github.com/WordPress/wordpress-develop/commit/dbbc9bcf98787fd77fd920df84cc9bbc69974b0a
- @spacedmonkey requested code reviews:
- Fixes an issue with bootstrapping scripts in widgets slowing down bootstrap
https://github.com/WordPress/wordpress-develop/pull/4170 - Improves Query and use of date functions.
https://github.com/WordPress/wordpress-develop/pull/4230 - Tracking a performance regression in 6.2 RC
https://github.com/WordPress/wordpress-develop/pull/4235
- Fixes an issue with bootstrapping scripts in widgets slowing down bootstrap
- @spacedmonkey also working on https://core.trac.wordpress.org/ticket/57814
Database Optimization
Contributors: @aristath @spacedmonkey @olliejones @rjasdfiii
- @olliejones Work on the SQLite database integration continues. Lots of tiny details transliterating one irregular SQL grammar to another. Nothing big to report.
JavaScript & CSS
Contributors: @mukesh27 @10upsimon @adamsilverstein
- @10upsimon We’re making progress on some of the final implementation details related to handling inline scripts, and doing some internal testing and research into how other projects are already implementing async/defer to look for possible conflicts. We should have something to share in a couple of weeks. In the meantime, we’d appreciate any examples you have of projects that are manually adding async/defer, so we can check them against our approach.
Images
Contributors: @flixos90 @thekt12 @adamsilverstein @joemcgill
- @flixos90 I have been researching remaining problems with lazy-loaded LCP images in WordPress sites in the last week, will continue to do so today. I’m using HTTP Archive to identify the most common problems and look at specific sites for samples to dig further
- @flixos90 Noting that the enhancements that will hopefully come out of this work will benefit the
fetchpriority="high"work as well - @adamsilverstein quick update from me: at WordCamp Asia a few weeks ago, I ran an “image comparison game” where users picked from two images (generated in WordPress at different compression levels and in WebP or JPEG) trying to tell which one was closer to the original. we had around 50 “choices” registered which isn’t much, but in any case I’m planning to analyze that data this week and should have some sort of results to share next week.
Measurement
Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27
- @clarkeemily we did have ‘Automated performance testing has been committed to the WP core repo https://core.trac.wordpress.org/changeset/55459‘ highlighted last week
- @joemcgill We’re successfully getting automated performance data on every commit to core now, which is a cool milestone. I expect that we’ll continue to improve those capabilities over time, but this is a nice starting point.
Ecosystem Tools
Contributors: @joegrainger
- @joegrainger We plan to complete the infrastructure for the Plugin Checker by the end of next week. Once complete we will start to perform some initial testing and review the infrastructure before working on the additional checks. Progress can be seen on the GitHub repo here. Please feel free to take a look and leave any thoughts/ideas you may have in the repo.
Creating Standalone Plugins
Contributors: @flixos90 @mukesh27 @10upsimon
- @mukesh27 and @10upsimon are working on Milestone 1 tasks for Creating standalone plugins, and we are on track to complete engineering by the end of this week or early next week. If anyone has some time, then review PRs at https://github.com/WordPress/performance/pulls?q=is%3Apr+is%3Aopen+label%3A%22Creating+standalone+plugins%22 and share the feedback.
- @flixos90 I have been reviewing some of the existing PRs in Milestone 1 and will work on a PR for https://github.com/WordPress/performance/issues/667 today
New Projects / Proposals
- n/a
Open Floor
- @spacedmonkey Can we talk about this – ‘Explore and assess 6.2 server-side performance regressions‘ https://core.trac.wordpress.org/ticket/57916
- @flixos90 Happy to answer any questions on the data I gathered
- @spacedmonkey Doing some research, realpath seems to be taking up a lot of resources
- @flixos90 Is the
realpath()usage something that was introduced in 6.2? - @spacedmonkey No, but I think it has been made worse.
- @joemcgill After thinking about the original issue some more, I’m wondering if what @flixos90 observed is mainly a side-effect of things being moved around in the application lifecycle, which means that there are more callbacks firing on init, but overall the total response time is still an improvement over 6.1.X.
- @flixos90 The overall total response time for classic themes is now actually worse in 6.2 than 6.1
- @joemcgill That’s not what I’m seeing in our automated tests though.
- @spacedmonkey It might be related to this – https://github.com/WordPress/wordpress-develop/commit/6d0a691b84d411813378f1983a0a87bf78a1ccad
- @flixos90 Yeah I also didn’t see that in my previous tests. However what I have consistently seen is
initbeing slower than in 6.1 - @flixos90 FWIW, the automated tests are running core
trunk. The tests I have been conducting are using built ZIP releases of the Betas and RCs. Not sure how relevant that is, but it may make a difference - @joemcgill Even in the latest run, 6.2 seems like an improvement.
- @flixos90 The ZIP files are in principle closer to the real world experience, that’s why I’ve been using them in addition to the development repository
- @spacedmonkey my test runs Slack thread
- @joemcgill Zips should be built from the build folder, which is what the automated tests are testing
- @flixos90 request for @spacedmonkey or @joemcgill to run the comparison between 6.1.1 production ZIP and 6.2-RC1 ZIP on your machines? Just to validate, maybe something is off on my environment
- @joemcgill Happy to double check using local profiling at the beta tester plugin later today.
- @spacedmonkey I might try using Local envoirment and other tools and see if i can reproduce
- @johnbillion Are all these tests using the theme unit test data?
- @spacedmonkey I use Fakerpress to make mock data
- @joemcgill The automated tests are. Not sure about how others are testing.
- @flixos90 Good call @johnbillion My own local performance testing I’ve done only with the regular WP content (“Hello world”), nothing added. I know that’s not representative of real-world experience, but @joemcgill and @spacedmonkey please try to use that too for specifically the attempt to validate what I’m seeing on my end
- @joemcgill If other folks can do A/B comparisons of the total response time for WP 6.1.1 vs 6.2-RC1 and share data on that issue, it could certainly help.
- @spacedmonkey Fakerpress is great for generating posts from multiple authors, adds comments, terms and users.
- @flixos90 So to summarize, just to reproduce, I’m seeing the regression locally in this environment:
- between 6.1.1 and 6.2-RC1
- a site with LocalWP
- using TT1 theme
- using Performance Lab plugin for Server-Timing, with no modules enabled
- no content on the site other than what a clean WP core install gives you
- Also see this sheet for more details.
- @johnbillion Are you able to test again with the theme unit test data Felix? That way we have a somewhat unified set of data that’s in use for the tests
- @flixos90 I certainly can. That said though, we also would still need to validate why I see a regression with the default content, so I would appreciate if someone else could run that on their end
- @spacedmonkey https://codex.wordpress.org/Theme_Unit_Test
- @flixos90 Last but not least, I want to highlight something here (which I tried to also call out on the ticket): Regardless of whether WP 6.2 is faster than 6.1,
initis slower than before for classic themes. That has surfaced in all performance benchmarks I have done up to date. So while we should validate the overall test results, we should look into what is going on ininitand why it has become worse in 6.2 - @flixos90 See https://docs.google.com/spreadsheets/d/1LroIJoYz-O9CpfJzaiKYYMWJ7GbE5RZoW1rf1R4FqyA/edit#gid=0 for example. In my new data https://docs.google.com/spreadsheets/d/1LroIJoYz-O9CpfJzaiKYYMWJ7GbE5RZoW1rf1R4FqyA/edit#gid=1935935734 this is just more pronounced (which again could be due to a problem on my setup that wasn’t there before). If you want to get those more detailed Server-Timing metrics in your local environment, you can use https://gist.github.com/felixarntz/63c05392dbf7d51cc7f8f4a424b1ff39 for example
- @joemcgill Back to my initial comment. I am curious if this is a side effect of some things being refactored during this release which has caused more work to be done on the init callback that was previously happening elsewhere. It could be that it’s fine that we’re doing more work on init than we were before if the overall execution time is improved.
- @flixos90 Potentially that’s the case, in which case the “regression” would be fine. But we need to validate that
- @joemcgill I think it would be helpful to review what is hooked to init in 6.2 vs 6.1 and compare differences.
- @flixos90 I did that in https://docs.google.com/spreadsheets/d/1OCfHtty6__DZPkPeOrMTBJiPPH46Lwd1AdofvUA4bnE/edit#gid=879358988
- @spacedmonkey register_block_type_from_metadata -> register_block_script_handle -> realpath. register_block_type_from_metadata Are hooked into init
- @flixos90 So we need to check how those functions’ code changed
- @johnbillion Briefly from me for a core issue related to performance: I’ve been working to remove use of the now-deprecated
SQL_CALC_FOUND_ROWSin core, starting with its use inWP_Query. PR here: https://github.com/WordPress/wordpress-develop/pull/3863 which continues work from a couple older PRs. There are a few outstanding items to address, I might ask for some help from interested parties on the performance team if I can’t make much progress myself over the next few weeks. Apart from that, the more eyes the merrier on this change! - @flixos90 Last but not least: Next Monday is the release of the Performance Lab plugin 2.1.0, so we need to get a few PRs ready
- @flixos90 I have been working on a fix for the
object-cache.phpcompatibility issues which I’m about to open a PR for. Would be great to get some reviews today/tomorrow so we can include it in 2.1.0
Our next chat will be held on Tuesday, March 21, 2023 at 16:00 UTC in the #core-performance channel in Slack.
