[wp-trac] [WordPress Trac] #59600: Block themes: Use a cache for block template files (was: Block themes: Use a cache for block templates and block template parts content)

[WordPress Trac]

#59600: Block themes: Use a cache for block template files
--------------------------------------+--------------------------
 Reporter:  flixos90                  |       Owner:  joemcgill
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  6.6
Component:  Themes                    |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------
Changes (by joemcgill):

 * priority:  high => normal
 * milestone:  6.5 => 6.6


Old description:

> While reviewing the performance impact of #59583, I noticed that a large
> chunk of the cost of parsing block templates and block template parts
> comes from simply the `file_get_contents()` calls for those files.
>
> On every page load for a block theme, several block templates and
> template parts are used, each of which results in a `file_get_contents()`
> operation. Getting these file contents is an expensive operation, that
> results in a performance bottleneck which gets greater the more block
> template parts are being used in a theme.
>
> I have prepared a draft PR with a solution for this and based on Server-
> Timing benchmarks, it notably improves the overall response time by a
> solid 5-10% for various block themes.
>
> Given this is a major performance win and relies on a pattern already
> established via #59490 / [56765], I think it is worth prioritizing even
> this late in the release cycle.

New description:

 ''Updated Feb 28 by @joemcgill''

 On every page load for a block theme, several block templates, template
 parts, and patterns are used, each of which results in a
 `file_get_contents()` operation to get the block contents before parsing
 and rendering the blocks included in each. Getting these file contents is
 an expensive operation, resulting in a performance bottleneck which gets
 greater the more block template parts are being used in a theme.

 Since these files are unlikely to change often in production, we should
 attempt to avoid these redundant operations by the use of the caching
 strategy outlined in #59719.

 Solutions need to respect `WP_DEVELOPMENT_MODE` settings, so that
 persistent caching does not happen when developing a theme, and should
 also be forgiving for use cases where theme files are modified directly in
 production through various methods.

 **Original issue description**

 While reviewing the performance impact of #59583, I noticed that a large
 chunk of the cost of parsing block templates and block template parts
 comes from simply the `file_get_contents()` calls for those files.

 On every page load for a block theme, several block templates and template
 parts are used, each of which results in a `file_get_contents()`
 operation. Getting these file contents is an expensive operation, that
 results in a performance bottleneck which gets greater the more block
 template parts are being used in a theme.

 I have prepared a draft PR with a solution for this and based on Server-
 Timing benchmarks, it notably improves the overall response time by a
 solid 5-10% for various block themes.

 Given this is a major performance win and relies on a pattern already
 established via #59490 / [56765], I think it is worth prioritizing even
 this late in the release cycle.

--

Comment:

 Moving this to 6.6 so we can land caching for this and pattern files early
 in the release cycle and not just before RC. I'm updating the issue title
 to also cover persistent caching of block patterns, which was discussed in
 [https://core.trac.wordpress.org/ticket/60120#comment:8 60120], but not
 implemented in that issue.

 @thekt12 already has [https://github.com/WordPress/wordpress-
 develop/pull/6137 an approach in progress] for caching patterns, which is
 currently related to #59719, but should be updated to point to this issue.
 That way we can close out #59719, since it's purpose was to agree on a
 consistent strategy for caching to block theme files, which was documented
 in [https://core.trac.wordpress.org/ticket/59719#comment:13 this comment].

 Further implementation details can be discussed related to the PRs for
 this issue.

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