Elementor-Menü funktioniert nach WP Rocket nicht mehr: die Lösung

Schritt 1: jQuery als Ausnahme eintragen

1. Öffne Einstellungen → WP Rocket → JavaScript & CSS.
2. Direkt unter JavaScript verzögert laden steht das Feld JavaScript-Ausnahmen. Trag dort diese Zeile ein:

/jquery-?[0-9.](.*)(.min|.slim|.slim.min)?.js

Schritt 2: Ein-Klick-Exklusionen, falls du JavaScript-Ausführung verzögern nutzt

1. Ist JavaScript-Ausführung verzögern eingeschaltet, öffne darunter die Ein-Klick-Exklusionen.
2. Klapp Plugins auf.
3. Hake Elementor, Elementor Pro und Elementor Pro – SmartMenus an. Nutzt du in Elementor das Nachladen von Hintergrundbildern, zusätzlich Elementor – Lazy Load Background Images.

Schritt 3: Speichern und richtig testen

1. Klick auf Änderungen speichern und optimieren. WP Rocket leert dabei den Cache.
2. Am Handy testen, und zwar so:

• in einem privaten Fenster, damit nichts aus dem Browser-Cache kommt
• nicht scrollen, als Erstes aufs Menü tippen
• mehrmals neu laden und wiederholen

Mehrmals ist wichtig. Der Fehler tritt nicht jedes Mal auf, siehe unten.

Warum das passiert

JavaScript verzögert laden verschiebt alle Skripte ans Ende, auch jQuery. jQuery meldet dann „fertig“, während die anderen Skripte noch laden. Elementor startet darauf sofort und gibt sein Startsignal. Ist Elementor Pro in diesem Moment noch nicht geladen, verpasst es das Signal.

Menü, Slider und Popup kommen aus Elementor Pro. Sie werden dann nie aktiviert. Es gibt keine Fehlermeldung, die Seite sieht ganz normal aus, sie reagiert nur nicht.

Es ist ein Wettlauf: Mal ist Elementor Pro schnell genug, mal nicht. Deshalb ist der Fehler so schwer zu finden. So oft hat es in unserem Labor funktioniert, je 12 frische Aufrufe am Handy:

In der ersten Zeile war nur JavaScript verzögert laden an. In den anderen Zeilen kamen LazyLoad, Bildabmessungen und Schriften dazu. Ohne die jQuery-Ausnahme klappte es also nur bei etwa jedem zweiten Aufruf, ganz egal, wie die Hintergrundbilder eingestellt waren.

Mit der jQuery-Zeile lädt jQuery wieder normal, und sein „fertig“ kommt erst, wenn alle anderen Skripte da sind. Messbar kostet das auf unserer Seite praktisch nichts: Der LCP am Handy (die Zeit, bis das größte Element sichtbar ist) lag bei 3,87 statt 3,80 Sekunden. Das liegt innerhalb der Messschwankung von etwa ±0,15 Sekunden. Dafür funktioniert die Seite bei jedem Aufruf.

Wenn es dann immer noch nicht geht

• Prüfe, ob WP Rocket wirklich die Ursache ist: Hänge ?nowprocket=1 an die Adresse deiner Seite. Dann liefert WP Rocket sie ohne Optimierung aus. Funktioniert das Menü so, liegt es an WP Rocket.
• Schalte JavaScript verzögert laden testweise aus. Geht das Menü danach, fehlt eine Ausnahme. Nutzt du Elementor-Erweiterungen (zum Beispiel Menü-Add-ons), brauchen deren Skripte eventuell eigene Ausnahmen. In den Ein-Klick-Exklusionen stehen viele davon schon bereit.
• JavaScript-Ausführung verzögern ohne Ausnahmen: In unserem Test öffnete sich das Menü dann erst etwa 1,9 Sekunden nach dem ersten Tipp, und der Slider startete erst nach der ersten Berührung. Lighthouse zeigt mit dieser Option zwar eine schnellere Seite, aber nur, weil es die Seite nie berührt und die verzögerten Skripte deshalb gar nicht lädt. Wir lassen sie bei Elementor aus. Die ganze Messung steht in JavaScript-Ausführung verzögern mit Elementor.
• Cache von Server oder CDN: Wenn dein Hoster oder ein CDN zusätzlich cacht, dort ebenfalls leeren.

Alle Messwerte und die komplette Einstellung findest du in WP Rocket für Elementor einrichten.

Für Technikinteressierte: so haben wir es geprüft

• Labor: WordPress 7.1.4, PHP 8.4, Elementor 4.3.6, Elementor Pro 4.3.2, WP Rocket 3.24 mit „Nicht benutztes CSS entfernen“, „JavaScript verzögert laden“, LazyLoad und Schriften. Referenzseite mit Burger-Menü (Elementor Pro Nav Menu), Kundenstimmen-Slider und Popup. Methodik
• Test: 12 frische Browser je Variante, am 8. November 2026, Handy-Ansicht. Seite laden, 1,5 Sekunden warten, Slider prüfen, aufs Menü tippen, nach 1 Sekunde prüfen, ob es offen ist. Vor jeder Variante haben wir automatisch geprüft, dass das CSS vollständig ausgeliefert wird (146 bis 147 KB benutztes CSS).
• Nachweis der Ursache: Wir haben mitgeschrieben, wann elementorFrontend.init() aufgerufen wird und wann elementorProFrontend existiert. Über die drei Varianten ohne jQuery-Ausnahme gab es 18 fehlerhafte Aufrufe. In 10 davon startete Elementor nachweislich vor Elementor Pro (4 von 7, 3 von 6 und 3 von 5). Ein Beispiel: Elementor startete nach 922 Millisekunden, Elementor Pro war erst nach 927 da. In den übrigen 8 zeigte unsere Messung keinen Unterschied in der Reihenfolge, auch dort half die jQuery-Ausnahme. Konsolenfehler gab es keine.
• Die Ausnahme: exclude_defer_js = /jquery-?[0-9.](.*)(.min|.slim|.slim.min)?.js. jQuery und jQuery Migrate bekommen dann kein defer mehr.
• Rohdaten: Rohdaten der neuen Messung mit allen Aufrufen und Zeitstempeln. Erstmals geprüft am 7. November 2026, mit vollständigem CSS neu getestet am 8. November 2026.
• Transparenz: Die erste Version dieses Artikels nannte andere Häufigkeiten (zwei Runden mit je 12 Aufrufen). Diese Messung lief ohne CSS, weil der Dienst von Nicht benutztes CSS entfernen hinter unserem Passwortschutz die CSS-Dateien nicht laden konnte und den Vorgang trotzdem als abgeschlossen meldete. Bei der neuen Messung haben wir das CSS deshalb automatisch geprüft. Ursache und Lösung haben sich durch die Korrektur nicht geändert.