[wp-trac] [WordPress Trac] #59314: Cache the result of template file lookups

[WordPress Trac]

#59314: Cache the result of template file lookups
-------------------------+-----------------------------
 Reporter:  joemcgill    |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Themes       |    Version:
 Severity:  normal       |   Keywords:
  Focuses:  performance  |
-------------------------+-----------------------------
 WP makes repeated `file_exists` operations for the same templates that
 rarely change. To reduce the overhead of these operations we should
 consider caching the result of `get_query_template` and use the cached
 path directly on subsequent requests.

 Related tickets:
 https://core.trac.wordpress.org/ticket/12491
 https://core.trac.wordpress.org/ticket/40731

 == Design considerations
 The design would need to account for the passed list of template
 candidates (the second parameter) by checking for a cached value after the
 `{$type}_template_hierarchy hook` is fired. If found, this would bypass
 the subsequent `locate_template` and `locate_block_template` calls in this
 function, otherwise would cache the value of the `$template variable`
 before it is passed to the final output filter.

 To avoid fatal errors, the cached value should still be run through a
 `file_exists` check and fall back to the original `locate_template`
 function if false. Other cache invalidation strategies will need to be
 thought through as part of implementation to avoid these cached values
 becoming stale.

 To keep the number of cache keys to a minimum, we could consider storing
 these as a single multi-dimensional array rather than distinct values.

 == Benefits
 This would avoid the need to run file operations for the same template on
 multiple requests, given that these files rarely change unless the whole
 theme has been replaced. Even so, the performance impact of this change is
 still inconclusive, as file operations on many systems get natively cached
 by PHP so the impact may be smaller than anticipated based only on
 application profiling methods.

 == Caveats and risks
 This benefit would be limited to sites running a persistent object cache
 since this value is only calculated once per request, unless this is
 implemented as a transient. While file operations do account for a
 noticeable percentage of the total time spent on the server during a
 request, this would only avoid the initial template file lookups, and not
 any additional template parts that are called during the rendering of a
 template file.

 Since the template hierarchy allows a high level of granularity, even to
 the level of a specific post ID, this cache would need to account for
 potentially every URL, which could bloat caches. Additional performance
 evaluation should be conducted on any implementation before this is
 committed.

 **Note:** A previous attempt at solving this problem was attempted in
 #40731 using a static cache instead of an object cache, but was determined
 to not be a significant enough benefit to warrant merging, so this would
 need to show clear performance benefits.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59314>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform