Megamenü als Tempobremse: Navigation schlank ausliefern

Eine Navigation gehört zu den wenigen Bauteilen, die auf jeder einzelnen Seite stehen. Ein Produkttext erscheint einmal, ein Kategorie-Teaser auf wenigen Seiten, das Menü aber auf Startseite, Listing, Produktseite, Suchergebnis und im Kundenkonto. Was dort zu viel steckt, zahlt jeder Seitenaufruf mit. Bei einem Shop mit tiefem Sortiment wächst die Hauptnavigation leise mit dem Katalog: Jede neue Unterkategorie wird automatisch ein weiterer Link im Kopf jeder Seite, ohne dass jemand die Vorlage anfasst. Wer nur die Startseite misst, sieht das oft nicht, weil dort Bilder und Slider die Diagnose bestimmen.

Die Kosten fallen an drei Stellen an. Erstens im HTML: Jede Zeile aus Listenpunkt und Link reist mit dem Dokument, wird komprimiert übertragen und im Browser wieder entpackt. Zur Einordnung: Die mittlere Startseite lädt am Desktop 18 KB HTML (Web Almanac 2024), ein Menü mit mehreren Hundert Kategorielinks ist daneben kein Randposten. Zweitens im DOM: Die mittlere mobile Seite hat 594 Elemente, im 90. Perzentil sind es 1.716 (Web Almanac 2024). Drittens in der Laufzeit: Je größer der Baum, desto teurer wird jede Stilberechnung und jedes Layout, auch wenn der Großteil der Knoten unsichtbar bleibt.

Die alten Schwellen des Lighthouse-Audits lagen bei einer Warnung ab etwa 800 und einem Fehler ab etwa 1.400 Knoten im body, und seit Lighthouse 13 ist das Audit in die Insight „Optimize DOM size“ gewandert (Chrome for Developers), was wir im Beitrag DOM-Größe reduzieren ausführlich einordnen.

Für das Megamenü ist eine andere Angabe aus derselben Dokumentation aufschlussreicher: Eine Stilneuberechnung gilt als groß, wenn sie mehr als 300 Elemente betrifft (Chrome for Developers). Genau in diese Größenordnung gerät ein Menü, das beim Öffnen eine Klasse am body oder am html-Element setzt, damit die Seite dahinter abgedunkelt wird oder das Scrollen stoppt. Dann muss der Browser unter Umständen große Teile der Seite neu bewerten, einschließlich aller versteckten Menüeinträge. Warum komplexe Selektoren diese Arbeit zusätzlich verteuern, beschreibt der Beitrag zur Style-Recalculation.

Bei der Reaktionszeit zeigt sich der Unterschied zwischen Einstieg und Tiefe. Mobil erreichen Startseiten zu 80 Prozent einen guten INP-Wert, Unterseiten nur zu 69 Prozent (Web Almanac 2025). Die Navigation ist nicht die einzige Ursache dafür, Listings mit Filtern und Produktseiten mit Galerien tragen ihren Teil bei. Sie ist aber ein Bauteil, das auf jeder dieser Unterseiten mitläuft, und darum ein Hebel, der überall gleichzeitig wirkt. Warum sich die Arbeit an Vorlagen mehr lohnt als an der Startseite allein, steht im Beitrag Vorlage statt Startseite.

Die wichtigste Entscheidung ist keine technische, sondern eine redaktionelle: Wie viele Ebenen braucht ein Besucher, um sich zu orientieren? Für viele Sortimente reichen zwei Ebenen im ausgelieferten HTML. Die oberste Ebene nennt die Hauptbereiche, die zweite die Kategorien darunter. Alles Weitere ist Feinauswahl, die der Besucher ohnehin auf der Kategorieseite trifft, mit Filtern, Sortierung und Produktbildern. Ein Menü, das jede Unterkategorie auflistet, nimmt dieser Seite ihre Aufgabe ab und macht sie gleichzeitig auf jeder anderen Seite schwerer.

In Shopware steht die Tiefe des Hauptmenüs im Verkaufskanal unter „Hauptnavigations-Ebenen“. Laut Felddefinition im Quellcode bestimmt der Wert, wie viele Ebenen von Unterkategorien das Kategoriemenü der Storefront zeigt. Es lohnt sich, ihn nach jedem größeren Sortimentsausbau neu anzusehen. Eigene Themes und Erweiterungen können die Einstellung umgehen, wenn sie den Baum selbst laden; dann gehört die Vorlage geprüft, nicht nur die Einstellung. In unserer Shopware-Performance gehört dieser Blick in die Vorlagen zum festen Ablauf.

