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, geprüft in 12 frischen Seitenaufrufen.

* 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 Zahlen sind kein echter Gewinn, und auch die kürzere Ladezeit in dieser Zeile kommt zum Teil daher.

Wie genau sind die Zahlen? Dieselbe empfohlene Einstellung ergab in einer zweiten Messreihe am selben Tag 4,02 statt 3,87 Sekunden mobil. Unterschiede unter etwa 0,15 Sekunden sind also nicht belastbar.

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 fast doppelt so schnell (0,38 statt 0,67 Sekunden). Mobil ist die Seite trotzdem nicht schneller (4,54 statt 4,53 Sekunden), am Desktop nur ein wenig (1,24 statt 1,31). Das Handy wartet nämlich kaum auf den Server, sondern vor allem auf CSS- und JavaScript-Dateien, Bilder und Schriften. Da setzen die nächsten Einstellungen an, jede mit einem kleinen Beitrag.

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. Mobil bringt das auf unserer Seite wenig (4,54 → 4,44 Sekunden, fast in der Messschwankung), am Desktop 1,24 → 1,19 Sekunden. Dafür braucht die Seite 20 Anfragen weniger (66 → 46), weil WP Rocket die einzelnen CSS-Dateien durch ein eingebettetes, bereinigtes CSS ersetzt.

Gut zu wissen: Das bereinigte CSS berechnet WP Rocket nicht auf deinem Server, sondern auf eigenen Servern. Die rufen deine Seite und deren CSS-Dateien dafür selbst ab. Bis das Ergebnis da ist, vergeht etwa eine Minute pro Seite. Liegt deine Seite hinter einem Passwortschutz, zum Beispiel als Staging-Seite, musst du den WP-Rocket-Servern nicht nur die Seite freigeben, sondern auch die CSS-, JavaScript- und Schriftdateien. Sonst meldet WP Rocket trotzdem „fertig“ und liefert leeres CSS aus. Genau das ist uns passiert (siehe Korrektur oben).

So prüfst du das:

1. Öffne deine Seite in einem privaten Fenster.
2. Lass dir den Quelltext anzeigen und suche nach wpr-usedcss.

Steht in diesem Block viel CSS (bei uns rund 146 KB), hat alles geklappt. Ist er leer oder sieht die Seite plötzlich nackt aus, kommt der WP-Rocket-Dienst nicht an deine Dateien.

JavaScript & CSS: JavaScript-Dateien

1. JavaScript minifizieren ist ab Werk an. So lassen.
2. JavaScript verzögert laden einschalten. Mobil von 4,44 auf 4,09 Sekunden, am Desktop von 1,19 auf 1,07.
3. Wichtig: Im Feld JavaScript-Ausnahmen direkt darunter diese Zeile eintragen:

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

Ohne diese Zeile fallen Menü, Slider und Popup von Elementor Pro in etwa jedem zweiten Seitenaufruf aus. Warum, steht im nächsten Abschnitt. Die Ausnahme kostet kaum Zeit: mobil 3,87 statt 3,80 Sekunden, das liegt in der Messschwankung, am Desktop 0,86 statt 0,79 Sekunden. 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.

LazyLoad und Bildabmessungen bringen mobil gut 0,2 Sekunden (4,09 → 3,86) und machen die Seite leichter: 713 → 611 KB. Die Schriften ändern mobil kaum etwas (3,80 Sekunden), am Desktop aber deutlich: 1,11 → 0,79 Sekunden, dazu 10 Anfragen weniger. Das Seitengewicht steigt dabei wieder auf 730 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: In einem fehlerhaften Aufruf startete Elementor nach 922 Millisekunden, Elementor Pro war erst nach 927 Millisekunden geladen. Fünf Millisekunden entscheiden also, ob dein Menü funktioniert.

So oft funktionierten Menü und Slider, je 12 frische Seitenaufrufe mobil:

Sobald JavaScript verzögert laden ohne jQuery-Ausnahme an ist, geht es in etwa jedem zweiten Aufruf schief. Ob LazyLoad für CSS-Hintergrundbilder an ist, spielt dabei kaum eine Rolle. In 4 der 7 Fehlschläge direkt nach dem Einschalten war Elementor Pro nachweislich noch nicht geladen, als Elementor startete. Tückisch ist, dass es eben nicht immer schiefgeht: Beim eigenen Test kann alles gut aussehen. Mit jQuery als Ausnahme lief es bei uns in allen Aufrufen.

