- 🇬🇧United Kingdom catch
Render cache multiple get is now in core after 📌 Render the navigation toolbar in a placeholder Active , we should see if there's an example in core where this would help, and then try to implement it in the renderer.
- 🇨🇭Switzerland berdir Switzerland
The combination of those 4 issues means we now have efficient get multiple cache loading for placeholdered routes and we have quite a few of those now with menus, block_content, local tasks and so on being placeholdered:
📌 Render the navigation toolbar in a placeholder Active
✨ Optimize placeholder retrieval from cache Active
✨ Optimize redirect chain retrieval in VariationCache Active
📌 Create placeholders for more things ActiveSo I think the benefits for blocks aren't that huge, you'd need multiple non-placeholdered blocks in the same region for this to be efficient. We might want to instead look into either placeholder even more blocks or then not cache them on their own at all # 📌 Add CacheOptionalInterface to more blocks Needs review ).
Looking at umami, the only blocks that are not placeholdered are: umami_search (simple form, pretty fast to build), umami_branding (also pretty simple), umami_messages (just puts in a placeholder, definitely could be non-cacheable?) and umami_help (unsure, but depends on route, so high amount of variations). So, not a lot of benefit here.
But I think one scenario where this is still interesting is what I mentioned #6. If you have a view with 50 nodes that gets invalidated, then you can fetch them with a single cache get instead of 50 (with cache redirects, possibly even 2 instead of 100). To measure the benefit, we'd need to create a handful of articles for the frontpage view.
We'd need to run the children through getMultiple() and somehow flag those that have been fetched, so we don't attempt to load them again.