Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Certain cache contexts can have a huge amount of variations. #2232375: Support CacheOptionalInterface in BlockViewBuilder, use it in language switcher block to prevent max-age 0 bubbling 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 #2352009: Bubbling of elements' max-age to the page's headers and the page cache 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).
Proposed resolution
I already created a first patch in #2888838: Optimize render caching 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.
Remaining tasks
User interface changes
API changes
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.
Comments
Comment #3
fabianx commentedI think the easiest would be a policy service, which says:
- Should this be cached / placeholder-ed?
Then it is pluggable and makes sense and is more flexible. Core implementation would just use the auto-placeholdering conditions for now.
Btw. the render tree in theory knows if it is in a context of a lazy builder or not, but we would need to store that information somewhere (explicitly or implicitly). Based on that we can re-act differently in lower levels.
Too bad that async PHP is still not there, but I also thought about things like:
- If rendering takes longer than x ms (in the render tree), return control to last point (co-routine like) and continue to render that sub-tree later.
Comment #10
andypostComment #11
neclimdulComment #13
gaëlgComment #17
catchI think this might be covered by #3516051: Add CacheOptionalInterface to more blocks , moving to postponed until that's done, then we can revisit whether there's anything missing after that.