Problem/Motivation
On a cold cache request, the views block derivative loads every view config entity enabled on a site to see if they have a block.
In Umami performance tests, this shows up as resulting in a 72ms cache set, there are several views enabled out of the box, and views tend to be very large config objects.
See the following trace in the performance testing dashboard and attached screenshot:
https://gander.tag1.io/explore?schemaVersion=1&panes=%7B%22fxz%22%3A%7B%...
Note that during regular site operation, a drush/dr cache clear usually rebuilds routes, and rebuilding routes also loads all views config entities to look for routes, so this warms the config cache for the next request. However it's still a lot of large config objects to load that ultimately don't get used on any particular page, many of which won't provide a block display at all.
Steps to reproduce
Proposed resolution
Couple of options:
1. Similar to #3365551: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points introduce a new 'views block' that allows you to select a views block display, get rid of the derivative entirely.
2. Can we use a config entity query with conditions to check for block displays instead of loading all views?
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| Screenshot from 2026-08-17 16-29-31.png | 246.57 KB | catch |
Comments
Comment #2
berdirUnlike other things, views block definitions actually vary by the view for the context definitions, that can't be done in a different way.
Routing relies on \Drupal\views\Views::getApplicableViews, that should work with uses_hook_block too. But by default the entity query still loads all configs ,and I don't think our lookup_keys feature is flexible enough for the "display.*.display_plugin" condition that relies on.