[wp-trac] [WordPress Trac] #59719: Revise caching approach for theme files

[WordPress Trac]

#59719: Revise caching approach for theme files
-------------------------+--------------------------
 Reporter:  flixos90     |       Owner:  flixos90
     Type:  enhancement  |      Status:  assigned
 Priority:  high         |   Milestone:  6.5
Component:  Themes       |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  2nd-opinion  |     Focuses:  performance
-------------------------+--------------------------

Comment (by flixos90):

 I just had a good chat with @joemcgill about this, where we ended up
 taking a step back. While determining how to best cache this data
 continues to be relevant, it's worth considering other ways to improve the
 performance of the relevant logic regardless of caching. If there are
 opportunities for that, we could afterwards reassess how the caching here
 should behave to achieve a good compromise between reliability,
 consistency, and performance gain.

 A few observations on existing theme caching first:
 * The `themes` cache group (see `WP_Theme` class) is by default not
 persistent, but can be made persistent via the
 `wp_cache_themes_persistently` filter. This filter additionally allows to
 define the cache expiration to use (in seconds). If no specific expiration
 is defined, it's set to 30 minutes.
 * This same filter is used to control whether to persistently cache the
 list of available themes (see `search_theme_directories()` function). The
 main difference is that here the WP Cache API isn't used, instead it uses
 a transient, which means even sites without a persistent object cache will
 receive these caching benefits. This in itself is inconsistent.
 * Eventually, we could either use this cache group for all theme data or
 introduce a new more specific theme cache group depending on what is being
 cached. This decision depends on a few factors, including whether or not
 we think the approach of "non-persistent by default, persistent by opt-in"
 makes sense for this data.

 Before we can decide that though, we identified another potential
 opportunity with block templates, block template parts, and block patterns
 (i.e. relevant for all tickets blocked by this ticket): Currently, when
 registering the data for them, that data includes the full contents of
 these files. Getting the file content accounts for some of the most
 expensive work, but the file contents actually only matter if the
 respective template/part/pattern is actually used on the current URL.
 There may be other data that isn't needed either unless the
 template/part/pattern is actually used. So we should consider reworking
 the template/part/pattern registration logic to only register the bare
 minimum data on every page load.

 If we can find a solution to that, we can probably reduce the performance
 overhead significantly for themes that include a large number of
 templates/parts/patterns, without involving any caching.

 An additional benefit would be that, even if we then cached this data, it
 wouldn't involve caching the actual file contents, which would mean that
 changes to those files would still be reflected immediately, plus it would
 keep cache data for individual keys from growing too large.

 We should probably explore that further:
 * **Can we rework each of the block template/part/pattern registration
 logic to only register the bare minimum data needed by default?**
 * The relevant functions would still need to optionally support
 registering the ''full'' data, or there would need to be some "lazy-
 loading" mechanism to only run if any of those data fields is being
 accessed. This would be relevant for example in the block editor where
 templates/parts/patterns need to be previewable.
 * For regular page loads though, only the bare minimum data would be
 relevant, and the extra data (such as the actual file content) would only
 be relevant for the few templates/parts/patterns actually used on the
 current URL.

 It's worth noting that there is also a little bit of potential overlap
 with #57789. The two tickets are about caching different aspects of theme
 data, and while the relevant logic considerations are completely
 different, in terms of caching it may make sense to follow similar
 principles.

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