WordPress langsam? Die 10 häufigsten Performance-Killer

TTFB 900 ms auf Shared Hosting, 53 % mobiler Bounce ab 3 Sekunden, jede 100 ms kostet 1 % Conversions. Die zehn häufigsten Ursachen für langsame WordPress-Seiten und wie du sie systematisch behebst.

Deine WordPress-Seite braucht 5 Sekunden zum Laden. Besucher springen ab, Google stuft dich herunter, und du verlierst Umsatz mit jeder Sekunde Wartezeit. Das Problem: Die meisten Site-Betreiber wissen nicht, wo sie anfangen sollen. Sie installieren ein Cache-Plugin, hoffen auf Besserung und wundern sich, warum sich nichts tut.

Dieser Artikel zeigt dir die zehn Ursachen, die wir bei WordPress-Wartungs-Projekten am häufigsten finden. Mit konkreten Zahlen, messbaren Auswirkungen und Fixes, die du sofort umsetzen kannst.

Warum WordPress-Performance 2026 geschäftskritisch ist

Google misst seit 2021 die Core Web Vitals als Ranking-Signal. 2026 gelten diese Schwellenwerte:

• LCP (Largest Contentful Paint): gut unter 2,5 s, schlecht ab 4,0 s
• INP (Interaction to Next Paint): gut unter 200 ms, schlecht ab 500 ms. INP hat FID ersetzt und 43 % aller Websites scheitern daran.
• CLS (Cumulative Layout Shift): gut unter 0,1, schlecht ab 0,25
• TTFB (Time to First Byte): empfohlen unter 200 ms

Die Zahlen zum Geschäftsimpact sprechen für sich. Steigt die Ladezeit von 1 auf 3 Sekunden, springt die Bounce-Rate um 32 %. Von 1 auf 10 Sekunden sind es +123 %. Eine Seite, die in 1 Sekunde lädt, konvertiert 3x so gut wie eine, die 5 Sekunden braucht. Und bei 2 Sekunden Verzögerung im Checkout brechen 87 % der Nutzer den Warenkorb ab.

Performance ist kein Nice-to-have. Es ist der Unterschied zwischen einem Business, das funktioniert, und einer teuren Visitenkarte im Netz.

1. Schlechtes Hosting

Hosting ist die Basis. Stimmt die Serverantwortzeit nicht, hilft auch das beste Caching nichts. Wir messen bei Shared-Hosting-Paketen regelmäßig TTFB-Werte zwischen 900 und 1.400 ms. Bei managed WordPress-Hostern liegen wir bei 120 bis 250 ms. Das ist ein Faktor 5 bis 10.

Shared Hosting bedeutet: Du teilst dir CPU, RAM und Bandbreite mit Hunderten anderer Websites auf demselben Server. Wenn einer deiner Nachbarn einen Traffic-Spike hat, leidet deine Performance mit. Unser Hosting-Vergleich zeigt die Unterschiede mit Benchmarks und 3-Jahres-Kostenrechnung.

Fix: Wechsel auf managed WordPress-Hosting oder einen VPS mit LiteSpeed oder Nginx. Das ist die Einzelmaßnahme mit dem größten Impact.

2. Nicht optimierte Bilder

Bilder machen bei über 50 % aller langsamen WordPress-Seiten den größten Anteil der Ladezeit aus. Ein einzelnes unkomprimiertes Foto aus der Kamera hat 3 bis 8 MB. Multipliziert mit 10 Bildern pro Seite ist die Performance ruiniert, bevor der erste Absatz geladen hat.

Was du brauchst:

• Modernes Format: WebP als Standard, AVIF als Fallback für Browser, die es unterstützen
• Responsive Größen: srcset und sizes-Attribute, damit Mobilgeräte nicht Desktop-Bilder laden
• Lazy Loading: Bilder unterhalb des sichtbaren Bereichs erst laden, wenn der Nutzer scrollt
• Korrekte Dimensionen: Breite und Höhe im HTML angeben, um CLS zu vermeiden

