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
Putting this in dynamic page cache, but we can move it somewhere more appropriate too.
This is a follow-up due to #2853509: Don't render status messages if there are no messages but also include their assets if there might be where it was pointed out that when the block is rendered, even when empty, it can add 10% to request time.
Copying my comment from there:
I haven't profiled this yet, but there's a few things going on with the messages block specifically:
1. This is rendered in a specially cased placeholder, so that it always runs as late as possible (to pick up as much from $_SESSION as it can). It's not cached, although it could probably be cached by a 'session contains messages' cache context then max-age=0 when it contains nothing (which I don't think we should implement here).
2. With dynamic page cache, at least theoretically this could be the only (or one of few) template getting rendered as opposed to pulled from cache, so there may be some overhead of loading templates, other caches etc. that in 7.x would have happened whether it gets rendered or not. In other words the 10% can be a good sign that the request is light when it doesn't get rendered.
Proposed resolution
Profile it to confirm it really is that expensive relative to the rest of the request, and what the function call diff is.
Couple of ideas for what we could do:
1. Add caching of the block based on a 'session has messages' cache context, so that the empty block is always pulled from cache, when it does get rendered it'd have to be with max-age=0
2. Add an additional messages region at the bottom of the page. Stop special casing the block so it can just be rendered based on what's in session top and bottom of the page (and hence the request). then have some javascript to take messages from the bottom of the page and move them to the top. This would remove the special casing and need for late rendering, but it means two blocks and some degradation without js enabled.
Comments
Comment #2
wim leersComment #15
catchAt least with bigpipe this is no longer special cased, see #3379885: Use MessagesCommand in BigPipe to remove special casing of the messages placeholder. I also haven't noticed lots of rendering time when profiling.