Page-Builder oder sauberer Code: Wann Elementor & Co. deinem Kundenprojekt schaden

Elementor, Divi, WPBakery: Page-Builder gehören in vielen Agenturen zum Standardwerkzeug. Man zieht Elemente auf die Seite, sieht sofort das Ergebnis, und der Kunde kann später selbst Texte tauschen. Das klingt nach dem perfekten Werkzeug, bis die Seite live ist und PageSpeed Insights mobil einen roten Wert zeigt.

In diesem Artikel geht es um die Frage Page-Builder vs. Custom Theme: was ein Page-Builder im Hintergrund erzeugt, warum Seiten mit Elementor langsam werden können, wann ein Page-Builder trotzdem die richtige Wahl ist und wie eine Website mit WordPress ohne Page-Builder aufgebaut ist.

Warum sind Page-Builder bei Agenturen so beliebt?

Die Beliebtheit hat gute Gründe:

• Schnelle Ergebnisse. Ein Layout steht in Stunden statt Tagen, auch ohne Entwickler im Team.
• Designer können selbst bauen. Wer gestaltet, setzt das Design direkt um, ohne Übergabe an die Programmierung.
• Der Kunde kann alles ändern. Texte, Bilder, sogar ganze Abschnitte lassen sich ohne Agentur anpassen.
• Riesige Auswahl an Vorlagen und Add-ons. Für fast jede Funktion gibt es ein fertiges Widget.

Für ein Angebot, das schnell und günstig sein muss, ist das verlockend. Der Preis dafür wird allerdings erst später sichtbar, im Quellcode und in der Ladezeit.

Was passiert im HTML, das du nicht siehst?

Ein Page-Builder muss für jede denkbare Gestaltung vorbereitet sein. Deshalb packt er jedes Element in mehrere Ebenen von Containern, die Abstände, Spalten, Hintergründe und Animationen steuern. Vereinfacht sieht eine einzelne Überschrift so aus:

<div class="section">
  <div class="container">
    <div class="column">
      <div class="widget-wrap">
        <div class="widget widget-heading">
          <div class="widget-container">
            <h2 class="heading-title">Unsere Leistungen</h2>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

In einem individuell programmierten Theme reicht dafür:

<section class="services">
  <h2>Unsere Leistungen</h2>
</section>

DOM-Größe

Jedes dieser Elemente landet im DOM, also in der Struktur, die der Browser aufbauen, gestalten und bei jeder Interaktion neu berechnen muss. Auf einer typischen Startseite mit Hero, Leistungen, Referenzen und Kontaktformular summiert sich das schnell auf mehrere Tausend Elemente. Lighthouse weist schon ab rund 800 Elementen auf eine zu große DOM-Größe hin.

Ungenutztes CSS und JavaScript

Page-Builder laden Stylesheets und Skripte für Widgets, Animationen und Icon-Sets, die auf der konkreten Seite oft gar nicht vorkommen. Dazu kommen Add-on-Pakete, die jeweils eigene Dateien mitbringen. Neuere Versionen der großen Builder haben hier nachgebessert und laden manche Dateien nur noch bei Bedarf. Das grundsätzliche Problem bleibt: Ein Werkzeug, das alles können muss, bringt mehr Code mit, als eine einzelne Seite braucht.

Abhängigkeiten

Die Inhalte sind im Format des Builders gespeichert. Wer den Builder später wechseln oder deaktivieren will, findet statt sauberer Seiten Shortcodes oder leere Layouts. Jedes Update des Builders oder eines Add-ons kann außerdem Darstellungsfehler verursachen, die auf allen Seiten gleichzeitig auftreten.

Wie wirkt sich das auf Ladezeit und Google-Ranking aus?

Google misst die Nutzererfahrung mit den Core Web Vitals. Als „gut“ gelten Werte, die 75 % der echten Besuche erreichen:

Messwert	Was er misst	Gut
LCP (Largest Contentful Paint)	Wann das größte sichtbare Element geladen ist	bis 2,5 s
INP (Interaction to Next Paint)	Wie schnell die Seite auf Klicks und Eingaben reagiert	bis 200 ms
CLS (Cumulative Layout Shift)	Wie stark sich das Layout beim Laden verschiebt	bis 0,1

Ein großer DOM und viel ungenutztes CSS und JavaScript wirken sich auf alle drei Werte aus. Render-blockierende Stylesheets verzögern den LCP. Jede Interaktion zwingt den Browser, Styles und Layout für Tausende Elemente neu zu berechnen, was den INP verschlechtert. Spät geladene Schriften und Animationen sorgen für Layout-Verschiebungen. Auf einem schnellen Büro-Rechner fällt das kaum auf, auf einem durchschnittlichen Smartphone im Mobilfunknetz sehr wohl.

