Warum Page Builder wie Elementor und Divi Ladezeit kosten — und was das für die Sichtbarkeit bedeutet

Die Aussage «Page Builder sind langsam» ist bequem und in dieser Form falsch. Richtig ist etwas Präziseres: Page Builder wie Elementor, Divi oder WPBakery lösen das Layout-Problem, indem sie Struktur als Verschachtelung abbilden. Jede Sektion, jede Spalte, jedes Widget bekommt eigene Container, damit sich im Editor alles einzeln anfassen lässt. Diese Container verschwinden nicht beim Speichern. Sie landen im HTML, das jeder Besucher und jeder Crawler herunterlädt.

Das ist ein Zielkonflikt, kein Konstruktionsfehler: Komfort im Editor wird mit Gewicht in der Auslieferung bezahlt. Dieser Artikel rechnet vor, wie viel Gewicht das typischerweise ist, ordnet die belegbaren Marktzahlen ein, trennt sie sauber von den Zahlen, die es nicht gibt, und zeigt, was ohne Relaunch tatsächlich hilft.

Was ein Page Builder technisch tut

Ein Page Builder übersetzt eine visuelle Anordnung in eine Baumstruktur aus Containern, und diese Struktur wird eins zu eins ausgeliefert. Wer im Editor eine Sektion anlegt, darin drei Spalten platziert und in jede Spalte ein Icon, eine Überschrift und einen Textblock setzt, erzeugt keine drei sichtbaren Elemente, sondern eine Hierarchie: äussere Sektion, innerer Container für die Breitenbegrenzung, Zeilenelement, pro Spalte ein Spaltenelement mit eigenem Innencontainer, pro Widget ein Wrapper und darin nochmals ein Element für das Widget selbst.

Diese Ebenen existieren aus einem nachvollziehbaren Grund. Jede von ihnen kann im Editor eigene Abstände, Hintergründe, Animationen und Sichtbarkeitsregeln pro Bildschirmgrösse bekommen. Damit das funktioniert, braucht jedes Element eine eigene ID oder Klasse — und zu jeder ID gehört eine generierte CSS-Regel, die zusätzlich ausgeliefert werden muss.

Dazu kommen zwei weitere Posten. Erstens laden die meisten Builder eine Basis-Bibliothek an CSS und JavaScript für alle Widgets, unabhängig davon, welche auf der konkreten Seite vorkommen. Zweitens wächst der Bestand über Add-ons: Wer für einen speziellen Slider, ein Preistabellen-Widget oder ein Formular ein Zusatzpaket installiert, holt sich dessen komplettes Asset-Bündel auf jede Seite, auf der der Builder aktiv ist. Nach zwei Jahren Betrieb ist das selten noch jemandem vollständig bekannt.

Die Rechnung: wohin die DOM-Knoten gehen

Der Unterschied zwischen einem Builder-Layout und semantisch ausgeliefertem Markup liegt bei derselben Seite typischerweise beim Anderthalb- bis Zweifachen an DOM-Knoten. Das lässt sich ohne Messung nachrechnen, weil die Verschachtelungstiefe pro Bauteil bekannt ist. Nehmen wir eine ganz normale Leistungsseite: acht Sektionen, in jeder drei Spalten, in jeder Spalte vier Elemente. Das sind 96 sichtbare Bausteine.

Das Beispiel ist bewusst konservativ gerechnet: keine Add-ons, keine zusätzlichen Animationswrapper, keine verschachtelten Sektionen in Sektionen. In der Praxis kommen Header, Footer, Cookie-Banner und Mega-Menu obendrauf, und dann sind die von der Chrome-Dokumentation genannten Schwellen schnell erreicht. Lighthouse warnt laut der Dokumentation zur DOM-Grösse ab rund 800 Knoten im body und meldet ab rund 1'400 Knoten einen Fehler.

Wichtig an dieser Rechnung ist nicht die exakte Zahl, sondern das Verhältnis. Im Builder-Fall sind 144 der 448 Knoten reines Gerüst, das ist knapp ein Drittel. Im semantischen Fall sind es 16 von 304, also gut fünf Prozent. Jeder dieser Knoten kostet Bytes im HTML, Arbeit beim Parsen, Speicher im Browser und Rechenzeit bei jeder Layout-Berechnung — und die läuft nicht einmal, sondern bei jeder Interaktion, jedem Scroll-Effekt und jeder Grössenänderung neu.