Welche Kategorien in die zweite Ebene gehören, entscheiden die Zugriffsdaten, nicht das Organigramm. Kategorien, die kaum jemand über das Menü aufruft, wandern auf die Kategorieseite ihres Bereichs. Ein Link „Alle anzeigen“ am Fuß jeder Spalte führt zur übergeordneten Kategorieseite und ersetzt eine lange Liste, die ohnehin kaum jemand bis zum Ende liest. Für Besucher ist das kein Verlust: Die Kategorieseite zeigt die Unterkategorien mit Bild, Produktzahl und Filtern, das Menü nur ihren Namen.

Ein Sonderfall sind Aktionen und Saisonthemen. Sie landen gern als zusätzliche Spalte mit Bild im Megamenü und bleiben dort, lange nachdem die Aktion vorbei ist. Ein fester Platz mit genau einem Teaser, der redaktionell getauscht wird, hält die Navigation stabil. Dasselbe gilt für Herstellerlisten: Eine Spalte mit allen Marken des Sortiments gehört auf eine eigene Markenseite, nicht in den Kopf jeder Produktseite.

Der häufigste Einwand gegen schlanke Menüs ist die Sorge um die Auffindbarkeit: Wenn die dritte Ebene nicht mehr im HTML jeder Seite steht, findet Google sie dann noch? Die Antwort hängt davon ab, ob es außer dem Menü einen zweiten Weg gibt. Google kann einen Link in der Regel nur verfolgen, wenn er ein <a>-Element mit href-Attribut ist (Google Search Central). Und Inhalte, die erst nach einer Aktion wie Klicken oder Scrollen geladen werden, erfasst die Google-Suche auf diesem Weg nicht, weil sie nicht mit der Seite interagiert (Google Search Central).

Ein Fragment, das beim Überfahren nachkommt, bleibt für den Crawler also unsichtbar. Das ist kein Problem, solange jede Unterkategorie auf ihrer übergeordneten Kategorieseite als normaler Link steht und jede Seite Brotkrumen bis zur Startseite führt. Google formuliert die Regel schlicht: Jede Seite, auf die es Ihnen ankommt, sollte von mindestens einer anderen Seite der Website verlinkt sein (Google Search Central). Brotkrumen zeigen die Lage einer Seite in der Hierarchie, und als BreadcrumbList ausgezeichnet werden sie für die Suche lesbar (Google Search Central).

Damit ist die Navigation nicht mehr der einzige Weg zu den Kategorien, sondern einer von mehreren. Für die Barrierefreiheit gilt dasselbe: Das W3C rät, die Einträge eines Untermenüs zusätzlich auf der Seite des übergeordneten Menüpunkts zu wiederholen, weil Menschen mit eingeschränkter Feinmotorik Ausklappmenüs oft schwer bedienen können (W3C WAI). Eine Kategorieseite, die ihre Unterkategorien als Kacheln oder Liste zeigt, löst beide Aufgaben zugleich. Eine Zusage über Rankings ist das nicht; es sichert nur, dass kein Ziel allein am Menü hängt.

Ein zweiter Punkt betrifft die Größe. Für die Google-Suche liest Googlebot die ersten 2 MB einer unterstützten Datei (Google Search Central), und diese Grenze gilt für die unkomprimierten Daten (Google Search Central). In der Regel liegen Shopseiten weit darunter. Weil die Navigation aber am Anfang des Dokuments steht, verbraucht ein aufgeblähtes Menü dieses Budget zuerst, vor Produkttext und Bewertungen weiter unten. Wer ohnehin große Seiten ausliefert, etwa lange Listings mit vielen Varianten, sollte die Summe aus Menü und Inhalt deshalb einmal unkomprimiert messen.

Viele Megamenüs hängen an einer Bibliothek, die Mausbewegungen auswertet, Panels positioniert, Zeitgeber setzt und Klassen umschaltet. Für das Öffnen beim Überfahren braucht es das meist nicht. CSS kann ein Panel zeigen, solange der Zeiger auf dem Hauptpunkt oder dem Panel liegt, und es kann Öffnen und Schließen verzögern. Das bildet die Absicht beim Überfahren ab: Wer mit der Maus quer über die Leiste zum Suchfeld fährt, soll nicht jedes Panel auf dem Weg aufklappen lassen, und wer schräg vom Hauptpunkt ins Panel zieht, soll es nicht unterwegs verlieren.

Das W3C-Tutorial zu Ausklappmenüs verzögert das Schließen mit einem Zeitgeber, damit ungenaue Mausbewegungen das Menü nicht sofort zuklappen; im Beispiel ist es eine Sekunde (W3C WAI). In CSS übernehmen das die verzögerten Übergänge auf opacity und visibility: Das Panel blendet erst nach einer Viertelsekunde aus und bleibt bis dahin bedienbar. Die Werte im Beispiel oben sind Startpunkte für eigene Tests, keine Vorgabe. Die Bedingung (hover: hover) sorgt dafür, dass Touch-Geräte dieses Verhalten gar nicht erst bekommen; dort öffnet der Button. Animiert wird nur opacity, nicht Höhe oder Position, damit kein Layout neu berechnet werden muss.

