[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:  high                       |   Milestone:  6.5
Component:  Themes                     |     Version:
 Severity:  normal                     |  Resolution:
 Keywords:  gutenberg-merge has-patch  |     Focuses:  performance
---------------------------------------+--------------------------

Comment (by joemcgill):

 Replying to [comment:12 joemcgill]:

 Revisiting the original explorations I proposed for this issue:

 > I'd like to explore three options:
 >
 > 1. Store the merged data to a static property, similar to the individual
 sources, to eliminate the cost of merging them.


 This idea is explored in
 [https://github.com/WordPress/gutenberg/pull/54742 this Gutenberg PR]. It
 does show some improvement and is something we could merge and test as a
 micro-optimization.

 > 2. Make the entire merged result cacheable in a persistent way

 In order to make the merged data cacheable persistently, invalidation
 needs to be handled for each of the ways the merged data can be affected.
 Including updating core versions, switching or modifying the active theme,
 changes to registered blocks, and changes to user edited settings via the
 site editor (or similar). Each origin (i.e., core, blocks, theme, and
 user) can also be filtered, which makes persistent caching challenging,
 unless we cache the pre-filtered values only rather than the final values
 that are statically cached currently.

 > 3. Make the data from each source cacheable in a persistent way, if the
 entire result cannot be cached persistently

 Given the complexity of idea 2 above, I think we should focus on this
 idea.

 By far, the most expensive `WP_Theme_JSON` origin to calculate seems to be
 `WP_Theme_JSON_Resolver::get_theme_data` on the surface. So it would make
 sense to implement caching there, as @flixos90 has done in
 [https://github.com/WordPress/gutenberg/pull/56095 this Gutenberg PR].

 However, this is a bit misleading because this method seems to be the
 first one called during the application lifecycle. That method is called
 by both `wp_get_theme_data_custom_templates` and
 `wp_get_theme_data_template_parts` prior to
 `WP_Theme_JSON_Resolver::get_merged_data`. This means that
 `WP_Theme_JSON_Resolver::get_theme_data` ends up including the cost for
 initially filling out the static properties of the `WP_Theme_JSON` class,
 including the initial calls to `WP_Theme_JSON::get_blocks_metadata` and
 `WP_Theme_JSON::sanitize`, which accounts for the bulk of the processing
 time. So while caching the `WP_Theme_JSON` data from themes will help, it
 won't remove the cost of calling the `WP_Theme_JSON` constructor the first
 time, it will just move that processing elsewhere.

 Even so, I think it's worth continuing to explore optimizations that
 reduce redundant processing of core and theme data, at minimum. The core
 data should be able to be cached persistently by WP version, similar to
 how we've handled caching in `register_core_block_style_handles()`. For
 data that is specific to the theme, we should probably follow the same
 strategy that is being considered in #59719.

 As a next step, it would be useful to verify the potential impact of
 persistently caching the `WP_Theme_JSON` data provided by core and themes
 by doing a shallow implementation and running a new set of benchmarks.

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