WP Rocket für Elementor einrichten: jede Einstellung gemessen

Das Ergebnis

Dieselbe Elementor-Seite, Einstellung für Einstellung, jeweils fünfmal mobil und fünfmal am Desktop gemessen. Die Tabelle zeigt den Median. In der letzten Spalte steht, ob Menü, Slider und Popup danach noch funktionierten.

* Lighthouse berührt die Seite nie, also lädt WP Rocket die Skripte bei der Messung gar nicht. Echte Besucher laden sie beim ersten Tippen oder Scrollen trotzdem. Diese Zahl ist kein echter Gewinn.

Warum der Cache allein nicht reicht

Ab Werk cacht WP Rocket die Seite, minifiziert CSS und JavaScript und lädt Links vor. Die erste Antwort des Servers kommt dadurch doppelt so schnell (0,79 statt 0,38 Sekunden). Mobil ist die Seite trotzdem nicht schneller. Das Handy wartet nämlich nicht auf den Server, sondern auf CSS-Dateien und Google Fonts, die den Aufbau blockieren. Genau da setzen die nächsten Einstellungen an.

Die Einstellungen Schritt für Schritt

Alle Einstellungen findest du unter Einstellungen → WP Rocket. Nach jeder Änderung unten auf Änderungen speichern und optimieren klicken.

JavaScript & CSS: CSS-Dateien

1. CSS minifizieren ist ab Werk an. So lassen.
2. CSS-Darstellung optimieren einschalten und Nicht benutztes CSS entfernen wählen. Das ist der größte einzelne Gewinn: mobil von 4,68 auf 2,06 Sekunden, 293 KB weniger.

Gut zu wissen: Das bereinigte CSS berechnet WP Rocket nicht auf deinem Server, sondern auf eigenen Servern. Die rufen deine Seiten dafür selbst ab. Hinter einem Passwortschutz klappt das nicht (dazu mehr unten). Bis das Ergebnis da ist, vergeht etwa eine Minute pro Seite.

JavaScript & CSS: JavaScript-Dateien

1. JavaScript minifizieren ist ab Werk an. So lassen.
2. JavaScript verzögert laden einschalten. Mobil von 2,06 auf 1,02 Sekunden.
3. Wichtig: Im Feld JavaScript-Ausnahmen direkt darunter diese Zeile eintragen:

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

Ohne diese Zeile startet Elementor manchmal, bevor Elementor Pro geladen ist. Was dann passiert und wie oft, steht im nächsten Abschnitt. Die Ausnahme kostet etwas Zeit (1,46 statt 1,03 Sekunden), weil jQuery wieder normal lädt. Dafür funktioniert die Seite zuverlässig.

JavaScript-Ausführung verzögern lassen wir aus. Warum, steht weiter unten.

Image & Media

1. Unter LazyLoad: Für Bilder aktivieren, Für CSS-Hintergrundbilder aktivieren und Für iframes und Video aktivieren einschalten.
2. Unter Bildabmessungen: Fehlende Bildabmessungen hinzufügen einschalten.
3. Unter Schriften: Fonts vorladen und Google Fonts selbst hosten einschalten.

Schneller wird die Seite dadurch kaum, aber leichter: von 443 auf 335 KB. Und mit Google Fonts selbst hosten kontaktieren die Browser deiner Besucher keinen Google-Server mehr. Das ist auch für den Datenschutz wichtig. Mehr dazu in Google Fonts lokal einbinden.

Cache füllen

Vorladen aktivieren und Vorladen von Links aktivieren sind ab Werk an. So lassen. Damit baut WP Rocket den Cache für alle Seiten selbst auf, statt auf den ersten Besucher zu warten.

Was bei Elementor kaputtgehen kann

In unserem Test fielen Menü, Slider und Popup in manchen Stufen einfach aus. Keine Fehlermeldung, kein Hinweis, die Seite sah normal aus. Nur reagierte das Burger-Menü nicht und der Slider stand still.

Die Ursache: JavaScript verzögert laden verschiebt auch jQuery nach hinten. 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 da, verpasst es das Signal. Menü, Slider und Popup kommen aber aus Elementor Pro und werden dann nie aktiviert. Das ist ein Wettlauf: Mal gewinnt Pro, mal nicht. Wir haben es mit Zeitstempeln nachgewiesen: Im fehlerhaften Aufruf startete Elementor nach 1.828 Millisekunden, Elementor Pro war erst nach 1.849 Millisekunden geladen.

So oft ging es schief, je 24 frische Seitenaufrufe mobil (zwei Runden mit je 12):

Mit LazyLoad für CSS-Hintergrundbilder verschiebt sich das Timing so, dass es meistens schiefgeht. Ohne fällt es nur selten auf, bei uns in einem von 24 Aufrufen. Genau das macht den Fehler so tückisch: Beim eigenen Test sieht alles gut aus. Mit jQuery als Ausnahme lief es bei uns in allen Aufrufen.

So prüfst du deine Seite: Öffne sie mehrmals in einem privaten Fenster am Handy, ohne zu scrollen, und tippe als Erstes auf das Menü. Öffnet es sich nicht oder steht ein Slider still, fehlt die Ausnahme.

Warum wir „JavaScript-Ausführung verzögern“ nicht empfehlen

