Mega Menus as a Speed Brake: Shipping Lean Navigation

Navigation is one of the few components that sit on every single page. A product description appears once, a category teaser on a few pages, but the menu shows up on the home page, listings, product pages, search results and the customer account. Whatever is too much in there, every page view pays for. In a shop with a deep catalog, the main navigation quietly grows with the assortment: every new subcategory automatically becomes another link in the header of every page, without anyone touching the template. If you only measure the home page, you often miss this, because images and sliders dominate the diagnosis there.

The cost arises in three places. First in the HTML: every list item and link travels with the document, is transferred compressed and unpacked again in the browser. For context: the median desktop home page loads 18 KB of HTML (Web Almanac 2024), so a menu with several hundred category links is no minor item next to that. Second in the DOM: the median mobile page has 594 elements, and at the 90th percentile it is 1,716 (Web Almanac 2024). Third at runtime: the larger the tree, the more expensive every style calculation and every layout becomes, even if most nodes stay invisible.

The old thresholds of the Lighthouse audit were a warning at about 800 and an error at about 1,400 nodes in the body, and since Lighthouse 13 the audit has moved into the "Optimize DOM size" insight (Chrome for Developers), which we cover in detail in the article Reduce DOM size.

For a mega menu, a different statement from the same documentation is more revealing: a style recalculation counts as large when it affects more than 300 elements (Chrome for Developers). A menu reaches exactly that order of magnitude when opening it sets a class on the body or html element to dim the page behind it or to stop scrolling. The browser may then have to re-evaluate large parts of the page, including all hidden menu entries. Why complex selectors make this work even more expensive is explained in the article on style recalculation.

Responsiveness shows the difference between entry pages and deeper pages. On mobile, 80 percent of home pages reach a good INP score, but only 69 percent of secondary pages (Web Almanac 2025). Navigation is not the only cause, since listings with filters and product pages with galleries contribute their share. But it is a component that runs on every one of those secondary pages, which makes it a lever that works everywhere at once. Why work on templates pays off more than work on the home page alone is covered in Template performance beyond the home page.

The most important decision is editorial rather than technical: how many levels does a visitor need to find their way? For many assortments, two levels in the delivered HTML are enough. The top level names the main areas, the second the categories below them. Everything beyond that is fine selection, which visitors make on the category page anyway, with filters, sorting and product images. A menu that lists every subcategory takes that job away from the category page and at the same time makes every other page heavier.

In Shopware, the depth of the main menu is set in the sales channel under "Navigation levels". According to the field definition in the source code, the value determines how many levels of subcategories the storefront category menu shows. It is worth reviewing after every major expansion of the assortment. Custom themes and extensions can bypass the setting when they load the tree themselves; then the template needs checking, not just the setting. In our Shopware performance work, this look at the templates is a fixed part of the process.

Which categories belong in the second level is decided by access data, not by the org chart. Categories that hardly anyone opens from the menu move to the category page of their area. A "View all" link at the foot of each column leads to the parent category page and replaces a long list that hardly anyone reads to the end anyway. Visitors lose nothing: the category page shows the subcategories with image, product count and filters, while the menu shows only their names.

Promotions and seasonal topics are a special case. They tend to end up as an extra column with an image in the mega menu and stay there long after the promotion has ended. A fixed slot with exactly one teaser that is swapped editorially keeps the navigation stable. The same applies to brand lists: a column with every brand in the assortment belongs on a brand page of its own, not in the header of every product page.

The most common objection to lean menus is the concern about discoverability: if the third level is no longer in the HTML of every page, will Google still find it? The answer depends on whether there is a second path besides the menu. Google can generally only follow a link if it is an <a> element with an href attribute (Google Search Central). And content that is only loaded after an action such as clicking or scrolling is not picked up by Google Search this way, because it does not interact with the page (Google Search Central).

A fragment that arrives on hover therefore stays invisible to the crawler. That is not a problem as long as every subcategory is linked as a normal link on its parent category page and every page carries breadcrumbs up to the home page. Google puts the rule simply: every page you care about should have a link from at least one other page on your site (Google Search Central). Breadcrumbs show the position of a page in the hierarchy, and marked up as BreadcrumbList they become readable for Search (Google Search Central).

