Builder-Seiten sind langsam — aber nicht hoffnungslos.

Woher das Gewicht kommt.

Vier der sechs Zeilen sind mit Einstellungen und Disziplin lösbar. Das ist die gute Nachricht: Eine Builder-Seite muss nicht langsam sein — die meisten sind es, weil niemand hingesehen hat.

Verschachtelung.

Die strukturelle Ursache. Builder arbeiten mit Abschnitten, Spalten, inneren Abschnitten, Containern — und jede Ebene erzeugt eigene Elemente mit eigenen Klassen und eigenen Gestaltungsregeln.

Ein Bereich, der im fertigen Ergebnis aus einer Überschrift und zwei Absätzen besteht, kann im Quelltext aus acht ineinandergeschachtelten Elementen bestehen. Das kostet beim Übertragen, beim Berechnen des Layouts und bei jeder Änderung durch Animationen.

Prüfen lässt sich das in Sekunden: Rechtsklick auf einen Text, untersuchen, und zählen, wie viele Ebenen bis zum eigentlichen Inhalt liegen. Mehr als vier sind ein Hinweis.

Behebbar ist das nur durch flacheres Bauen — und das heißt bei einer bestehenden Seite: umbauen. Deshalb steht es in der Tabelle als einziges bei „nur durch Umbau“.

Skripte aller Bausteine.

Der größte behebbare Posten. Viele Builder laden die Dateien für alle verfügbaren Bausteine auf jeder Seite — auch dort, wo kein einziger davon vorkommt.

Das heißt praktisch: Eine schlichte Kontaktseite lädt die Skripte für Schieberegler, Zähler, Registerkarten, Akkordeons, Preistabellen und Formulare, obwohl dort nur Text und eine Adresse stehen.

Was hilft:

• Nicht genutzte Bausteine abschalten, wenn der Builder das erlaubt — viele können das inzwischen.
• Bedingtes Laden aktivieren, falls vorhanden: Dateien nur dort, wo der Baustein vorkommt.
• Erweiterungspakete prüfen. Zusatzpakete mit hundert Bausteinen sind der häufigste Grund für überflüssige Dateien.
• Zählen, wie viele CSS- und JS-Dateien eine typische Seite tatsächlich lädt (Blockierende Dateien).

Punkt drei lohnt eine ehrliche Prüfung: Wenn ein Erweiterungspaket installiert ist und davon drei Bausteine verwendet werden, zahlt die ganze Website für diese drei.

Schriften und Symbole.

Builder bringen eigene Schriftbibliotheken und Symbolsätze mit, und beide werden oft vollständig geladen.

Bei Schriften: Prüfen, welche Schnitte tatsächlich verwendet werden. Eine Familie mit neun Stärken in normal und kursiv sind achtzehn Dateien; gebraucht werden meist vier. Und wenn sie von einer fremden Quelle kommen, lohnt die lokale Auslieferung doppelt (Schriften optimieren).

Bei Symbolen: Ein kompletter Symbolsatz für drei Pfeile und ein Telefonsymbol sind schnell mehrere hundert Kilobyte. Einzelne SVG-Symbole sind winzig, scharf und per CSS einfärbbar.

Beides zusammen macht auf vielen Builder-Seiten einen erheblichen Teil der Datenmenge aus — und beides ist in überschaubarer Zeit behoben.

Was sich einstellen lässt.

1. Nicht genutzte Bausteine abschalten.
2. Bedingtes Laden aktivieren.
3. Symbolsatz auf das Nötige begrenzen oder ersetzen.
4. Schriftschnitte reduzieren, lokal ausliefern.
5. Animationen auf das Nötige beschränken.
6. Eigene Gestaltung in der Datei statt in jedem Element einzeln.
7. Bilder als echte Bildelemente statt als CSS-Hintergrund.

Punkt sieben ist ein Builder-typisches Problem: Große Kopfbilder werden gern als Hintergrund gesetzt. Dann entdeckt der Browser sie spät, es gibt keine automatische Größenauswahl fürs Handy, und das LCP leidet (LCP, Bilder).

Bausteine bewusst wählen.

Nicht jeder Baustein kostet gleich viel. Teuer sind in der Regel:

• Schieberegler und Karussells — Skript, mehrere Bilder, oft Layoutsprünge.
• Zähler und animierte Diagramme.
• Eingebettete Karten und Videos (Externe Dienste).
• Parallax- und Scrolleffekte.
• Beitragslisten mit vielen Elementen.

Beim ersten Punkt lohnt die Grundsatzfrage: Ein Schieberegler im Kopfbereich ist fast immer die Ursache für ein schlechtes LCP, und erfahrungsgemäß sehen die meisten Besucher nur das erste Bild. Ein einzelnes starkes Bild ist schneller und wirkt meist besser.

Globale Einstellungen statt Einzelwerte.

Ein Punkt, der Tempo und Pflegeaufwand gleichzeitig betrifft. Builder erlauben es, Farben, Abstände und Schriftgrößen an jedem Element einzeln zu setzen — und erzeugen dafür individuelle Gestaltungsregeln.

