[wp-trac] [WordPress Trac] #57789: Make theme.json related caches persistent

[WordPress Trac]

#57789: Make theme.json related caches persistent
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:  joemcgill
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.6
Component:  Themes                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  gutenberg-merge has-patch needs-     |     Focuses:
  testing                                        |  performance
-------------------------------------------------+-------------------------
Changes (by joemcgill):

 * keywords:  gutenberg-merge has-patch => gutenberg-merge has-patch needs-
     testing


Comment:

 I'm doing some clean up on this ticket so we can make more progress during
 the 6.6 release cycle.

 @spacedmonkey, I responded to [your PR https://github.com/WordPress
 /wordpress-develop/pull/6289] and in doing so, I realized that clarifying
 the goal of this ticket could be useful.

 The goal of this ticket is not simply to make the data stored to our
 current `theme_json` cache group persistent, but instead to address the
 underlying reasons why we haven't been able to make that data persistent
 so far.

 Generally speaking, all of the places where we are storing data to the
 `theme_json` cache group is to avoid expensive operations from the
 `WP_Theme_JSON_Resolver` class, including those related to accessing and
 transforming specific properties from this merged object (settings,
 styles, custom CSS, etc). The `WP_Theme_JSON_Resolver` class is
 responsible for merging together `WP_Theme_JSON` data derived from 4
 sources (i.e. "origins"): core, registered blocks, the theme, and user
 customizations made in the site editor. Ideally, we could persistently
 cache the final merged `WP_Theme_JSON` data and the results of any
 expensive operations that depend on this merged data. However, handling
 cache invalidation for each of these origins is complex, which is what has
 been a blocker in this effort.

 In order to move this forward, we should try to handle persistence at the
 origin level. Data from each origin is already stored to a static property
 on each request, but that data is not cached in a persistent way. We
 should be able to persistently cache the data from the "core" origin based
 on the WordPress version. We can also likely cache data from the "theme"
 origin based on any changes to the theme's theme.json, the parent theme's
 theme.json, and any `add_theme_support()` values. I think we should focus
 on these two origins for now.

 The [https://github.com/WordPress/wordpress-develop/pull/5267 previous PR]
 from @flixos90 already focuses on those two origins but specifically
 limits caching to just reading and translating the theme.json files. While
 this is already an improvement, we should validate that the approach still
 has the same impact that he was reporting and also see if we can increase
 the impact by caching more than just the translated files. However, I
 currently have two concerns with that approach:

 1. A big part of the cost of reading and building the `WP_Theme_JSON`
 objects is spent constructing and sanitizing the `WP_Theme_JSON` objects
 themselves.
 2. When measuring the impact of any PR, we should be cautious about not
 over-emphasizing performance gains based on avoiding file operations,
 since we've already determined that file reads end up getting cached at
 the OPcache level in most cases.

 I've also closed [https://github.com/WordPress/wordpress-
 develop/pull/5024#issuecomment-2070862796 my previous PR], given that it
 didn't result in a measurable impact.

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