Fix: Installiere ein Bildoptimierungs-Plugin (ShortPixel, Imagify oder EWWW). Aktiviere WebP-Konvertierung und Lazy Loading. Prüfe, dass dein Theme srcset korrekt ausgibt.

3. Plugin-Überladung

Die durchschnittliche WordPress-Seite hat 12 bis 15 aktive Plugins. Das Problem ist nicht die Anzahl per se, sondern was jedes Plugin tut: CSS- und JS-Dateien laden. Auf jeder einzelnen Seite. Auch wenn das Plugin dort gar nicht gebraucht wird.

Ein Kontaktformular-Plugin, das sein CSS und JavaScript auf der Startseite lädt, obwohl das Formular nur auf der Kontaktseite existiert. Ein Slider-Plugin, das seine Bibliothek auf allen 200 Seiten einbindet. Ein SEO-Plugin, das im Frontend Schema-Markup-Scripts lädt, die nur im Head stehen müssten.

Jedes zusätzliche CSS- und JS-File bedeutet eine HTTP-Anfrage, Parser-Zeit und potenziell Render-Blocking. Bei 15 Plugins mit je 2 Dateien sind das 30 zusätzliche Requests, bevor dein eigentlicher Content geladen wird.

Fix: Prüfe mit Query Monitor, welches Plugin welche Assets auf welcher Seite lädt. Deaktiviere Assets seitenspezifisch mit Asset CleanUp oder Perfmatters. Lösche Plugins, die du nicht aktiv nutzt. Und mach dir bewusst: Jedes Plugin ist auch ein potenzieller Sicherheits- und Update-Risiko.

4. Fehlendes oder falsch konfiguriertes Caching

WordPress generiert jede Seite dynamisch. Bei jedem Aufruf: PHP-Ausführung, Datenbank-Abfragen, Template-Rendering. Ohne Caching passiert das bei jedem einzelnen Besucher. Mit Page-Caching wird das Ergebnis als statische HTML-Datei gespeichert und direkt ausgeliefert. Das reduziert die Ladezeit um 50 bis 70 %.

Du brauchst drei Caching-Ebenen:

1. Page Cache: Speichert die fertige HTML-Seite. Plugins: WP Super Cache, W3 Total Cache, LiteSpeed Cache (bei LiteSpeed-Servern die beste Wahl, siehe Webserver-Vergleich)
2. Object Cache: Speichert Datenbank-Abfragen im RAM (Redis oder Memcached). Spart bei Seiten mit vielen Queries 100 bis 300 ms pro Request.
3. Browser Cache: HTTP-Header, die dem Browser sagen, statische Dateien (Bilder, CSS, JS) lokal zu speichern. Reduziert Folgezugriffe auf fast null Ladezeit.

Fix: Installiere ein Caching-Plugin und konfiguriere alle drei Ebenen. Wenn dein Hoster Redis oder Memcached anbietet, aktiviere Object Caching. Setze Browser-Cache-Expiry auf mindestens 1 Jahr für statische Assets.

5. Aufgeblähte Themes

Multipurpose-Themes wie Avada, Divi oder BeTheme laden CSS für 80+ Elemente, auch wenn deine Seite nur 5 davon nutzt. Page Builder wie Elementor, WPBakery oder Divi fügen 200 bis 500 KB an zusätzlichem CSS und JavaScript hinzu. Pro Seite.

Das Ergebnis: riesige CSS-Dateien, die der Browser parsen muss, bevor er irgendetwas rendern kann. Dazu kommen JavaScript-Bibliotheken für Animationen, Lightboxes und Mega-Menüs, die die meisten Seiten nicht brauchen.

Fix: Wenn du bei einem Page Builder bleibst, deaktiviere alle ungenutzten Module und Widgets. Entferne globale CSS-Klassen, die nirgends verwendet werden. Langfristig ist ein leichtgewichtiges Theme (GeneratePress, Kadence, Blocksy) oder ein Custom-Theme die bessere Lösung.

6. Render-Blocking CSS und JavaScript