Inhalte, die beim Überfahren erscheinen, müssen laut Erfolgskriterium 1.4.13 der WCAG 2.2 drei Bedingungen erfüllen: Sie lassen sich schließen, ohne Zeiger oder Fokus zu bewegen, der Zeiger kann über den neuen Inhalt fahren, ohne dass er verschwindet, und sie bleiben sichtbar, bis der Auslöser wegfällt (W3C). Ein Panel, das direkt am Hauptpunkt anschließt und mit Escape schließt, erfüllt das. Eine Lücke von wenigen Pixeln zwischen Leiste und Panel lässt es dagegen beim Hinüberfahren zuklappen. Für Escape und den Zustand des Buttons genügen wenige Zeilen Skript am nav-Element; das ist kein Vergleich zu einer Menübibliothek.

Mit dem Attribut interestfor gibt es inzwischen einen eingebauten Weg, Interesse per Überfahren, Fokus oder langem Drücken zu erkennen. Er läuft aber bisher nur in Chrome und Edge ab Version 142, nicht in Firefox und Safari (Web Features Explorer). Für ein Hauptmenü ist er darum eine Ergänzung für später, keine Grundlage.

Für den INP-Wert gilt eine Besonderheit: Überfahren, Zoomen und Scrollen zählen nicht als Interaktion, gemessen werden Klicks, Tippen und Tastendrücke (web.dev). Ein Megamenü, das beim Überfahren schwere Arbeit startet, taucht im INP darum nicht direkt auf. Es kann aber den Klick verzögern, der unmittelbar danach kommt, wenn der Hauptthread dann noch beschäftigt ist. Auf dem Handy ist der Fall eindeutig: Dort öffnet ein Tippen das Menü, und genau dieses Tippen wird gemessen.

Darum lohnt es sich, den Zustand am Menü zu halten und nicht am body. Eine Klasse am Listenpunkt betrifft in der Regel nur dessen Teilbaum, eine Klasse am body kann Selektoren auf der ganzen Seite neu auswerten lassen. Wer beim Öffnen die Seite dahinter abdunkeln möchte, legt dafür ein eigenes Element über den Inhalt, statt eine Regel am body umzuschalten. Und wer das Scrollen der Seite hinter der Schublade sperren muss, setzt die Sperre einmal und nicht bei jeder Bewegung neu.

Die Navigation ist auf allen Seiten eines Shops gleich, zumindest für alle Besucher einer Sprache und eines Verkaufskanals. Trotzdem wird sie in vielen Systemen bei jedem Seitenaufbau neu berechnet: Kategorien laden, Sichtbarkeit prüfen, Links erzeugen, Markup schreiben. Das kostet Serverzeit vor dem ersten Byte und bindet die Navigation an die Lebensdauer jeder einzelnen Seite. Ändert sich ein Preis, verfällt mit der Produktseite auch das Menü, obwohl es sich nicht geändert hat.

Besser ist ein eigenes Fragment mit eigener Lebensdauer. Shopware geht diesen Weg seit Version 6.7: Kopf- und Fußbereich werden per ESI geladen (Shopware), und das erlaubt, sie getrennt vom Rest der Seite zu cachen (Shopware). Ändert sich ein Produktpreis, muss die Navigation nicht neu entstehen; ändert sich eine Kategorie, wird das Fragment ungültig, ohne dass jede Seite allein wegen des Menüs neu aufgebaut werden muss. In anderen Systemen erreichen Sie dasselbe mit einem serverseitigen Include, das den Menüteil getrennt zwischenspeichert, oder mit einem eigenen Cache-Eintrag, der beim Speichern einer Kategorie gelöscht wird.

Für die Fragmente der dritten Ebene ist die Lage noch einfacher. Sie sind für alle Besucher gleich und lassen sich als statische Dateien mit langer Cachedauer ausliefern, wenn ihre Adresse eine Version trägt, die sich mit dem Kategoriebaum ändert. Ein neuer Baum bekommt eine neue Adresse, alte Kopien laufen einfach aus. Der Server muss dann für ein geöffnetes Menü keine einzige Datenbankabfrage mehr ausführen.

Heikel wird es, wenn die Navigation persönliche Teile enthält: den Namen im Kontomenü, die Zahl im Warenkorb, eine Kundengruppe mit eigenen Kategorien. Steht das im selben Fragment, zerfällt der Cache in viele kleine Varianten. Solche Teile kommen getrennt nach oder werden im Browser ergänzt. Warum schon ein einzelnes Cookie die Trefferquote zerlegen kann, beschreibt der Beitrag Ein Cookie zerlegt den Cache; welche Cache-Schichten im Shop zusammenspielen, erklären wir auf der Seite Caching-Strategien.