Elementor langsam — woran es wirklich liegt.

Erst messen.

Bevor irgendetwas geändert wird: messen. Und zwar an den Seiten, die wirklich besucht werden — Startseite, wichtigste Leistungsseiten, Kontakt — und getrennt für Mobilgeräte und Desktop.

Die Messwerte zeigen die Richtung: Ein schlechter Wert für den größten sichtbaren Inhalt deutet auf Bilder, Schriften oder blockierende Dateien. Ein schlechter Wert für die Reaktionszeit deutet auf zu viel Skript. Verschiebungen beim Laden deuten auf fehlende Größenangaben (Tempobericht lesen).

Wichtig ist auch die Server-Antwortzeit. Ist sie hoch, nützt die beste Optimierung im Browser wenig — dann liegt die Bremse beim Hosting oder in der Datenbank (Langsam trotz Hosting).

Verschachtelung.

Jedes Element in Elementor erzeugt HTML. Ein Abschnitt mit einer Spalte, darin ein innerer Abschnitt mit zwei Spalten, darin je ein Widget — das sind schnell zehn verschachtelte Ebenen für einen Textblock mit Bild.

Viele Ebenen bedeuten: mehr HTML, mehr CSS-Regeln, mehr Arbeit für den Browser beim Aufbauen und bei jeder Interaktion. Auf leistungsstarken Rechnern merkt man das kaum, auf älteren Mobilgeräten sehr deutlich.

Die Frage bei jeder Seite lautet: Braucht dieser Rahmen wirklich einen eigenen Container? Oft lassen sich zwei, drei Ebenen einsparen, ohne dass sich optisch etwas ändert.

Container statt Abschnitte.

Elementor hat vor einigen Jahren das alte Aufbaumodell aus Abschnitten und Spalten durch flexible Container ersetzt. Container erzeugen deutlich weniger HTML und lassen sich ineinander schachteln, ohne für jede Ebene Spalten zu brauchen.

Viele ältere Websites laufen noch auf dem alten Modell. Für die Ladezeit lohnt die Umstellung — besonders bei Seiten mit vielen inneren Abschnitten. Sie ist aber kein Knopfdruck, sondern eine Überarbeitung, die man Seite für Seite plant (Container umstellen).

Mit Elementor 4 kommt eine weitere Ebene hinzu: die neuen Atomic-Elemente, die noch schlankeren Code erzeugen sollen. Für neue Seiten ist das interessant, für bestehende Websites ein Thema für die Planung, nicht für hektische Umbauten (Elementor 4).

Zusatzpakete.

Der größte einzelne Bremsfaktor, den ich bei Elementor-Websites finde. Zusatzpakete mit Dutzenden Widgets laden oft ihre Skripte und Stylesheets auf jeder Seite — auch dort, wo keines ihrer Widgets verwendet wird.

Drei oder vier solcher Pakete parallel sind keine Seltenheit, und meist wird von jedem nur eine Handvoll Widgets genutzt. Manche Pakete erlauben, ungenutzte Widgets abzuschalten. Besser ist, Pakete ganz zu entfernen, deren Funktion sich mit Elementor selbst oder einem anderen Paket abdecken lässt (Addons aufräumen).

Schriften und Symbole.

Typisches Bild: Das Theme lädt eine Schrift, Elementor eine zweite, ein Zusatzpaket eine dritte, und dazu kommen zwei Symbolsätze. Jede Schrift in mehreren Stärken ist eine eigene Datei.

Die Lösung: Schriften auf zwei Familien mit wenigen Stärken begrenzen, lokal ausliefern statt von fremden Servern, und Symbolsätze nur laden, wenn sie gebraucht werden. Elementor bietet Optionen, um Symbolsätze schlanker oder als eingebettete Grafiken zu laden (Schriften optimieren, Google Fonts lokal).

Bilder.

Ein großes Hintergrundbild im Kopfbereich ist auf vielen Elementor-Websites der größte sichtbare Inhalt — und bestimmt damit den wichtigsten Ladewert. Als CSS-Hintergrund wird es zudem später entdeckt als ein normales Bild.

Was hilft: das Bild in passender Größe und modernem Format bereitstellen, für Mobilgeräte eine kleinere Fassung, und den Kopfbereich nicht verzögert laden. Bilder weiter unten dagegen erst bei Bedarf laden (Bilder optimieren, LCP verbessern).