Rund 40 % aller schlechten User-Experience-Scores kommen von Render-Blocking Resources. Das passiert, wenn CSS- und JS-Dateien im <head> stehen und den Browser zwingen, mit dem Rendern zu warten, bis alles heruntergeladen und geparst ist.

Die meisten WordPress-Sites scheitern an diesem Lighthouse-Audit. Jedes Plugin, das sein Stylesheet im Head einbindet, verzögert den First Paint. Jedes Script ohne defer oder async blockiert das Rendering.

Was du tun kannst:

• Critical CSS inlinen: Die CSS-Regeln für den sichtbaren Bereich direkt im HTML ausgeben, den Rest asynchron nachladen
• JavaScript deferred laden: Alle Scripts mit defer oder async laden, außer die, die sofort gebraucht werden
• CSS und JS zusammenführen: Weniger Dateien = weniger HTTP-Requests = schnellerer Start

Fix: Nutze Autoptimize, Perfmatters oder LiteSpeed Cache für Critical-CSS-Generierung und Script-Deferring. Prüfe das Ergebnis in Lighthouse und achte auf den Waterfall in den Chrome DevTools.

7. Datenbank-Bloat

WordPress speichert alles in der Datenbank: Posts, Revisionen, Transients, Autoload-Daten, Plugin-Optionen, Spam-Kommentare. Bei einer gesunden Installation liegt die Autoload-Größe bei 200 bis 500 KB. Ab 1 MB wird es kritisch. Bei 5 MB und mehr kostet jeder einzelne Seitenaufruf 100 bis 200 ms zusätzlich, nur für das Laden der Autoload-Daten.

Typische Ursachen für Datenbank-Bloat:

• Post-Revisionen ohne Limit (WordPress speichert standardmäßig jede einzelne Änderung)
• Spam- und Papierkorb-Kommentare, die sich über Monate ansammeln
• Abgelaufene Transients, die nie bereinigt werden
• Deaktivierte Plugins, die ihre Tabellen und Optionen hinterlassen
• WooCommerce-Sessions und abgelaufene Transients

Fix: Begrenze Post-Revisionen in der wp-config.php mit define('WP_POST_REVISIONS', 5);. Nutze WP-Optimize oder Advanced Database Cleaner, um Transients, Revisionen und Spam regelmäßig zu bereinigen. Prüfe die Autoload-Größe per SQL: SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';

8. Zu viele externe Scripts

Die durchschnittliche Webseite lädt 20 Third-Party-Scripts mit einem Gesamtvolumen von rund 449 KB. 93,6 % aller Seiten binden mindestens ein externes Script ein. Tracking-Pixel, Chat-Widgets, Social-Media-Buttons, Fonts von Google, Werbe-Tags, Analytics, Consent-Banner.

Jedes externe Script ist ein DNS-Lookup, ein TCP-Handshake, eine TLS-Negotiation und ein Download. Das passiert parallel zum Laden deiner eigentlichen Seite und konkurriert um Bandbreite und CPU-Zeit. Dazu kommt: Du hast null Kontrolle über die Antwortzeit externer Server.

Fix: Hoste Google Fonts lokal (DSGVO-konform und schneller). Lade Tracking-Scripts per Server-Side Tracking statt Client-Side. Entferne Social-Buttons und ersetze sie durch einfache Links. Verzögere Chat-Widgets bis zur Nutzerinteraktion. Prüfe mit dem Chrome DevTools Network-Tab, welche Third-Party-Requests die längsten Wartezeiten haben.

9. Kein CDN

Ohne CDN liefert dein Server in Frankfurt jede Datei selbst aus, egal ob der Besucher aus München, São Paulo oder Singapur kommt. Ein CDN (Content Delivery Network) verteilt statische Dateien auf Dutzende Edge-Server weltweit. Der Besucher bekommt die Dateien vom nächstgelegenen Standort.

