-
-
Notifications
You must be signed in to change notification settings - Fork 23
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
Implement caching for get_blocks
#27
base: master
Are you sure you want to change the base?
Conversation
Thanks for the PR! I like the idea, but how does cache invalidation happen here? |
The cache key is using a The expiration is currently set to One more thing to note: the cache key does not include the post id, so if two posts have exactly the same content (and meta), they use the same cache key. But I guess that is rather unlikely. |
What about blocks that stored in widgets or templates parts that do not have post ids? |
Good point! In general it is problematic if blocks such as As an alternative, we could cache not on content level but on block level (after the default parsing into blocks), with a whitelist of cacheable blocks. Also I'd rather like to find the root of the issue that causes the long response time rather than just trying to "cache it away" :) What do you think? |
I had a try at caching in my own PR: #29 |
On some posts the response time is quite long.
This pull request implements a caching for the parsing using transients (or site transients for multisite).
The cache key contains a
md5
hash of the content and the post meta (only on posts).By default the expiration is set to
0
, so that the cached data will be used until either post content or post meta changes, or until you clear transients manually.In my case this decreases the response time from ≈30s on the first call to ≈1.5s on subsequent calls.
I will have to check which specific block might cause the performance issue as not all posts take that much time.
Did anyone have a similar experience?
I did not dig deeper into it, my guess is that the pQuery parser is kind of slow, or it trips on particular blocks.
This pull request additionally introduces two new filters:
rest_api_blocks_output
rest_api_handle_block
I use them to add additional data to some third-party blocks which don't provide all necessary data as attributes or to apply other transformations.