Diese Option lädt JavaScript erst, wenn jemand die Seite berührt, scrollt oder die Maus bewegt. Lighthouse macht das nie, deshalb sehen die Messwerte traumhaft aus: 37 KB statt 335 KB. Das ist eine Täuschung. Echte Besucher laden die Skripte beim ersten Tippen trotzdem.

In unserem Test brachte die Option mobil keine schnellere Ladezeit (1,02 statt 1,03 Sekunden). Ohne Ausnahmen startete Elementor erst nach der ersten Berührung, der Slider stand bis dahin still. Mit den Ein-Klick-Exklusionen für Elementor und Elementor Pro lief alles, aber das Menü öffnete sich beim ersten Tipp erst nach etwa einer Sekunde statt sofort. Für eine Elementor-Seite wie unsere lohnt sich das nicht.

Was WP Rocket sendet und empfängt

Wir haben jeden Zustand mit unserem Connection Monitor aufgezeichnet:

• Ab Werk: Während der Messung keine einzige Verbindung nach außen, auch keine Lizenzprüfung.
• Mit „Nicht benutztes CSS entfernen“: Pro Seite ein Auftrag an saas.wp-rocket.me. Mitgeschickt werden die Adresse der Seite, die E-Mail-Adresse deines WP-Rocket-Kontos und dein Lizenzschlüssel. Zurück kommt das bereinigte CSS. Laut Antwort läuft der Auftrag in einer EU-Warteschlange. Danach ruft ein WP-Rocket-Server deine Seite selbst ab (bei uns von 46.30.212.202, Kennung „WP-Rocket-SaaS“).
• Mit „Google Fonts selbst hosten“: Dein Server lädt die Schriften einmalig bei Google herunter, bei uns 3 CSS-Abrufe und 25 Schriftdateien mit zusammen 843 KB. Danach gibt es im Browser deiner Besucher keine Anfrage mehr an fremde Server.

Daten von Besuchern schickt WP Rocket dabei nicht. Für deine Datenschutzerklärung ist aber gut zu wissen, dass mit „Nicht benutztes CSS entfernen“ ein externer Dienst deine Seiten abruft.

Prüfliste

• JavaScript & CSS: CSS minifizieren an, CSS-Darstellung optimieren mit Nicht benutztes CSS entfernen
• JavaScript & CSS: JavaScript minifizieren und JavaScript verzögert laden an, jQuery-Zeile in JavaScript-Ausnahmen
• JavaScript & CSS: JavaScript-Ausführung verzögern aus
• Image & Media: alle drei LazyLoad-Optionen, Fehlende Bildabmessungen hinzufügen, Fonts vorladen, Google Fonts selbst hosten
• Cache füllen: Vorladen aktivieren und Vorladen von Links aktivieren an (ab Werk)
• Danach: Seite mehrmals mobil in einem privaten Fenster öffnen, Menü, Slider und Popup ohne vorheriges Scrollen testen

Erst einmal Elementor selbst optimieren? Das steht in Elementor schneller machen.

Für Technikinteressierte: Testaufbau und Rohdaten

• Labor: WordPress 7.1.4, PHP 8.4, Hello Elementor 3.5, Elementor 4.3.6, Elementor Pro 4.3.2, WP Rocket 3.24, Shared Hosting bei All-Inkl. Referenzseite mit Hero-Bild, Icon-Boxen, Kundenstimmen-Slider, Galerie, Akkordeon, Formular und Popup. Methodik
• Messung: Lighthouse 13.5.0, je 5 Läufe mobil (gedrosselt) und Desktop nach einem Aufwärm-Abruf. Vor jeder Stufe Labor auf denselben Snapshot zurückgesetzt, Cache geleert, bei „Nicht benutztes CSS entfernen“ gewartet, bis WP Rocket „completed“ meldete.
• Ausgangszustand: WP Rocket mit allen 79 Standardwerten einer Neuinstallation. Ab Werk sind minify_css, minify_js, manual_preload, preload_links und das mobile Caching an.
• Funktionstest in jeder Stufe mit einem automatisierten Browser auf exakt der gemessenen Adresse: Burger-Menü, Slider, Akkordeon, Formular, Popup, Konsolenfehler. Zusätzlich ein Test ganz ohne Interaktion (laden, nichts anfassen, dann erster Tipp aufs Menü) und für die Empfehlung 12 frische Aufrufe mit Zeitstempeln für den Start von Elementor und Elementor Pro.
• Die Ausnahme: exclude_defer_js = /jquery-?[0-9.](.*)(.min|.slim|.slim.min)?.js. Damit läuft jQuery wieder normal im Kopf der Seite und löst sein „ready“ erst aus, wenn alle verzögerten Skripte geladen sind.
• Transparenz: Zwei Messreihen haben wir verworfen. In der ersten fehlte im Labor-Snapshot die Einstellung für mobiles Caching, und unser Passwortschutz blockierte die WP-Rocket-Server. In der zweiten rief der Funktionstest die Seite mit einem angehängten Parameter auf, den WP Rocket nicht optimiert. Er hat also eine andere Seite geprüft als die gemessene und den Elementor-Fehler übersehen. Alle Werte oben stammen aus der dritten, korrigierten Reihe. Die Empfehlung haben wir danach unter gleichen Bedingungen nachgemessen.
• Rohdaten: messdaten.csv mit allen Läufen. Gemessen am 7. November 2026.