7 WordPress-Bremsen, die fast jeder Site übersieht

Ich prüfe WordPress-Seiten auf Performance. Aus diesen Prüfungen zeichnen sich sieben Bremsen ab, die viele Seiten ausbremsen 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 bis 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 bis 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 bis 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 bis 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 bis 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 bis 6 Font-Varianten, von denen nur 2 wirklich genutzt werden.

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

5. Datenbankabfragen aus dem Theme-Header

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

Custom-Themes haben oft Sidebar-, Menu- oder Footer-Logiken, die pro Request 5 bis 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 bis 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 bis 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:

PageSpeed Insights (pagespeed.web.dev): Lighthouse-Score, Core Web Vitals, Diagnose-Liste
GTmetrix Waterfall: Sehe genau, welche Datei wie lange braucht
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. Mein 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.

Weiterlesen: Weitere Ursachen für langsame Seiten stehen im Ratgeber WordPress langsam. Wenn Sie den Umstieg erwägen, lesen Sie Webseite ohne WordPress, was geht und die Seite zum Webdesign.