Für das Ranking gilt: Core Web Vitals sind ein Signal unter vielen, und relevanter Inhalt bleibt wichtiger. Bei vergleichbaren Inhalten kann die schnellere Seite aber im Vorteil sein. Mindestens genauso wichtig ist der direkte Effekt auf deinen Kunden: Besucher, die auf eine langsame Seite warten, springen ab, bevor sie anfragen oder kaufen.

Prüfen kannst du das mit PageSpeed Insights. Achte auf den Unterschied zwischen Felddaten (echte Nutzer der letzten 28 Tage) und Labordaten (eine einzelne simulierte Messung). Für das Ranking zählen die Felddaten. Den Überblick über die ganze Website liefert der Bericht „Core Web Vitals“ in der Google Search Console.

Wann ist ein Page-Builder trotzdem okay?

Ein Page-Builder ist kein Fehler an sich. Er passt gut, wenn:

• eine Landingpage nur für eine kurze Kampagne gebraucht wird und danach wieder verschwindet,
• das Budget wirklich keinen Raum für individuelle Entwicklung lässt,
• der Kunde regelmäßig ganze Layouts selbst umbauen will und keinen Entwickler beauftragen möchte,
• ein schneller Prototyp gebraucht wird, um eine Idee mit dem Kunden abzustimmen,
• eine bestehende Builder-Website gut funktioniert und ein Neuaufbau sich nicht rechnet. Dann lohnt sich gezielte Performance-Optimierung mehr als ein Relaunch.

Problematisch wird es, wenn eine Unternehmenswebsite oder ein Shop, der jahrelang laufen und wachsen soll, auf einem Builder mit einem Dutzend Add-ons aufgebaut wird.

Wie sieht ein sauber programmiertes WordPress-Theme aus?

WordPress ohne Page-Builder heißt nicht, dass der Kunde nichts mehr selbst pflegen kann. Es heißt, dass die Flexibilität dort liegt, wo sie gebraucht wird, und nicht im Code jeder einzelnen Seite.

Vordefinierte Abschnitte statt freiem Baukasten

Mit Advanced Custom Fields (ACF) und Flexible Content oder eigenen Gutenberg-Blöcken bekommt die Redaktion fertige Abschnitte: Hero, Text mit Bild, Leistungsübersicht, FAQ, Kontaktbereich. Der Kunde wählt Abschnitte aus, füllt Felder aus und ändert die Reihenfolge. Das Design kann dabei nicht versehentlich zerbrechen, weil Abstände, Schriften und Farben im Theme festgelegt sind.

Nur der Code, den die Seite braucht

• Schlankes, semantisches HTML ohne unnötige Container
• CSS und JavaScript nur für die Bereiche, die auf der jeweiligen Seite tatsächlich vorkommen
• Bilder in passenden Größen mit srcset und Lazy Loading
• Lokal eingebundene Schriften, ohne Abfragen bei Drittanbietern
• Möglichst wenige Plugins, jedes mit einem klaren Zweck

Wartbar über Jahre

Der Code liegt in einem Git-Repository, Änderungen werden auf einer Staging-Umgebung getestet, bevor sie live gehen. Neue Funktionen kommen als neuer Abschnitt oder neues Template dazu, ohne bestehende Seiten zu beeinflussen.

Praxisbeispiel: vorher und nachher

[PLATZHALTER – vor Veröffentlichung ersetzen: anonymisiertes Projekt aus der eigenen Praxis. Ausgangslage (welcher Page-Builder, wie viele Plugins), was umgebaut wurde, und echte PageSpeed-Werte mobil vorher/nachher. Nur echte Messwerte verwenden.]

Messwert (mobil)	Vorher (Page-Builder)	Nachher (eigenes Theme)
Performance-Score	…	…
LCP	…	…
INP	…	…
CLS	…	…
DOM-Elemente	…	…
Übertragene Datenmenge	…	…

Fazit

Ein Page-Builder spart am Anfang Zeit und kostet sie später in Ladezeit, Wartung und Abhängigkeiten. Für kurzlebige Seiten und kleine Budgets ist das ein fairer Tausch. Für Websites und Shops, die deinem Kunden über Jahre Anfragen und Umsatz bringen sollen, ist ein individuell programmiertes Theme fast immer die bessere Grundlage.

Du willst deinen Kunden saubere WordPress-Websites liefern, hast aber keine eigene Entwicklung? Wie das unter deinem Namen funktioniert, liest du im Beitrag zur White-Label-Programmierung. Welche Projekte wir umsetzen, findest du unter Website-Programmierung.