[wp-trac] [WordPress Trac] #57648: Major performance regression in `wp_enqueue_global_styles()` for classic themes

[WordPress Trac]

#57648: Major performance regression in `wp_enqueue_global_styles()` for classic
themes
--------------------------+--------------------------
 Reporter:  flixos90      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  high          |   Milestone:  6.2
Component:  Editor        |     Version:  trunk
 Severity:  major         |  Resolution:
 Keywords:                |     Focuses:  performance
--------------------------+--------------------------

Comment (by flixos90):

 I spent some time conducting additional analyses. **TLDR there appears to
 be a regression, but much smaller than my original analysis had
 suggested;** performance analysis is hard 🙃

 Apologies in advance for the upcoming wall of text. If you don't care
 about how I got to where I got, please skip to the "Summary" section at
 the end of this comment.

 My first analysis had been using the regular WP core development
 repository, so there's a chance that something in that configuration
 skewed the data notably. Anyway, because of that I now focused on
 configurations using WordPress in the "regular" way, i.e. the builds that
 you also would get from wordpress.org.

 The approach for all analyses was to use the
 [https://wordpress.org/plugins/performance-lab/ Performance Lab plugin] as
 well as
 [https://gist.github.com/felixarntz/63c05392dbf7d51cc7f8f4a424b1ff39 the
 plugin from this Gist] which I quickly assembled for that purpose (and
 other future testing).

 I tested in the following configurations (each using 2 separate sites, one
 with 6.1.1, the other with 6.2-beta.1):
 1. 2 [https://tastewp.com/ TasteWP] sites with `WP_DEBUG`, 20 requests per
 scenario ([https://docs.google.com/spreadsheets/d/1p8Bw8Y_53NlZ8rHRmXn-
 a_fJj3XBe8Ajf6w9eCHKecI/edit#gid=345666660 results])
 2. 2 [https://instawp.com/ InstaWP] sites without `WP_DEBUG`, 20 requests
 per scenario ([https://docs.google.com/spreadsheets/d
 /1p8Bw8Y_53NlZ8rHRmXn-a_fJj3XBe8Ajf6w9eCHKecI/edit#gid=1654163366
 results])
 3. 2 local sites (set up with [https://localwp.com/ Local]) without
 `WP_DEBUG`, 20 requests per scenario
 ([https://docs.google.com/spreadsheets/d/1p8Bw8Y_53NlZ8rHRmXn-
 a_fJj3XBe8Ajf6w9eCHKecI/edit#gid=2076948974 results])
 4. same as 3., but with 1000 requests instead of 20 requests
 ([https://docs.google.com/spreadsheets/d/1p8Bw8Y_53NlZ8rHRmXn-
 a_fJj3XBe8Ajf6w9eCHKecI/edit#gid=2025456764 results])

 For each test I made 20 requests per scenario and used the median values
 for each metric.

 The data from the TasteWP and InstaWP tests showed vastly conflicting
 data, suggesting that making requests to external sites is not a great
 approach due to the high variance. It also is worth highlighting that the
 overall response time in each request differed notably from the `wp-total`
 metric that WordPress measured itself, which makes sense since that type
 of request is much more affected by external factors like network
 connection than in a local environment. This is primarily why I consider
 Server-Timing metrics more helpful than TTFB (although it's also fair to
 say that in a local environment TTFB is usually okay since the latency is
 so little). Anyway, the most important thing to see was that in none of
 the tests `wp_enqueue_global_styles()` was a big issue, which meant my
 first analysis had probably had some problem in its configuration.

 Since the above data was so unconclusive though due to its high variance
 between requests, I went back to testing with a local environment, using 2
 sites set up with Local. Those numbers ended up with a lower variance
 between requests, so are more reliable. They ''do'' suggest that there is
 still a regression in the performance of `wp_enqueue_global_styles()`, but
 by far not as severe, which is good.

 When I ran the CLI script again locally, I got the impression that results
 were still somewhat different between runs, so I did yet another
 comparison with the same Local sites, now going with that far higher
 request count of 1000 per scenario that @oandregal had been using.
 Interestingly, while the data seemed even more consistent, at the end of
 the day it was very much the same data that I got with only the 20
 requests per scenario. So making 1000 requests per scenario is probably
 unnecessary and excessive; 20 seems on the low end, who knows, maybe 100
 is a reasonable number?

 Anway, based on the above research, I think the last analysis
 ([https://docs.google.com/spreadsheets/d/1p8Bw8Y_53NlZ8rHRmXn-
 a_fJj3XBe8Ajf6w9eCHKecI/edit#gid=2025456764 this sheet]) has data that we
 can rely on. 🎉

 **Summary**
 * WordPress load time so far appears to be 24% faster for the block theme
 (TT3) and 6% faster for the classic theme (TT1).
 * The regression of `wp_enqueue_global_styles()` for classic themes is by
 far not as severe as originally thought. It's still a 60% regression, but
 in absolute numbers that is only 2ms.
 * For block themes, `wp_enqueue_global_styles()` is actually 14% (2.7ms)
 faster than before.
 * One other thing worth highlighting is that the process of locating the
 template has notably improved for block themes by a significant 39% (23ms
 instead of 38ms).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57648#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform