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 tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) the individuals who contributed suggestions for that priority project in the 2023 roadmap, to get any updates on progress

Priority Projects

Server Response Time

Link to roadmap projects

Contributors: @joemcgill @spacedmonkey @aristath

Database Optimization

Link to roadmap projects

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.

JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. & CSSCSS Cascading Style Sheets.

Link to roadmap projects

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

Link to roadmap projects

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 HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. 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 WordCampWordCamp WordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. 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

Link to roadmap projects

Contributors: @adamsilverstein @olliejones @joemcgill @mukesh27

  • @clarkeemily we did have ‘Automated performance testing has been committed to the WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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

Link to roadmap projects

Contributors: @joegrainger

  • @joegrainger We plan to complete the infrastructure for the PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 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

Link to GitHub overview issue

Contributors: @flixos90 @mukesh27 @10upsimon

New Projects / Proposals

  • n/a

Open Floor

  • @spacedmonkey Can we talk about this – ‘Explore and assess 6.2 server-side performance regressionshttps://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 init being 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 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 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 testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. 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 ticketticket Created for both bug reports and feature development on the bug tracker.): Regardless of whether WP 6.2 is faster than 6.1, init is 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 in init and 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_ROWS in core, starting with its use in WP_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.php compatibility 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.

#core-media, #core-performance, #performance, #performance-chat, #summary