Warum Page-Builder deine WordPress Performance zerstören — und was wirklich hilft
WordPress Performance und Page-Builder — das Problem hat einen Namen
Wenn eine WordPress-Seite langsam ist und ein Page-Builder im Einsatz ist, sind das selten zufällig zwei getrennte Fakten. Page-Builder wie Elementor, WPBakery oder Divi sind für viele Projekte der erste Griff — aber sie kommen mit einem strukturellen Performance-Problem, das man schwer nachträglich lösen kann.
Ich erkläre hier, warum das so ist, wie du das Ausmaß messbar machst, und was in der Praxis wirklich hilft.
Warum Page-Builder deine WordPress Performance ausbremsen
Page-Builder erzeugen Performance-Probleme auf mehreren Ebenen gleichzeitig:
- JS- und CSS-Bloat: Elementor Pro lädt Stylesheets und Scripts für alle verfügbaren Widgets — auch die, die auf der aktuellen Seite gar nicht vorkommen. Das sind schnell 300–500 KB unkomprimiertes CSS und mehrere JS-Bundles, bevor dein eigentlicher Inhalt überhaupt gerendert wurde.
- Render-blocking Assets: Viele Builder laden ihre Ressourcen synchron im
<head>. Der Browser kann mit dem Rendern nicht beginnen, bis diese Dateien vollständig geladen und geparst sind. Das trifft direkt den LCP-Wert (Largest Contentful Paint). - Aufgeblähtes DOM: Ein typisches Elementor-Layout verpackt jeden Inhalt in drei bis fünf Wrapper-Divs. Eine Seite mit 20 Abschnitten kann leicht 800–1.200 DOM-Nodes haben. Das kostet Parsing-Zeit und erhöht den TBT (Total Blocking Time).
- Zu viele HTTP-Requests: Google Fonts, Font Awesome Icons, externe Widget-Scripts — Page-Builder ziehen Ressourcen von vielen verschiedenen Domains. Jeder zusätzliche Request ist eine zusätzliche Latenz.
- Generisches Markup: Inline-Styles, fehlende Semantik, keine optimierten Bildformate by default — das ist der Ausgangszustand, nicht das Worst-Case-Szenario.
So misst du das Problem
Bevor du anfängst zu optimieren, brauchst du Zahlen. Diese Tools sind kostenlos und reichen für eine solide Diagnose:
- Lighthouse: Im Chrome DevTools unter "Performance" — liefert LCP, TBT, CLS und gibt dir konkrete Hinweise, welche Ressourcen blockieren.
- PageSpeed Insights: Misst zusätzlich die Core Web Vitals aus echten Chrome-Nutzerdaten (CrUX). Das ist aussagekräftiger als reine Lab-Daten.
- WebPageTest: Erlaubt dir, mit einem echten Browser und einer definierten Verbindungsgeschwindigkeit zu testen. Waterfall-Ansicht zeigt dir genau, welche Requests sich gegenseitig blockieren.
Schau vor allem auf LCP (sollte unter 2,5 Sekunden liegen), TBT (unter 200 ms) und CLS (unter 0,1). Wenn du mit einem Page-Builder bei LCP über 4 Sekunden liegst, ist das kein Einstellungsproblem — das ist ein strukturelles Problem.
Was konkret hilft — und was nicht
Ich werde direkt sein: Die meisten "Page-Builder Performance optimieren"-Guides empfehlen Dinge, die das Grundproblem nicht lösen. Ein Caching-Plugin kann den TTFB verbessern, aber es entfernt keine 400 KB ungenutztes CSS. Hier ist, was tatsächlich einen Unterschied macht:
Kurzfristige Maßnahmen (ohne Builder-Wechsel)
- Elementor Asset Loading: Ab Elementor 3.x gibt es eine "Improved Asset Loading"-Option, die nur widget-relevante CSS lädt. Sie hilft, löst aber nicht alles.
- Caching: WP Rocket oder LiteSpeed Cache komprimieren HTML, kombinieren Scripts und liefern gecachte Seiten. Kein Ersatz für schlanken Code, aber sinnvoll als Ergänzung.
- Bildoptimierung: WebP, korrekte Bildgrößen per
srcset, Lazy Loading für Bilder unterhalb des Folds — das sind schnell umsetzbare Gewinne. - Fonts: Google Fonts lokal hosten statt per externem Request laden.
font-display: swapsetzen, damit Text sofort sichtbar ist. - Kritisches CSS: Above-the-fold-Styles inline ausliefern und den Rest deferred laden. Das verbessert den LCP-Wert spürbar.
Langfristige Lösung: Builder reduzieren oder ersetzen
Die ehrlichste Antwort: Wenn WordPress Performance wirklich wichtig ist, kommt man um ein schlankes Custom Theme kaum herum. Ich habe das bei mehreren Projekten so gemacht — zuletzt für Augusta Beauty, wo ein vollständig eigenes Theme die Grundlage war. Das Ergebnis: deutlich bessere Core-Web-Vitals-Werte, kein ungenutztes CSS, keine externen Font-Requests, vollständige Kontrolle über jeden Asset.
Das ist mehr Aufwand im Aufbau. Aber es ist die einzige Lösung, die das strukturelle Problem behebt statt es zu verkleiden.
WordPress Performance ist eine Baustellenentscheidung
Die meisten Performance-Probleme bei WordPress-Seiten entstehen nicht im Betrieb — sie werden beim Aufbau eingebaut. Ein Page-Builder kann schnell eine Seite liefern, aber er bringt strukturellen Ballast mit, den du später nicht einfach wegkonfigurierst.
Wenn du bereits eine Page-Builder-Seite betreibst und merkst, dass die Core Web Vitals nicht gut sind, lohnt sich eine ehrliche Bestandsaufnahme: Was ist kurzfristig optimierbar, und ab wann ist ein Umbau die wirtschaftlichere Entscheidung?
Wenn du das für dein Projekt durchdenken willst, meld dich gerne — ich biete Web-Performance-Beratung an und schaue mir konkrete Seiten an.