This makes the navigation one of several paths to the categories instead of the only one. The same applies to accessibility: the W3C advises repeating the entries of a submenu on the page of the parent menu item, because people with reduced dexterity often have trouble operating fly-out menus (W3C WAI). A category page that shows its subcategories as tiles or a list solves both tasks at once. This is no promise about rankings; it only ensures that no destination depends on the menu alone.

A second point concerns size. For Google Search, Googlebot reads the first 2 MB of a supported file (Google Search Central), and this limit applies to the uncompressed data (Google Search Central). Shop pages usually stay far below it. But because the navigation sits at the beginning of the document, a bloated menu uses up this budget first, before product text and reviews further down. If you already ship large pages, such as long listings with many variants, measure the sum of menu and content uncompressed once.

Many mega menus depend on a library that evaluates mouse movements, positions panels, sets timers and toggles classes. Opening on hover usually needs none of that. CSS can show a panel as long as the pointer rests on the main item or the panel, and it can delay opening and closing. That models hover intent: someone moving the mouse across the bar to the search field should not open every panel along the way, and someone moving diagonally from the main item into the panel should not lose it on the way.

The W3C tutorial on fly-out menus delays closing with a timer so that imprecise mouse movements do not snap the menu shut immediately; the example uses one second (W3C WAI). In CSS, the delayed transitions on opacity and visibility take over this job: the panel only starts to fade after a quarter of a second and stays usable until then. The values in the example above are starting points for your own tests, not a rule. The (hover: hover) condition makes sure touch devices do not get this behavior at all; there the button opens the panel. Only opacity is animated, not height or position, so no layout has to be recalculated.

Content that appears on hover has to meet three conditions under success criterion 1.4.13 of WCAG 2.2: it can be dismissed without moving pointer or focus, the pointer can move over the new content without it disappearing, and it remains visible until the trigger is removed (W3C). A panel that attaches directly to the main item and closes on Escape meets this. A gap of a few pixels between bar and panel, on the other hand, makes it close while the pointer moves across. A few lines of script on the nav element are enough for Escape and the button state; that is no comparison to a menu library.

The interestfor attribute now offers a built-in way to detect interest via hover, focus or long press. So far, however, it only works in Chrome and Edge from version 142, not in Firefox and Safari (Web Features Explorer). For a main menu it is therefore an addition for later, not a foundation.

INP has a special feature here: hovering, zooming and scrolling do not count as interactions; clicks, taps and key presses are measured (web.dev). A mega menu that starts heavy work on hover therefore does not show up in INP directly. It can, however, delay the click that comes right after if the main thread is still busy at that point. On a phone the case is clear: a tap opens the menu, and exactly that tap is measured.

That is why it pays to keep the state on the menu rather than on the body. A class on the list item usually affects only its subtree, while a class on the body can make selectors across the whole page re-evaluate. If you want to dim the page behind an open menu, place a separate element over the content instead of toggling a rule on the body. And if you need to lock scrolling behind the drawer, set the lock once rather than again on every movement.

The navigation is identical on every page of a shop, at least for all visitors of one language and one sales channel. Yet many systems recompute it on every page build: loading categories, checking visibility, generating links, writing markup. That costs server time before the first byte and ties the navigation to the lifetime of every single page. When a price changes, the menu expires along with the product page even though it has not changed.

A fragment with its own lifetime is the better approach. Shopware has taken this route since version 6.7: header and footer are loaded via ESI (Shopware), which allows them to be cached separately from the rest of the page (Shopware). When a product price changes, the navigation does not have to be rebuilt; when a category changes, the fragment is invalidated without every page having to be rebuilt just because of the menu. In other systems you achieve the same with a server-side include that caches the menu part separately, or with a dedicated cache entry that is purged when a category is saved.

For third-level fragments, the situation is even simpler. They are the same for all visitors and can be served as static files with a long cache lifetime, as long as their address carries a version that changes with the category tree. A new tree gets a new address, and old copies simply expire. The server then no longer has to run a single database query for an opened menu.

It gets tricky when the navigation contains personal parts: the name in the account menu, the number in the cart, a customer group with its own categories. If these sit in the same fragment, the cache breaks into many small variants. Such parts are delivered separately or added in the browser. Why a single cookie can wreck the hit rate is explained in Why one cookie wrecks your cache hit rate; which cache layers interact in a shop is covered on our page on caching strategies.