Was sich belegen lässt — und was nicht

Belegbar ist der Marktbefund, nicht der direkte Kausalzusammenhang zwischen einem einzelnen Builder und einer Ladezeit. Der Web Almanac 2025 der HTTP Archive hält fest, dass WordPress rund 64 Prozent aller CMS-getriebenen Seiten ausmacht und dass 45 Prozent der WordPress-Seiten mobil gute Core-Web-Vitals-Werte erreichen. Zum Vergleich nennt dieselbe Auswertung Duda mit 85 Prozent, TYPO3 mit 79 Prozent und Wix mit 74 Prozent, wobei Wix im Jahresvergleich von 55 auf 74 Prozent gesprungen ist. Bei den Page Buildern innerhalb von WordPress führt Elementor mit 43 Prozent Verbreitung mobil, gefolgt vom Block-Editor mit rund 18 Prozent, WPBakery mit 13 Prozent und Divi mit 10 Prozent.

Was diese Quelle ausdrücklich nicht enthält, ist eine Aufschlüsselung der Core Web Vitals nach einzelnem Page Builder. Es gibt dort keine Zahl der Form «Elementor-Seiten bestehen zu X Prozent». Wer eine solche Zahl in einem Blogbeitrag liest, sollte nach der Quelle fragen; meist stammt sie aus einem selbst gebauten Test mit einer Handvoll Seiten und ist nicht auf den Markt übertragbar.

Genauso wenig belegt der CMS-Vergleich, dass WordPress die Ursache ist. Die 45 Prozent messen eine Population, keine Technologie: Der WordPress-Bestand ist im Schnitt älter, wird häufiger von Nicht-Spezialisten betrieben und trägt mehr historisch gewachsene Plugins mit sich herum als der Bestand einer Baukastenplattform, die vor drei Jahren gestartet ist und alle Kunden zentral aktualisiert. Ein sauber gebautes WordPress-Setup landet problemlos im grünen Bereich. Der Punkt bleibt derselbe wie eingangs: Nicht das System entscheidet, sondern das, was am Ende ausgeliefert wird.

Warum das die Reaktionsfähigkeit trifft, nicht nur den Ladebalken

Der spürbarste Schaden entsteht nicht beim ersten Laden, sondern bei jeder Interaktion danach — und genau das misst Interaction to Next Paint. Die Ladezeit lässt sich mit Caching, einem CDN und optimierten Bildern weitgehend in den Griff bekommen. Die Reaktionsfähigkeit nicht: Sie hängt daran, wie viel Arbeit der Browser leisten muss, wenn jemand tippt, klickt oder ein Menü öffnet.

Diese Arbeit skaliert mit zwei Grössen. Erstens mit der Anzahl DOM-Knoten, weil jede Layout-Neuberechnung den Baum durchläuft. Zweitens mit der Menge an JavaScript, die den Hauptthread belegt. Ein Page Builder liefert beides mit: einen tiefen Baum und ein Bündel an Widget-Skripten, dazu die Skripte der Add-ons, des Consent-Managers, des Analytics-Tools und des Chat-Widgets. Wir haben die Mechanik dahinter im Beitrag zu Core Web Vitals und INP im Detail beschrieben.

Die dritte Metrik, Cumulative Layout Shift, leidet aus einem anderen Grund. Builder setzen Höhen häufig relativ statt fest, damit sich im Editor alles frei anpassen lässt. Genau das nimmt dem Browser die Möglichkeit, den Platz vorab zu reservieren — der Inhalt springt beim Laden.

Was Page Builder gut können

Page Builder lösen ein reales Problem, und das sollte man nicht kleinreden: Sie geben Menschen ohne Entwicklungskenntnisse die Kontrolle über Layout und Inhalt zurück. In einem Betrieb, in dem die Marketingverantwortliche eine Landingpage am Dienstagnachmittag selbst aufsetzen muss, ist das kein Komfort, sondern eine Voraussetzung. Die Alternative wäre eine Agenturanfrage für jede Textänderung, und die kostet mehr als jede Millisekunde Ladezeit.