So prüfst du deine Seite:

1. Öffne sie mehrmals in einem privaten Fenster am Handy, ohne zu scrollen.
2. 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 gut aus: 3,32 statt 3,80 Sekunden und 459 statt 730 KB. Das ist größtenteils eine Täuschung. Echte Besucher laden die Skripte beim ersten Tippen trotzdem. Und 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, in allen 12 Aufrufen. Gemessen lädt die Seite dann mobil in 3,57 Sekunden, also 0,3 Sekunden schneller als unsere Empfehlung. Auch hier lädt Lighthouse aber ein verzögertes Skript gar nicht. Dafür öffnete sich das Menü beim ersten Tipp erst nach etwa 0,2 statt nach 0,02 Sekunden. Das merkt man. Für eine Elementor-Seite wie unsere lohnt sich das nicht. Genaue Messwerte zum ersten Tipp stehen in JavaScript-Ausführung verzögern mit Elementor.

Was WP Rocket sendet und empfängt

Wir haben jeden Zustand mit unserem Connection Monitor aufgezeichnet:

• Ab Werk: WP Rocket fragt gelegentlich bei api.wp-rocket.me nach Preisen und nach Updates (check_update.php), bei uns zweimal direkt nach dem Einrichten. Während der Messung selbst gab es keine Verbindung nach außen.
• 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“), dazu die CSS-Dateien der Seite.
• Mit „Google Fonts selbst hosten“: Dein Server lädt die Schriften einmalig bei Google herunter, bei uns 6 CSS-Abrufe und 25 Schriftdateien mit zusammen rund 1,1 MB. 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: im Quelltext prüfen, ob im Block wpr-usedcss wirklich CSS steht
• 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, und zusätzlich geprüft, dass das ausgelieferte bereinigte CSS mindestens 10 KB groß ist. Es waren in jeder Stufe 146 bis 147 KB.
• Messschwankung: Die Empfehlung ergab in einer zweiten Messreihe am selben Tag 4,02 statt 3,87 Sekunden mobil. Unterschiede unter etwa 0,15 Sekunden werten wir deshalb nicht als echten Unterschied. Die Server-Antwortzeit (TTFB) lag mobil ohne Cache-Plugin bei 674 Millisekunden, mit WP Rocket bei 377.
• 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 in jeder Stufe 12 frische Aufrufe mit Zeitstempeln für den Start von Elementor und Elementor Pro. In allen fehlerhaften Aufrufen startete Elementor, bevor der Browser DOMContentLoaded meldete, in allen funktionierenden erst danach.
• 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.
• Korrektur vom 8. November 2026: Unser Labor liegt hinter einem Passwortschutz. Freigegeben hatten wir für den WP-Rocket-Dienst nur die Seite selbst, nicht deren CSS-, JavaScript- und Schriftdateien. Der Dienst meldete trotzdem „completed“, das ausgelieferte bereinigte CSS war aber leer. Alle Werte ab „Nicht benutztes CSS entfernen“ stammten deshalb von einer Seite ohne CSS und waren viel zu gut. Jetzt sind die statischen Dateien nur für die offiziellen IP-Adressen von WP Rocket freigegeben, und unsere Testskripte brechen ab, wenn das bereinigte CSS kleiner als 10 KB ist. Alle Stufen haben wir neu gemessen, die alten Messdaten archiviert. Unsere frühere Beobachtung, dass der Elementor-Fehler vor allem zusammen mit LazyLoad für CSS-Hintergrundbilder auftritt, hat sich mit echtem CSS nicht bestätigt: Er tritt auf, sobald „JavaScript verzögert laden“ ohne jQuery-Ausnahme an ist.
• Transparenz: Davor hatten wir schon zwei Messreihen 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 vierten Reihe vom 8. November 2026.
• Rohdaten: messdaten.csv mit allen Läufen. Gemessen am 7. und 8. November 2026.