Die Zahlen: Ein CDN verbessert die WordPress-Ladezeit um 42 bis 72 %. Bei einer Seite mit internationalen Besuchern ist der Unterschied noch größer. Aber auch für rein deutschsprachige Seiten bringt ein CDN Vorteile: DDoS-Schutz, Lastverteilung und niedrigere TTFB.

Fix: Cloudflare in der kostenlosen Version ist für die meisten WordPress-Seiten ausreichend. Wer mehr braucht (Bild-Optimierung, tiefere WP-Integration), nimmt Bunny CDN oder KeyCDN. Die Einrichtung dauert 15 Minuten.

10. Veraltete PHP-Version

PHP 8.3 verarbeitet 13 % mehr Requests pro Sekunde als PHP 7.4. PHP 8.4 mit WooCommerce erreicht sogar 21 % mehr Durchsatz als PHP 7.4. Das ist kostenlose Performance, die du durch ein PHP-Upgrade im Hosting-Panel bekommst.

Trotzdem laufen viele WordPress-Seiten noch auf PHP 7.4 oder sogar 8.0. Gründe: Angst vor Kompatibilitätsproblemen, fehlendes Wissen, kein Staging zum Testen. Dabei ist der Upgrade-Pfad 2026 gut dokumentiert, und die meisten Plugins sind längst kompatibel.

Fix: Erstelle ein Backup, teste das PHP-Upgrade in einer Staging-Umgebung, und wechsle dann auf PHP 8.3 oder 8.4. Prüfe vorher die Kompatibilität deiner Plugins mit dem PHP Compatibility Checker.

Alle 10 Killer auf einen Blick

Problem	Auswirkung	Fix
Schlechtes Hosting	TTFB 900 – 1.400 ms	Managed WP oder VPS
Nicht optimierte Bilder	50 %+ der Ladezeit	WebP/AVIF, Lazy Loading, srcset
Plugin-Überladung	30+ extra HTTP-Requests	Asset CleanUp, ungenutzte löschen
Fehlendes Caching	50 – 70 % längere Ladezeit	Page + Object + Browser Cache
Aufgeblähtes Theme	200 – 500 KB extra CSS/JS	Leichtgewichtiges Theme
Render-Blocking Resources	~40 % schlechter UX-Score	Critical CSS, defer Scripts
Datenbank-Bloat	100 – 200 ms pro Request	Revisionen begrenzen, Transients bereinigen
Externe Scripts	~449 KB, 20 Third-Party-Requests	Lokal hosten, Server-Side Tracking
Kein CDN	42 – 72 % langsamere Auslieferung	Cloudflare oder Bunny CDN
Veraltetes PHP	13 – 21 % weniger Durchsatz	PHP 8.3/8.4 im Hosting-Panel

Wo du anfangen solltest

Die Reihenfolge ist wichtig. Es gibt keinen Sinn, an Render-Blocking Resources zu arbeiten, wenn dein Server 1.200 ms braucht, um überhaupt zu antworten.

1. Hosting prüfen: Miss deine TTFB mit PageSpeed Insights. Liegt sie über 400 ms, ist das dein erster Hebel.
2. Caching einrichten: Wenn noch kein Page Cache aktiv ist, bringt das den größten Einzeleffekt.
3. Bilder optimieren: ShortPixel oder Imagify installieren, WebP aktivieren, fertig.
4. Plugin-Audit: Query Monitor installieren, Assets pro Seite prüfen, Ballast entfernen.
5. Feintuning: Critical CSS, Script-Deferring, CDN, PHP-Upgrade.

Die meisten WordPress-Seiten lassen sich mit den ersten drei Schritten von 5+ Sekunden auf unter 2 Sekunden bringen. Für die letzten Millisekunden brauchst du Feintuning, aber 80 % des Ergebnisses kommen aus 20 % der Maßnahmen.

Wenn du unsicher bist, wo deine Seite steht, oder die Optimierung nicht selbst machen willst: Genau dafür gibt es unsere WordPress-Wartung. Wir machen den Performance-Audit, identifizieren die Killer und setzen die Fixes um. Und falls bei einem Update mal der White Screen of Death auftaucht, sind wir auch dafür da.