How to maintain huge menus in Drupal
I once opened a Drupal menu with several thousand links and watched the browser give up before I did. The page loaded, technically. Then every click felt like asking an old printer to explain its feelings.
Start with BigMenu and Menu Select
If a Drupal site has a large editorial menu, the first problem is usually not architecture. It is the editor screen. Core’s menu administration page can become painful when the menu grows into thousands of links. BigMenu deals with that by changing the way editors browse and manage the menu: instead of forcing the full tree onto the page, it lets subtrees open through AJAX when the editor needs them. https://www.drupal.org/project/bigmenu
That sounds small until you have used the default menu UI on a large site. A collapsed tree still hurts if Drupal had to build the whole thing before the page became usable. BigMenu’s value is that it avoids that early bulk load. The editor sees the part of the tree they asked for, not the entire forest. https://www.drupal.org/project/bigmenu
Menu Select solves a different irritation. On content forms, editors often need to choose a parent menu item. With a large menu, a normal select list is absurd. Nobody wants to scroll through thousands of items just to place one page under the right parent. Menu Select replaces that experience with a more usable hierarchy and can add autocomplete, so the editor can search for the parent link instead of hunting through the whole menu by hand. https://www.drupal.org/project/menu_select
I like this split. BigMenu helps when you are managing the menu itself. Menu Select helps when you are attaching content to the menu. They are easy to confuse because both touch menu UX, but they fix different moments in the editorial workflow.
Menu Select Ajax: load the choice when the editor needs it
Menu Select with autocomplete is already a large step forward. But on very big sites, even a better widget can still be too heavy if the form tries to prepare too much menu data before the editor does anything. This is where an AJAX-based menu select pattern makes sense.
The idea is plain: the form should not build a full parent selector for a massive menu on initial load. It should wait. When the editor chooses a menu, types a search term, or opens a branch, Drupal can make a small AJAX request and return only the matching part of the menu. Drupal’s Form API supports this pattern through AJAX-enabled form elements, where a user action triggers a server-side rebuild and only the chosen part of the form is replaced. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms
In practice, an AJAX menu select usually has two layers. The first layer is the visible selector: a search field, a parent picker, or a small expandable branch. The second layer is the stored value: the actual menu link plugin ID or parent reference that Drupal needs when the form is saved.
This distinction matters. Editors should work with labels, trails, and familiar page titles. Drupal should store stable machine values. When those two concerns get mixed together, large menu widgets become fragile. You see duplicate labels, unclear parent choices, and slow form rebuilds.
A good AJAX menu select flow feels almost boring. The editor starts typing part of a title. Drupal returns a short list of possible parent links, preferably with enough context to tell identical titles apart. The editor picks one. The form stores the selected menu link behind the scenes. No giant select list. No full tree render. No browser meltdown.
The same pattern works for expandable branches. Show the top level first. When the editor opens a parent, fetch that parent’s children. If they open another child, fetch the next level. This is how the UI should behave when the data set is large: small request, small response, clear next action.
At 10,000 menu items, stop loading forward
Once a menu reaches something like 10,000 items, I stop thinking about it as a normal Drupal menu. Technically, it is still a menu. Operationally, it is closer to a content index with a tree shape.
The common mistake is to start at the root, load the whole tree, expand the active trail, then throw most of the result away. That works on small menus. On a huge menu, it is backwards.
The better approach I used was backward loading. Start with the active menu link for the current page. From there, load only its parents. That gives you the active trail without asking Drupal to build every unrelated branch. Drupal’s menu APIs support this direction of travel: the menu link manager can find links by route, and it also exposes parent IDs for a menu link plugin. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuActiveTrail.php/11.x https://api.drupal.org/api/drupal/core%21lib%21drupal%21core%21menu%21menulinkmanagerinterface.php/function/menulinkmanagerinterface%3A%3Agetparentids/9
This changes the cost profile completely. A huge menu may have 10,000 items, but the active trail for a page is usually short. Maybe five levels. Maybe seven. Even a deep catalog rarely has dozens of ancestors for one item. So instead of loading 10,000 links to discover one path, you load the active item and walk upward.
After that, you can decide how much surrounding navigation the page really needs. Sometimes the parent trail is enough. Sometimes you also need the active item’s children. Sometimes you need siblings at one level for a section menu. Fine. Load those slices deliberately. Do not let “we need navigation” quietly become “load the entire tree on every request.”
Drupal’s menu tree system already thinks in terms of tree parameters, active trails, and transformations. The usual tree-loading approach can expand links along the current active trail, which is useful on normal menus. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuLinkTreeInterface.php/interface/MenuLinkTreeInterface/8.2.x On a very large menu, though, I prefer to be stricter. First find the active link. Then load its parents. Then load only the branch needed for the current page.
The real maintenance rule: never make editors pay for the whole menu
Huge Drupal menus are not only a rendering problem. They are an editorial problem, a form-building problem, a cache problem, and sometimes an information architecture problem someone postponed for three years.
BigMenu helps editors work with large trees without opening everything at once. https://www.drupal.org/project/bigmenu Menu Select makes parent selection tolerable, especially with autocomplete. https://www.drupal.org/project/menu_select AJAX selection keeps forms from preparing thousands of choices before the editor has made the first meaningful click. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms
For front-end navigation, backward loading is the part I would protect most aggressively. Start from the active menu link. Load parents only. Add children or siblings only when the design truly needs them. That one habit keeps a 10,000-item menu from turning every request into a punishment.
The browser should never have to carry the whole menu just because one page needs to know where it lives.
Looking for the best Drupal development company on the market? You’ve just found it.
We’re the largest Drupal-focused digital agency built to deliver fast, secure, scalable platforms—without compromise. From new builds and redesigns to migrations and long-term support, our Drupal experts ship enterprise-grade results with boutique-level attention.
Book a call today and let’s turn your Drupal roadmap into a high-performing reality.
Ivan Abramenko, Principal Drupal Architect
ivan.abramenko@drupalbook.org
projects@drupalbook.org