-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Object caching WP_Theme_JSON::compute_style_properties
#6392
Object caching WP_Theme_JSON::compute_style_properties
#6392
Conversation
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
WP_Theme_JSON::compute_style_properties
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN:
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @kt-12. I can confirm that this makes a big improvement in my profiling, so it would be great to keep some focus on this problem. The biggest issue with the current approach is the use of wp_add_global_styles_for_blocks()
inside the WP_Theme_JSON
class. We need to find an approach to caching this data that does't require the use of this global function or rethink the approach a bit.
cs fixes Co-authored-by: Joe McGill <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea here. I've left a few suggestions for how I think this could be improved.
$style_cache_key = $settings_hash . '_' . $metadata_hash; | ||
if ( isset( $cached[ $style_cache_key ] ) ) { | ||
$block_css = $cached[ $style_cache_key ]; | ||
} else { | ||
$block_css = $tree->get_styles_for_block( $metadata ); | ||
$cached[ $style_cache_key ] = $block_css; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the settings hash is part of the transient key, it doesn't need to be used for each block node key:
$style_cache_key = $settings_hash . '_' . $metadata_hash; | |
if ( isset( $cached[ $style_cache_key ] ) ) { | |
$block_css = $cached[ $style_cache_key ]; | |
} else { | |
$block_css = $tree->get_styles_for_block( $metadata ); | |
$cached[ $style_cache_key ] = $block_css; | |
} | |
if ( isset( $cached[ $metadata_hash ] ) ) { | |
$block_css = $cached[ $metadata_hash ]; | |
} else { | |
$block_css = $tree->get_styles_for_block( $metadata ); | |
$cached[ $metadata_hash ] = $block_css; | |
} |
@@ -1000,6 +1000,14 @@ protected static function get_blocks_metadata() { | |||
$registry = WP_Block_Type_Registry::get_instance(); | |||
$blocks = $registry->get_all_registered(); | |||
|
|||
// Unset old blocks from static variable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We haven't been clearing unregistered blocks till now. This caused inconsistent outcomes, for WP_Theme_JSON::get_styles_block_nodes()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good find. I'm really unsure if having stale metadata stored in the WP_Theme_JSON
class is really a problem, as it seems like most of the places that make use of this data are doing so for validation purposes when comparing against the active WP_Theme_JSON
data.
I am curious if you still see the behavior that you noticed if the changes from #6696 are applied.
If not removing this metadata leads to a bug, it would be best to document the specifics of the bug with steps to reproduce and propose this change outside the scope of this PR.
@@ -1000,6 +1000,14 @@ protected static function get_blocks_metadata() { | |||
$registry = WP_Block_Type_Registry::get_instance(); | |||
$blocks = $registry->get_all_registered(); | |||
|
|||
// Unset old blocks from static variable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good find. I'm really unsure if having stale metadata stored in the WP_Theme_JSON
class is really a problem, as it seems like most of the places that make use of this data are doing so for validation purposes when comparing against the active WP_Theme_JSON
data.
I am curious if you still see the behavior that you noticed if the changes from #6696 are applied.
If not removing this metadata leads to a bug, it would be best to document the specifics of the bug with steps to reproduce and propose this change outside the scope of this PR.
This reinstates the code block that handled proper inlining of styles that are added through theme.json files and updates the way block nodes are being cached so that we use the block name as the cache key when available, or a hash of nodes that don't have a block name because they've been added through theme.json files.
@kt-12 I went ahead and resolved conflicts and updated this branch with the fixes proposed in my other PR so will close that now. Looks like this has fixed the test failures we were seeing on this branch. Let's do some final checks, but I think this is about ready to commit. |
With the latest updates this is still profiling really well and showing a large improvement for That said, those improvements are not currently reflected in the benchmarks performed by the Performance Workflow. I suspect it's because the extra query being performed to get the transient is offsetting the savings introduced in the function, but that's just a guess. Given the size of the potential improvement, it still may be worth committing so we can continue to do further testing during the beta period. |
Merged in 58334. |
Trac ticket: 59595
Incorporating feedback from - #5567, I did the first version #5567
theme_json
based caching based on initial feeback ( commit )theme_json
for caching. Howevertheme_json
being non-persistent had no benefit. Instead, the cache key generation added additional overhead. This is becausecompute_style_properties(
is called 85 times on the home page out of which 83 calls had a unique signature, so it was as good as having no cache at all + cache key generation overhead. The same -ve effect was found for the non-cached site. Overall the code resulted in a6%
degrade.No cache - All score below in (ms)
Trunk Response Time (median) - 399.62
After PR - 424.81 -- Note this cost is mainly due to cache key creation code run separately 85 times
Meme cache with
theme_json
non persistent cacheTrunk Response Time (median - 375.47
After PR with cache - 402.58
Switching to transient-based caching ( this commit )
The way around this was to use transient function-based caching. The idea was transient would override the -ve effect of overhead due to cache key creation on non-persistent sites and it would give the benefit of a persistent cache for other sites.
Testing the above concept this commit -
No cache
Trunk - 400
PR (transient cache) - 471.61 ( mainly because get_transient_site is costly) + cache_key code.
Meme cache
Trunk - 374
PR - 376 (benefit negated by wp_json_encode and md5 )
Improved transient caching through static caching (current state)
Meme cache
Trunk - 374
PR - 356 (~ 6% improvement )
No cache
Trunk - 400
PR (transient cache) - 384 ( ~4% improvement )
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.