- 🇬🇧United Kingdom catch
I think this might be covered by 📌 Add CacheOptionalInterface to more blocks Needs review , moving to postponed until that's done, then we can revisit whether there's anything missing after that.
Certain cache contexts can have a huge amount of variations. 📌 Make language switcher block cacheable Postponed is a good example, that block is currently not cacheable at all (max-age = 0). For Dynamic Page Cache (DPC), that's not a big deal, we simply auto-placeholder it and calculate it on each page. But that prevents us from doing 🐛 [pp-3] Bubbling of elements' max-age to the page's headers and the page cache Postponed because it will result in the whole page being uncacheable so any multilingual site would no longer be able to use page cache, at all.
The latest patch in that issue instead caches it per path and query arguments, which is what the internal page cache is already doing anyway, so we can cache it there without a problem (which we already do, because it ignores max-age). It would however result in a huge amount of cache variations.
Additionally, our auto-placeholder conditions don't yet include url.query_args, but the problem is that DPC uses the same settings to also disable DPC completely. And we don't want that for url.query_args. I think.
In the issue about render cache, I also suggested that might want to disable partial rendering caching for other things, like anything path/route based (like local actions/tasks blocks).
I already created a first patch in 🌱 Optimize render caching Needs work that adds a new setting to control auto-placeholdering separately from DPC and no longer render cache those parts.
An alternative approach would be a new setting for an exclusion list for render caching in general, even if we can't auto-placeholder, but we we also want to auto-placeholder them if possible or the cache contexts will bubble up to DPC. And if we have that setting, we also need a way to disable that exclusion that DPC would use.
There are also other ideas on how to disable render cache, some blocks for example are so trivial that building them is faster than loading from cache or we know there are too many variations and it's not worth it. That could be a separate no-cache flag.
I also had some other ideas a while ago, for example a user-agent filter to prevent caching on search engine requests because on big sites, those often access thousands of old pages a day that nobody else uses, so writing them to cache is wasting a lot of space. So maybe it could be pluggable, but that might be too much overhead, can probably be done using a decorated service too.
New settings, we need to find a way to prevent BC changes for existing sites. #2935617: Move User module's temp stores to core → has an approach for that that copies values and does a deprecation message, we could in theory use something like that if necessary.
Postponed
11.0 🔥
cache system
It affects performance. It is often combined with the Needs profiling tag.
Enhances developer experience.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
I think this might be covered by 📌 Add CacheOptionalInterface to more blocks Needs review , moving to postponed until that's done, then we can revisit whether there's anything missing after that.