7 WordPress-Bremsen, die fast jeder Site übersieht

Wir machen seit 18 Monaten WordPress-Performance-Audits. Aus den Reports zeichnen sich sieben Bremsen ab, die fast jeder Site bremsen — und die mit ein paar Stunden Arbeit gefixt werden können. Reihenfolge nach typischem Lighthouse-Impact.

1. Page-Builder im Frontend (Elementor, Divi, WPBakery)

Render-Impact: 1,5–3,0 Sekunden LCP-Verschlechterung Häufigkeit in Audits: 60 %

Page-Builder sind Editor-Tools — aber sie liefern oft hunderte Kilobyte CSS und JavaScript ins Frontend mit, auch wenn der Besucher sie nicht braucht. Elementor lädt typischerweise 200–400 KB nur für Layout-Logik. Divi und WPBakery ähnlich.

Fix-Optionen: Conditional-Loading-Plugin (Asset CleanUp), Builder-CSS auf relevante Pages limitieren, oder im Audit-Fall: Migration auf einen Block-Editor-Stack.

2. Slider-Plugins, die jede Page laden

Render-Impact: 0,5–1,5 Sekunden LCP Häufigkeit: 45 %

Revolution Slider, Smart Slider, MetaSlider, LayerSlider — alle laden ihre Library standardmäßig auf jeder Page, auch wenn nur die Startseite einen Slider zeigt. Plus: Die typischen Slider-Bilder sind oft unkomprimierte JPEGs in 4K-Auflösung für Mobile-Devices.

Fix: Slider auf Startseite begrenzen (wp_dequeue_script per Conditional), Bilder als WebP exportieren, Lazy-Loading prüfen.

3. Yoast/RankMath mit voller Plugin-Tail

Render-Impact: 0,3–0,8 Sekunden TBT (Total Blocking Time) Häufigkeit: 95 %

SEO-Plugins erzeugen mehr JavaScript als nötig — Sitemaps, Breadcrumb-Komponenten, OpenGraph-Generator, Social-Preview-Modul. Im Frontend gehört davon fast nichts hin. Plus: Schema-Markup, das fehleranfällig generiert wird.

Fix: Plugin-Inhalte auf Admin-Bereich beschränken, Schema manuell pflegen oder lightweight Alternativ wie Slim SEO testen.

4. Web-Fonts ohne Preload

Render-Impact: 0,5–1,5 Sekunden LCP Häufigkeit: 75 %

Google-Fonts oder Adobe-Fonts werden oft erst bei der ersten Render-Stage angefragt — was zu Layout-Shifts und verzögertem Text führt. WordPress-Themes injizieren oft 3–6 Font-Varianten, von denen nur 2 wirklich genutzt werden.

Fix: Fonts selbst hosten (DSGVO-Plus), <link rel="preload"> für die wichtigsten 1–2 Varianten, Font-Display: swap setzen.

5. Datenbankabfragen aus dem Theme-Header

Render-Impact: 0,2–0,8 Sekunden TTFB Häufigkeit: 40 %

Custom-Themes haben oft Sidebar-, Menu- oder Footer-Logiken, die pro Request 5–15 zusätzliche MySQL-Queries auslösen. Bei langsamen Hostings summiert sich das zu spürbarem Server-Wartezeit-Aufschlag.

Fix: Object-Caching aktivieren (Redis/Memcached), Query-Anzahl mit Query Monitor prüfen, redundante Calls cachen.

6. Hosting auf Shared-Plattformen ohne PHP-Workers-Limit

Render-Impact: 0,5–2,0 Sekunden TTFB unter Last Häufigkeit: 35 %

Shared-Hosting bei All-Inkl, Strato, 1&1 funktioniert für Visitenkarten-Sites. Sobald die Site 1.000+ Besucher pro Tag hat oder einen Shop laufen lässt, schlagen die Worker-Limits durch — TTFB schwankt zwischen 200ms und 2 Sekunden.

Fix: Auf Hosting mit dediziertem PHP-Worker-Pool wechseln (Raidboxes, Hostpresto, Cloudways) oder Caching-Plugin mit serverseitigem Cache (LiteSpeed Cache, WP Rocket Pro). Im Worst Case: Headless-Migration mit statischer Site-Generation.

7. Comments / Trackbacks / XML-RPC aktiviert ohne Bedarf

Render-Impact: 0,1–0,3 Sekunden TBT, plus Sicherheitsrisiko Häufigkeit: 70 %

Standardmäßig sind Kommentare, Trackbacks und XML-RPC aktiv — auch wenn die Site sie nicht nutzt. Das lädt zusätzlichen JavaScript- und Render-Code, plus es ist ein häufiger Brute-Force-Angriffsvektor.

Fix: In WP-Admin → Discussion alle Trackback/Pingback-Optionen deaktivieren, Comments per Theme-Code entfernen, XML-RPC per .htaccess blockieren.

So finden Sie Ihre konkreten Bremsen

Drei Tools, die zusammen ein verlässliches Bild liefern:

1. PageSpeed Insights (pagespeed.web.dev) — Lighthouse-Score, Core Web Vitals, Diagnose-Liste
2. GTmetrix Waterfall — Sehe genau, welche Datei wie lange braucht
3. Query Monitor (WordPress-Plugin) — DB-Queries, Hooks, Plugin-Last pro Request

Faustregel: Wenn Lighthouse-Performance unter 70 liegt und Sie mehr als 2 der oben genannten Bremsen treffen, lohnt sich ein strukturierter Audit.

Wann lohnt sich ein externer Audit?

Wenn die Site geschäftskritisch ist und Sie nicht selbst die Zeit für PHP-Profiling, Plugin-Diagnose und Caching-Tuning haben. Unser WordPress Performance-Audit ist 490 € einmalig: Lighthouse + Plugin-Bremsen-Liste + Schema-Audit + Hosting-Check + Migrations-Pfad-Bewertung. Output: PDF-Report + 30-Min-Auswertung.

Mehr dazu: Astro vs. WordPress: Was wirklich schneller ist.