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

CommentFileSizeAuthor
Screenshot from 2026-08-17 16-29-31.png246.57 KBcatch

Comments

catch created an issue.

berdir’s picture

Unlike 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.