[wp-trac] [WordPress Trac] #57916: Explore and assess 6.2 server-side performance regressions

[WordPress Trac]

#57916: Explore and assess 6.2 server-side performance regressions
----------------------------+----------------------
 Reporter:  flixos90        |      Owner:  flixos90
     Type:  task (blessed)  |     Status:  assigned
 Priority:  normal          |  Milestone:  6.2
Component:  General         |    Version:  trunk
 Severity:  normal          |   Keywords:
  Focuses:  performance     |
----------------------------+----------------------
 Over the past few weeks, I have been monitoring server-side performance of
 WordPress 6.2 Beta releases in [https://docs.google.com/spreadsheets/d
 /1LroIJoYz-O9CpfJzaiKYYMWJ7GbE5RZoW1rf1R4FqyA/edit#gid=0 this
 spreadsheet]. While there has been one known regression in #57648 that is
 acceptable temporarily (due to the nature of the change, and the root
 problem should be addressed in the near future), there are a few other
 regressions in server-side performance, specifically in the `init` action,
 that deserve some attention.

 Today I conducted another benchmark for 6.2 RC1 (see
 [https://docs.google.com/spreadsheets/d/1LroIJoYz-
 O9CpfJzaiKYYMWJ7GbE5RZoW1rf1R4FqyA/edit#gid=1935935734 this sheet] and
 unfortunately got worse results overall. Performance measurements
 fluctuate sometimes, so at first I thought this was random, but I got
 similar results, no matter how often I ran it. I used the same site and
 configuration for testing as I did before, but the numbers were different
 - even when I re-ran 6.2 Beta 3 benchmarks. While it is unclear to me
 still why the results now are so different from the previous analyses, one
 thing that is clear and now further emphasized by the new benchmark is
 that there are some **regressions in `init`: 3.47ms for a block theme and
 3.41ms for a classic theme**

 Those regressions were not as clearly visible in the previous benchmarks.
 While we don't know at this point exactly which of the two numbers we
 should trust, it is worth noting that these regressions also impact
 overall load time:
 * TT1 (classic theme) loads **4.29ms slower in 6.2-RC1 than in 6.1.1**.
 * TT3 (block theme) still loads ~25ms faster in 6.2-RC1 than in 6.1.1
 (which is a great win), yet the previous benchmarks had indicated a far
 better ~34ms difference.

 In order to get more insights on the `init` performance regression, I ran
 another benchmark with a more detailed breakdown that includes metrics for
 every single callback that is hooked into the `init` action, which can be
 explored in
 [https://docs.google.com/spreadsheets/d/1OCfHtty6__DZPkPeOrMTBJiPPH46Lwd1AdofvUA4bnE/edit
 this spreadsheet].

 The primary areas causing the slowdown in `init` performance are:
 * The `wp_widgets_init()` function (mostly the `widgets_init` action):
 **0.92ms** slower for classic theme, **2.05ms** for block theme
 * The `WP_Block_Supports::init()` method: **0.71ms** for classic theme,
 **0.87ms** slower for block theme
 * The `register_core_block_types_from_metadata()` function: **0.21ms**
 slower for classic theme, **0.86ms** for block theme
 * The `register_core_block_patterns_and_categories()` function: **0.2ms**
 slower for classic theme, **0.25ms** for block theme

 Given that there are 2 new block types being registered with server-side
 logic in this release (`core/heading` and `core/post-author-name`) and
 given the general addition of a few block types, there is a good chance
 that especially the last two points above are affected by those, which is
 probably acceptable. After all, features come at a cost, and that is
 certainly justifiable. However, some of those regressions seem
 unnecessarily large. We should explore particularly why
 `wp_widgets_init()` and `WP_Block_Supports::init()` are that much slower
 than they were in 6.1.

 For block themes only, it is also worth noting that a few block
 registration functions see a notable regression (which ''do not'' see this
 regression for classic themes):
 * `register_block_core_heading()`: **0.34ms** slower
 * `register_block_core_post_navigation_link()`: **0.21ms** slower
 * `register_block_core_site_title()`: **0.21ms** slower

 It's probably a good idea to check why these block registration functions
 are that slow as well.

 I have added this task to the 6.2 milestone, since this task is about
 determining where these problems come from and whether we can do something
 about them. I understand we may not fix any of these regressions for the
 6.2 release, but I think we should assess them prior to the release so
 that we can fix some of them for 6.2.1, which should be done in separate
 tickets. This ticket's purpose is to provide an overview and facilitate
 general discussion about the problems, not to actually fix them.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57916>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform