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

[WordPress Trac]

#57648: 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:  normal        |  Resolution:
 Keywords:                |     Focuses:  performance
--------------------------+--------------------------

Comment (by flixos90):

 @oandregal I have finally figured out why I have been seeing a regression
 in `wp_enqueue_global_styles()`: It is because that function calls
 `wp_get_global_stylesheet()` and that specifically was modified in a
 notable way in #56910 / [55148].

 * This commit intentionally got rid of the 1 minute transient.
 * Since transients are "persistent" caches beyond requests (not really
 persistent here, but at least "persistent" for 1 minute) and we now
 switched them to a non-persistent cache, that function usually has a
 cached result for WP 6.1.1, while it doesn't for the WP 6.2 Beta.
 * However, getting rid of the 1 minute transient was an intentional
 change, as that is a bad practice and was "hacking" around the problem
 that we haven't yet found a way to implement proper cache invalidation. In
 other words, this is basically a calculated / expected regression at this
 point, as we replaced a "short term persistent" cache with a non-
 persistent cache.
 * It should be highlighted than when I disable caching in the function for
 both 6.1.1 and 6.2 Beta, the code in 6.2 Beta is ''way'' faster than the
 code in 6.1.1, so that's still a positive observation. Essentially for the
 6.2 code, it effectively doesn't make a difference, since the function is
 only called 1 time in a regular page load anyway, i.e. will never actually
 get a cache hit. Below are the Server-Timing metrics for the
 `wp_enqueue_global_styles()` function with vs without caching enabled in
 the `wp_get_global_stylesheet()` function that it calls:
     * `wp_enqueue_global_styles()` with caching (TT3): **16.83ms** (6.2
 Beta) vs **19.18ms** (6.1)
     * `wp_enqueue_global_styles()` without caching (TT3): **16.56ms** (6.2
 Beta) vs **35.53ms** (6.1)
     * `wp_enqueue_global_styles()` with caching (TT1): **5.41ms** (6.2
 Beta) vs **3.35ms** (6.1)
     * `wp_enqueue_global_styles()` without caching (TT1): **5.33ms** (6.2
 Beta) vs **12.04ms** (6.1)
 * Note that for block themes, despite effectively the lack of caching in
 `wp_get_global_stylesheet()`, the code in 6.2 is still faster than in 6.1,
 which is excellent. I'm almost sad we ever had caching here, since those
 ~20ms faster performance of a single function (when considered without
 caching) are amazing to see :)

 Yet, we just have to acknowledge that in the field, we will now have this
 small regression in the `wp_get_global_stylesheet()` function for classic
 themes, for the time being. But I believe we are still in a better place
 than before, as the approach previously was error-prone, and overall WP
 6.2 performance sees so many improvements over 6.1 that holistically this
 little regression will only cause a slight reduction in the overall load
 time performance wins.

 Based on the above, my vote would be too close this ticket as `maybelater`
 (as we should still work towards figuring out how to properly use a
 persistent cache around this logic).

 Aside: [https://docs.google.com/spreadsheets/d/1LroIJoYz-
 O9CpfJzaiKYYMWJ7GbE5RZoW1rf1R4FqyA/edit This spreadsheet] has the latest
 WP 6.2 performance benchmarks I ran today, covering both server-side and
 client-side performance for 6.2 Beta 1 and Beta 2 in comparison with
 6.1.1.

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