Animationen und Effekte.

Einblend-Animationen, Parallaxe, Bewegungseffekte beim Scrollen — Elementor macht sie mit wenigen Klicks möglich. Jede davon kostet Rechenzeit im Browser, und Einblend-Animationen im sichtbaren Bereich verzögern zusätzlich, wann Inhalte erscheinen.

Meine Faustregel: keine Animation im ersten sichtbaren Bereich, sparsam darunter, und Bewegungseffekte nur dort, wo sie einen Zweck haben. Wer Bewegung reduziert eingestellt hat, sollte sie auch nicht sehen (INP verbessern).

Elementors Leistungsoptionen.

Elementor bringt selbst eine Reihe von Leistungsoptionen mit: optimiertes Laden von Skripten und Stylesheets nur dort, wo sie gebraucht werden, schlankere Symbolsätze, verzögertes Laden von Hintergrundbildern und Ähnliches.

Auf neuen Installationen sind viele davon eingeschaltet. Auf Websites, die seit Jahren laufen, stehen sie oft noch auf dem alten Stand. Ein Blick in die Einstellungen lohnt — aber nicht alles auf einmal einschalten: Jede Option einzeln aktivieren und danach prüfen, ob die Darstellung stimmt.

Caching.

Ein Seiten-Cache liefert fertige Seiten aus, statt sie bei jedem Aufruf neu zu erzeugen. Für Elementor-Websites ist das besonders wirksam, weil das Zusammensetzen einer Elementor-Seite auf dem Server vergleichsweise aufwendig ist.

Wichtig: Nach Änderungen müssen sowohl der Seiten-Cache als auch Elementors erzeugte Stylesheets erneuert werden, sonst sehen Besucher alte Fassungen (Caching einrichten).

Langsamer Editor.

Ein langsamer Editor ist ein anderes Problem als eine langsame Website. Er hängt vor allem an Speicherlimit, Serverleistung, der Zahl installierter Erweiterungen und der Größe der Seite. Sehr lange Seiten mit Hunderten Elementen werden im Editor zäh — ein Grund mehr, sie aufzuteilen (Editor lädt nicht).

Die Reihenfolge.

1. Messen — Seiten, Geräte, Server-Antwortzeit.
2. Zusatzpakete ausmisten.
3. Schriften und Symbole reduzieren.
4. Bilder im sichtbaren Bereich optimieren.
5. Elementors Leistungsoptionen einzeln prüfen.
6. Caching sauber einrichten.
7. Verschachtelung und Container auf den wichtigsten Seiten überarbeiten.
8. Erneut messen.

Die ersten vier Punkte bringen meist den größten Gewinn bei geringstem Aufwand. Die Container-Umstellung ist wirksam, aber aufwendig — sie kommt am Ende und gezielt (Page-Builder und Ladezeit).

Wenn du nicht weiterkommst.

Wenn deine Elementor-Website zu langsam ist und du wissen willst, was sich mit vertretbarem Aufwand herausholen lässt. Ich finde die Ursache, behebe sie und erkläre dir, was passiert ist. Wenn die Website gerade steht, hilft der Notfall-Support, dauerhaft begleitet die WordPress-Wartung.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. WordPress und seine Page-Builder sind mein Fachgebiet — ich baue damit seit Jahren, unterrichte das Thema als Dozent und kenne Elementor nicht nur aus der Oberfläche, sondern von innen: wie es Daten speichert, CSS erzeugt, Skripte lädt und mit Theme, Cache und Erweiterungen zusammenspielt.

Das ist bei Elementor der entscheidende Unterschied. Die meisten Probleme sehen aus wie Gestaltungsfragen und sind in Wahrheit technische: ein erzeugtes Stylesheet, das nicht neu geschrieben wurde, ein Speicherlimit, ein Konflikt zweier Erweiterungen. Wer das Innere kennt, findet die Ursache in Minuten statt in Stunden.

Was du bekommst: eine Diagnose in verständlicher Sprache, eine Behebung, die hält, und eine ehrliche Einschätzung, ob Elementor für deine Website weiterhin die richtige Wahl ist — auch wenn die Antwort lautet, dass alles so bleiben kann.