Dazu kommt: Die Anbieter arbeiten an genau diesem Punkt. Neuere Container-Modelle mit Flexbox und Grid ersetzen die alten Zeilen-und-Spalten-Konstrukte und sparen dabei echte Verschachtelungsebenen. Wer den Builder auf dem aktuellen Stand betreibt und die veralteten Bauteile in bestehenden Seiten ersetzt, verkleinert den Baum ohne inhaltliche Änderung.

Der ehrliche Vergleich lautet deshalb nicht «Page Builder gegen Code», sondern: Für welche Art von Seite lohnt sich welche Bauweise? Eine Kampagnenseite, die vier Wochen läuft und intern gepflegt wird, ist beim Builder gut aufgehoben. Eine Leistungsseite, die über Jahre für ein umkämpftes Suchwort ranken soll, verdient eine Bauweise, in der jedes Byte begründet ist. Wie sich das preislich unterscheidet, haben wir auf der Seite zu den Webdesign-Preisen offengelegt.

Was ohne Relaunch messbar hilft

Vier Schritte bringen bei einer bestehenden Builder-Seite den grössten Teil des Effekts, und keiner davon erfordert einen Neubau.

Erstens: Add-ons zählen und streichen. Jedes Widget-Paket lädt Assets auf jeder Seite. Wer prüft, welches Paket tatsächlich noch genutzt wird, entfernt oft mehrere hundert Kilobyte CSS und JavaScript in einem Nachmittag. Das ist der Schritt mit dem besten Verhältnis von Aufwand zu Wirkung.

Zweitens: Verschachtelung reduzieren. Sektion-in-Sektion-in-Sektion entsteht beim Bauen fast von selbst. Beim Durchgehen der wichtigsten zehn Seiten lassen sich diese Ebenen meist zusammenlegen, ohne dass sich optisch etwas ändert.

Drittens: Bilder und Schriften. Der Web Almanac 2025 weist für die mediane Startseite 911 KB Bilddaten mobil aus, gegenüber 22 KB für das HTML-Dokument. Der Ladebalken wird also überwiegend von Bildern bestimmt, nicht vom Builder. Moderne Formate und korrekte Abmessungen sind der Hebel, der zuerst gezogen gehört.

Viertens: Drittanbieter-Skripte verzögern. Chat-Widget, Heatmap und Tag-Manager gehören selten in die erste Sekunde. Nachladen bei Bedarf verschiebt INP zuverlässiger als jede Builder-Einstellung.

Wer wissen will, welcher dieser Punkte im eigenen Fall wie viel bringt, findet die Antwort in einem strukturierten Website-Audit — inklusive der Frage, ob sich ein Neubau überhaupt rechnet.

Wo die Grenze des Arguments liegt

Ladezeit gewinnt keine Rankings, sie beseitigt nur einen Grund zu verlieren. Core Web Vitals sind ein Rankingfaktor, aber ein schwacher, und sie wirken vor allem dann, wenn zwei Seiten inhaltlich ähnlich gut passen. Eine Seite auf Position 30 hat kein Performance-Problem, sondern ein Relevanzproblem. Wer dort zuerst am Builder schraubt, verbessert die falsche Kennzahl.

Der zweite, oft unterschätzte Punkt betrifft die KI-Suche. Systeme, die Seiten nicht anschauen, sondern lesen, müssen den Inhalt aus dem Markup herauslösen. Je tiefer der Baum und je mehr Gerüst pro Satz, desto ungenauer gelingt das. Wir haben diesen Zusammenhang im Beitrag zu Text-Ratio und Payload ausgerechnet. Für eine Builder-Seite heisst das: Der Nachteil zeigt sich zuerst dort, wo kein Ranking-Bericht ihn sichtbar macht.

Die vernünftige Reihenfolge lautet deshalb: erst prüfen, ob die Seite überhaupt für die richtigen Suchanfragen kandidiert, dann die Struktur aufräumen, dann das Gewicht. Und wenn am Ende der Neubau die richtige Antwort ist, dann als Entscheidung mit Zahlen dahinter — nicht, weil ein Werkzeug einen schlechten Ruf hat. Wie wir dabei vorgehen, steht auf den Seiten zur Website-Erstellung und zur Zusammenarbeit mit uns als Web-Agentur.