Performance of large menus

Sascha Grossenbacher Porträt
Sascha Grossenbacher

Websites often have very large menu trees, also called mega menus. They contain dozens or hundreds of different menu links that are usually rendered up front, so that their trees or expanded displays are immediately visible when visitors click on them.

Achieving good performance with regular Drupal menu blocks can be challenging for three reasons:

  • Expensive to build
  • Many variations
  • Frequently invalidated

A good example for these challenges is the https://www.psi.ch/en website (See our case study if you want to know more):

  • Between the main navigation, the top header and footer menus, there are about 10 different menu blocks displayed on any given page
  • The site has tens of thousands of content pages in dozens of different sections, many of which have their own version of the main navigation. These sections use the Group module to manage editor access.
  • 4 languages
  • A visible active trail that indicates the currently active main navigation section as well as the child links below
  • The active trail also needs to be vary not only for the pages that are directly linked, but content like articles, events and projects also need to provide the appropriate active trail for their respective overview page. We use Menu Trail by Path for that.

In the last few minor releases, there have been significant improvements in Drupal core and as well as some contributed projects, but there's still work to do.

This article will delve deeper into the 3 challenges with examples and completed and proposed improvements for each. Some improvements were done specifically for this sites, many others are now available to everyone partially due to our involvement, but some require appropriate configuration.

On many Drupal sites, most or all of these menu links point to nodes or another type of entity. Drupal will automatically  check whether or not the target entity is accessible for the current user, by default that happens one by one. That means each menu link loads the target node and does access checks on it, which may trigger fairly expensive hooks, such as node grant lookups, or in the case of PSI, a reverse lookup of the group relationship pointing to that node, then loading the group relationship and then its group.

PSI also contains additional elements in the different menu sections as well as barely noticeable features that are quite expensive to maintain. One is the small arrows, whose direction indicates if the link target goes to a different section (read: different main navigation). That means the group of the target node needs to be loaded and the configured menu compared with the one of the current node.

Using Blackfire and manual profiling, we identified that building the main navigation took up to 50% of the total processing time, even on complex pages. with many paragraphs, embedded views and so on. 

Improvements

Many of the improvements we did for this aspect are site-specific, but there are some related core issues as well.

Custom, Implemented

We bypass expensive group access checks for anonymous visitors. This site does not restrict view access to content except for the ability to have whole groups in a draft mode. We replaced the default group access hook with our own, where we allow view access to all published nodes except those from a globally cached exclude list. Other users fall back to the regular access implementation.

Custom, Implemented

Due to the arrow indicators, we still ended up loading groups and group relationships, so we added another cache layer for that, the challenge here is that this cache needs to vary based on the current group and get invalidated correctly

When using visible active trail indicators, these menu trees also need to be built different for every page. The active trail is meant to show visitors in which section of a website they are currently in. For example, a news article may be located below a News, which is with then About Us section of your main navigation. This is similar to the breadcrumb, but may not follow the same rules.

Until recently, with just Drupal core, every menu block had a cache context that essentially varies for every possible active menu link, even when no CSS exists that would do anything with the the automatically added CSS classes.

The Menu Trail by Path module makes active trail calculation more expensive, as it essentially varies by every possible URL path.

For PSI, the combination of active trails, 4 languages, dozens of different menus means that we currently see around 5000 variations of the main menu block in our cache. These statistics can be explored with the statistics provided by the Redis module, either the report in the UI, or starting with Redis 2.x, also a Drush CLI command.

Improvements

Menu Trail by Path, Implemented

To mitigate its cost, Menu Trail by Path provides a setting that allows to configure the active trail source for each menu, either use its own logic, the default logic by core which only looks up explicitly referenced menu links or disable it entirely. It is strongly recommended to disable active trail calculation for all menus that do not have a visual indicator, such as secondary footer and header menus.

Alternatives

If an active trail is needed, consider alternative options to add that, such as:

  • Attach active trail information using JavaScript. We have been experimenting with this, but are seeing well visible delays compared to the active trail from a cached server response, this may or may not be an issue for your site.
  • A mixed mode, where the server-side active trail is only calculated for the visible part and the lower layers are then completed using Javascript. Menu Trail by Path partially supports this with a setting that allows to configure how many URL path parts should be considered when calculating the active trail, the specific challenge for our project is that this is not always the same as the first part after the language code is sometimes already a specific section/top-level active trail and sometimes it is merely the group and a second level needs to be considered.
  • A server side implementation that operates on the rendered HTML and alters that, similar to the active link response subscriber (\Drupal\Core\EventSubscriber\ActiveLinkResponseFilter). No implementation of this is currently known to us.

As if expensive menu trees that are built and cached in dozens to thousands of variations wouldn't be bad enough, they also tend to be frequently invalidated on sites that update content linked in their menus semi-frequently for two reasons:

  1. Until now (before Drupal 11.5), saving any node with an active menu link through the menu_ui module always saved, rebuild and invalidated any rendered versions of that menu as well as any rendered page that contains that menu. Even if no relevant change was made to the to menu link or anything that would affect its visibility.
  2. Access checks for users that do not have the bypass node access permission add the node:ID cache tag. That means that a menu that links to 100 node pages will have 100 different node:ID cache tags associated with it. Even when the menu link is not saved, such as updating the node through the API.

The result is that every time a page in the menu is saved, all already cached variations that link to that page are invalidated and need to be rebuild again.

Improvements

Core, Implemented in 11.3

A lot of work went into render caching improvements, specifically relevant for menu blocks is that certain blocks can and do opt in to always be placeholdered. This means that the dynamic page cache entries no longer contain the menu blocks. If the menu output does not vary between pages, multiple dynamic page cache pages can share the same menu block cache and they are significantly smaller. We're seeing a reduction of around 50% with all the blocks that are no longer part of it, which means more cached pages fit into the cache.

Block placeholdering

Core, Implemented in 11.3

The same issue also has a second advantage, that is just as important. Invalidating the menu block output no longer invalidates the dynamic page cache, and as a result, page responses after menu cache invalidations are significantly faster as they are still dynamic page cache hits. Due to this, we're seeing better dynamic page cache hit ratios especially when page cache hit rates go down due to such an invalidation.

Core, Implemented in 11.5

Menu UI now only updates the menu link entity when anything specific to it changes, such as the parent or title (Fixing this also required fixing critical data consistency bugs in the core entity system as well as corresponding changes in token.module and it may require site specific changes if you've customized the menu link form when editing nodes). This solves the first problem, but it unfortunately doesn't do much for the second.

Avoid saving menu links through node form when they do not change
That core change does allow the Menu Cache Optimization contributed module to function as intended. That was developed as a proof of concept around 2 years ago to solve the second problem but required core patches until now. What it does is filter out all node:ID cache tags from the cached menu output and instead explicitly invalidates the menu cache tag when a change that impacts visibility of the menu link is detected. Currently, that is limited to the published status changing.
Menu Cache Optimization

Since Drupal 11.3, there have been several improvements in Drupal core to improve the menu performance, but most require some configuration, additional modules or at least awareness of the problems that your site may face.

We will expand this post with other contributed projects or core issues to improve menu performance, share them with us.

Sign up for our newsletter now to receive important insights from the industry and MD Systems every month.

Zur Anmeldung