Wer stattdessen die globalen Einstellungen nutzt, bekommt weniger Regeln, eine einheitlichere Website und die Möglichkeit, Änderungen an einer Stelle zu machen.

Das ist bei einer bestehenden Seite Aufräumarbeit, zahlt aber doppelt ein: weniger Gewicht und deutlich weniger Aufwand bei der nächsten Gestaltungsänderung.

Den Anteil messen.

1. Netzwerkanalyse öffnen und nach Herkunft gruppieren.
2. Dateien des Builders zählen und ihre Größe summieren.
3. Anteil an der Gesamtmenge bestimmen.
4. Eine schlichte Seite mit einer aufwendigen vergleichen.
5. Verschachtelungstiefe an einer typischen Stelle prüfen.
6. Mit gedrosseltem Prozessor die Reaktionsfähigkeit testen.

Punkt vier ist aufschlussreich: Wenn eine Seite mit zwei Absätzen fast so viel lädt wie die Startseite, ist das überflüssige Gewicht — und genau das lässt sich mit bedingtem Laden beheben.

Wann Optimieren reicht.

In den meisten Fällen. Wenn die Seiten überschaubar aufgebaut sind, wenige Spezialbausteine vorkommen und die Verschachtelung im Rahmen bleibt, bringen die Maßnahmen oben deutlich spürbare Verbesserung.

Ein realistisches Bild: Die Dateianzahl halbieren, die Datenmenge deutlich senken und das LCP um eine Sekunde verbessern ist bei einer typischen Builder-Seite mit den genannten Schritten erreichbar — ohne Umbau.

Für die meisten Websites ist das genug, um in den grünen Bereich zu kommen (Core Web Vitals).

Wann ein Umbau ehrlicher ist.

Es gibt Fälle, in denen Optimieren Flickwerk bleibt:

• Extreme Verschachtelung über viele Ebenen auf allen Seiten.
• Mehrere Erweiterungspakete mit je hundert Bausteinen.
• Jede Seite individuell gebaut, ohne gemeinsame Vorlagen.
• Zwei Builder parallel im Einsatz — kommt vor.
• Jede Änderung bricht etwas anderes.
• Das Design soll ohnehin erneuert werden.

Wenn drei oder mehr davon zutreffen, ist die ehrliche Rechnung: Was kostet das Optimieren, was bringt es, und was kostet ein Neuaufbau mit sauberen Vorlagen? Oft gewinnt der Neuaufbau — nicht wegen des Tempos allein, sondern weil die Pflege danach deutlich günstiger ist (Relaunch, Builder wechseln).

Ich sage dir das vorher und nicht nach drei Optimierungsrunden.

Für neue Projekte.

Wenn ohnehin neu gebaut wird, lohnen ein paar Entscheidungen am Anfang:

1. Flach bauen. Jede Ebene weniger ist dauerhaft weniger Gewicht.
2. Wenige Bausteintypen festlegen und durchhalten.
3. Globale Einstellungen für Farben, Abstände, Schriften.
4. Vorlagen statt Einzelseiten, wo es geht.
5. Kein Erweiterungspaket, solange es nicht gebraucht wird.
6. Tempo von Anfang an messen, nicht erst am Ende.

Punkt zwei ist der wirksamste: Wer der Redaktion acht gut gebaute Bausteine gibt statt dreißig, bekommt eine schnellere und einheitlichere Website — und weniger Rückfragen.

Und der ehrliche Hinweis zum Schluss: Der Blockeditor im WordPress-Kern ist inzwischen für viele Websites eine brauchbare Alternative und erzeugt deutlich leichtere Ausgabe. Ob er reicht, hängt davon ab, was gebaut werden soll — aber die Frage lohnt sich, bevor ein Builder gesetzt wird.

Wenn du nicht weiterkommst.

Wenn deine Builder-Seite langsam ist und du wissen willst, ob Optimieren reicht. Ich messe deine Seite mit echten Nutzerdaten statt mit einem einzelnen Test, sortiere die Befunde nach Wirkung und behebe die, die zählen: Ladezeit optimieren. Dauerhaft begleitet die WordPress-Wartung — damit neue Inhalte die Werte nicht wieder kaputt machen.

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

Wer hilft.

Ich bin Manuel Killert, Webentwickler aus Quakenbrück. Ich mache Websites schneller — und zwar messbar, nicht gefühlt. Das heißt: erst messen, dann die zwei oder drei Stellen beheben, die tatsächlich den Unterschied machen, dann noch einmal messen.

Was ich nicht mache: eine Punktzahl schönrechnen. Es gibt Tricks, mit denen ein Testwerkzeug hundert Punkte zeigt, während die Seite für echte Besucher gleich langsam bleibt. Das ist Selbstbetrug, und ich sage dir, wenn jemand dir so etwas verkauft hat.

Ich arbeite mit dem, was du hast — Theme, Plugins, Hoster. Ein Neubau ist manchmal die ehrlichere Antwort, und dann sage ich das auch, statt monatelang an einer Seite zu optimieren, die grundsätzlich falsch gebaut ist.