Opened 3 weeks ago
Last modified 4 days ago
#59314 new enhancement
Cache the result of template file lookups
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Themes | Keywords: | needs-patch 2nd-opinion |
Focuses: | performance | Cc: |
Description
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.
Change History (6)
#2
@
3 weeks ago
- Keywords needs-patch added
- Milestone changed from Awaiting Review to Future Release
Moving this to Future Release, since we're so close to the 6.4 beta release.
#3
@
3 weeks ago
- Keywords 2nd-opinion added
Calls to file_exists()
should essentially be free due to the stat cache. I can't imagine we'll be able to increase performance by additionally caching the results in the object cache. Let's get some good before and after figures please.
We may also consider using glob to lookup on php / html files, caching that. Then the lookup would be if a path is in an array.