WordPress Performance: Ladezeiten verbessern in 5 Schritten

Ein Szenario, das mir in Kundengesprächen ständig begegnet: Die neue Website sieht gut aus, der Content stimmt, sogar ein Hosting-Vertrag wurde abgeschlossen – und trotzdem dreht sich beim Laden gefühlte Ewigkeiten das Rad. In meinen Workshops erlebe ich häufig, dass Betreiber gar nicht wissen, woran es liegt: am Theme, an zu vielen Plugins, am Bildmaterial vom Smartphone in voller Auflösung, oder doch am Hosting? Meistens ist es eine Mischung aus mehreren dieser Faktoren, keine einzelne Ursache.

Um die Kernfrage gleich vorwegzunehmen: WordPress-Ladezeiten lassen sich bei vielen Websites über fünf besonders häufige Hebel verbessern – ein aktives Caching-System, optimierte Bilder, ein schlankes Plugin-/Theme-Setup, eine regelmäßig aufgeräumte Datenbank und ein leistungsfähiges Hosting mit kurzer Serverantwortzeit (TTFB). Welche Maßnahme bei Ihnen den größten Effekt bringt, zeigt erst die Messung aus dem nächsten Abschnitt – wer diese fünf Punkte systematisch prüft, deckt damit viele der typischen Performance-Bremsen einer WordPress-Website ab, ohne die Seite technisch neu aufbauen zu müssen.

Warum sich der Aufwand lohnt, zeigen ältere, aber weiterhin aussagekräftige Google-Untersuchungen zum mobilen Nutzerverhalten: In einer Google/SOASTA-Analyse von 2017 stieg die modellierte Absprungwahrscheinlichkeit beim Anstieg von einer auf drei Sekunden um 32 Prozent und von einer auf zehn Sekunden um 123 Prozent. Google-Daten aus 2016 zeigten zudem, dass 53 Prozent der mobilen Besuche bei Ladezeiten über drei Sekunden abgebrochen wurden. Und laut dem aktuellen HTTP Archive Web Almanac 2025 bestehen nur rund 45 Prozent der WordPress-Websites auf Mobilgeräten alle drei Core Web Vitals – deutlich weniger als bei kontrollierten Baukasten-Plattformen wie Wix (74 Prozent) oder Duda (85 Prozent). Das ist kein Grund zur Panik, aber ein guter Grund, die eigene Seite einmal ehrlich zu prüfen.

Bevor Sie optimieren: Ladezeit richtig messen

Bevor Sie irgendein Plugin installieren, sollten Sie wissen, woran Ihre Seite tatsächlich krankt. Sonst optimieren Sie unter Umständen wochenlang an Bildern, während das eigentliche Problem im Server liegt.

Zwei Werkzeuge reichen für den Einstieg. PageSpeed Insights (pagespeed.web.dev) liefert einen Score sowie eine Aufschlüsselung nach den drei Core Web Vitals: LCP (Largest Contentful Paint, soll unter 2,5 Sekunden liegen), INP (Interaction to Next Paint, unter 200 Millisekunden) und CLS (Cumulative Layout Shift, unter 0,1). Der Core-Web-Vitals-Bericht in der Google Search Console zeigt zusätzlich die sogenannten Field-Daten – also reale Messwerte tatsächlicher Besucher über die letzten 28 Tage, nicht nur einen einmaligen Labor-Test.

Der Unterschied zwischen Lab- und Field-Daten ist wichtig: PageSpeed Insights kombiniert beides – einen aktuellen Lighthouse-Labortest unter definierten Bedingungen und, sofern genügend Daten aus dem Chrome UX Report vorliegen, reale Nutzerdaten der vergangenen 28 Tage (Field-Daten). Die Google Search Console bereitet dieselben Field-Daten zusätzlich für einzelne URL-Gruppen und die langfristige Überwachung auf. In meinen WordPress-Projekten zeigt sich dabei häufig ein klares Muster: INP ist seltener das Problem als LCP – und TTFB ist häufig ein wichtiger Bestandteil eines schlechten LCP. Im Web Almanac 2025 erreichten mobil nur 44 Prozent der untersuchten Websites eine gute TTFB; wie stark das bei Ihrer konkreten WordPress-Site ins Gewicht fällt, zeigt erst die eigene Messung. Das erklärt, warum Schritt 5 in diesem Artikel besonders viel Gewicht bekommt.

Schritt 1: Caching aktivieren

Ohne Page-Cache muss WordPress Seitenaufrufe in der Regel dynamisch über PHP und Datenbankzugriffe verarbeiten – selbst wenn sich seit dem letzten Aufruf nichts geändert hat. Ein Page-Cache hält die fertig erzeugte HTML-Ausgabe vor und kann sie bei weiteren Aufrufen ausliefern, ohne die vollständige WordPress-Verarbeitung erneut durchführen zu müssen. Ein Object-Cache (meist über Redis oder Memcached) geht einen Schritt weiter und hält wiederverwendbare WordPress-Daten zwischen Requests vor, wodurch sich wiederholte Datenbankzugriffe vermeiden lassen – das hilft besonders bei dynamischen Seiten mit vielen Widgets oder WooCommerce-Shops spürbar.

Bei den Plugin-Optionen unterscheide ich in meinen Workshops immer zwischen zwei Kategorien: server-integrierte Lösungen wie LiteSpeed Cache (die eigentlichen Page-Cache-Funktionen brauchen LiteSpeed/OpenLiteSpeed oder QUIC.cloud, viele Zusatzfunktionen laufen aber auch auf anderen Webservern) und klassische Optimierungs-Plugins wie WP Rocket, W3 Total Cache oder FlyingPress, die auf vielen gängigen Hosting-Umgebungen eingesetzt werden können (bei manchen Managed-WordPress-Hostern übernimmt der Anbieter das serverseitige Page-Caching bereits selbst, dann bleiben nur die übrigen Optimierungsfunktionen relevant).

ℹ️ Transparenz-Hinweis (Werbung): Der Link zu FlyingPress* ist mit einem Sternchen (*) markiert und ein Affiliate-Link. Schließen Sie darüber einen Vertrag ab, erhalte ich eine Provision – für Sie bleibt der Preis exakt gleich. Ich setze FlyingPress selbst auf dieser Website ein.

FlyingPress* setze ich mittlerweile bei mir selbst und in praktisch allen Kundenprojekten ein – die Konfiguration ist deutlich schlanker als bei den meisten Konkurrenten, ohne bei den Kernfunktionen Abstriche zu machen. Eine seriöse allgemeine Prozentzahl für die Ladezeit-Reduktion gibt es nicht – der Effekt hängt stark von Ausgangszustand, Cache-Hit-Rate, Seitentyp und Server ab. In eigenen Projekten sehe ich aber regelmäßig deutliche Sprünge, sobald vorher gar kein Caching aktiv war; messen Sie vor und nach der Aktivierung, um den tatsächlichen Effekt bei Ihrer Website zu kennen. Wichtig: Ein aktiviertes Caching-Plugin allein reicht nicht, wenn es falsch konfiguriert ist. Prüfen Sie nach der Einrichtung, ob der Cache bei Änderungen an Beiträgen automatisch geleert wird – sonst sehen Besucher veraltete Inhalte.

Schritt 2: Bilder optimieren

Bilder machen bei vielen Websites einen erheblichen Teil des Seitengewichts aus – im Web Almanac 2025 lag allein das Bildgewicht der medianen mobilen Startseite bei rund 911 KB. Hier steckt oft das größte ungenutzte Sparpotenzial. Der Klassiker aus der Praxis: Ein Kunde lädt Fotos direkt von der Smartphone-Kamera hoch, mit 4.000 Pixeln Breite, obwohl die Website sie nie größer als 800 Pixel anzeigt. WordPress erzeugt zwar automatisch kleinere Bildvarianten und liefert diese regulär über responsive srcset-Angaben aus – aber die unnötig große Ausgangsdatei belastet trotzdem Speicherplatz und Bildverarbeitung, und je nach Theme oder Page-Builder wird im Einzelfall dennoch eine zu große Variante ausgeliefert.

Das moderne Bildformat WebP spart gegenüber klassischem JPEG bei vergleichbarer Qualität typischerweise 25 bis 35 Prozent Dateigröße. WordPress unterstützt WebP seit Version 5.8 und AVIF seit Version 6.5. Ebenfalls seit 5.8 lässt sich über den Filter image_editor_output_format das Ausgabeformat erzeugter Bildgrößen per Code anpassen, seit 6.5 auch auf AVIF – eine automatische JPEG-zu-WebP/AVIF-Konvertierung ist im Core aber nicht standardmäßig aktiviert, dafür braucht es eigenen Code oder ein Plugin wie das von der WordPress-Performance-Team betreute „Modern Image Formats“ (setzt in der aktuellen Version WordPress 6.9 oder höher voraus).

ℹ️ Transparenz-Hinweis (Werbung): Der Link zu ShortPixel* ist mit einem Sternchen (*) markiert und ein Affiliate-Link. Schließen Sie darüber einen Vertrag ab, erhalte ich eine Provision – für Sie bleibt der Preis exakt gleich. Ich setze ShortPixel selbst auf dieser Website ein.

Wer sich das ersparen möchte, greift zu Plugins wie ShortPixel* oder Imagify, die Uploads automatisch komprimieren und in WebP umwandeln. Ergänzend gehört Lazy Loading dazu – Bilder unterhalb des sichtbaren Bereichs laden verzögert, typischerweise sobald sie sich dem Viewport nähern, nicht erst beim tatsächlichen Hinscrollen; WordPress bringt das seit Version 5.5 bereits nativ mit.

Schritt 3: Plugins und Theme entschlacken

Aktive Plugins erweitern den WordPress-Code und können zusätzliche PHP-Verarbeitung, Datenbankabfragen oder CSS/JavaScript verursachen – entscheidend ist dabei weniger die reine Anzahl als das konkrete Verhalten der einzelnen Plugins. In meinen Website-Audits sehe ich trotzdem regelmäßig 40 oder mehr aktive Plugins, von denen ein gutes Drittel seit Jahren nicht mehr gebraucht, aber nie deinstalliert wurde. Ein ehrlicher Plugin-Audit lohnt sich: Deaktivieren Sie testweise alles, was nicht zwingend nötig ist, und prüfen Sie danach den PageSpeed-Wert. Häufige Bremsklötze sind Page-Builder mit eigenem CSS-/JS-Overhead, Social-Media-Widgets mit externen Skripten und veraltete SEO-Plugins mit doppelten Funktionen.

Auch das Theme spielt eine Rolle. Multipurpose-Themes mit unzähligen Layout-Optionen bringen oft deutlich mehr CSS und JavaScript mit, als eine konkrete Website tatsächlich nutzt. Ein schlankes Theme, das nur die tatsächlich benötigten Ressourcen ausliefert, ist hier meist die bessere Ausgangsbasis. Zusätzlich helfen Maßnahmen wie das Entfernen ungenutzter CSS-/JS-Anteile, Minifizierung sowie das verzögerte Laden nichtkritischer Ressourcen und das Vermeiden sogenannter renderblockierender Ressourcen – insbesondere Stylesheets und synchron geladene Skripte, die den ersten Seitenaufbau verzögern. Ob Dateien zusätzlich zusammengefasst werden sollten, hängt vom konkreten Setup ab; viele Caching-Plugins aus Schritt 1 bringen für diese Maßnahmen bereits eine Optimierungsfunktion mit.

Schritt 4: Datenbank aufräumen

Eine WordPress-Datenbank wächst mit der Zeit unbemerkt: Post-Revisionen (WordPress speichert standardmäßig Revisionen von gespeicherten Entwürfen und Aktualisierungen, dazu kommt maximal ein Autosave pro Benutzer und Beitrag), Spam-Kommentare, abgelaufene Transients (temporäre Zwischenspeicher von Plugins), und nicht mehr benötigte Daten ehemaliger oder dauerhaft ungenutzter Plugins können sich ansammeln. Eine gewachsene Datenbank ist nicht automatisch langsam – problematisch wird es vor allem, wenn große oder schlecht gepflegte Tabellen, zu viele sogenannte autoloaded Options oder ineffiziente Abfragen bei häufigen Seitenaufrufen verarbeitet werden müssen, was bei tausenden Beiträgen und Jahren im Betrieb durchaus vorkommt. Verglichen mit Caching, Bildoptimierung oder Hosting ist der reine Geschwindigkeitseffekt einer Datenbank-Bereinigung bei den meisten Unternehmenswebsites kleiner – trotzdem lohnt sich der Aufwand: Eine schlanke Datenbank hält die Seite sauber, und kleinere Backups sind schneller erstellt, übertragen und im Ernstfall auch schneller wiederhergestellt.

Tools wie WP-Optimize räumen Revisionen, Spam und Transients mit wenigen Klicks auf. Wer wie ich FlyingPress für das Caching einsetzt, braucht dafür oft gar kein Zusatz-Plugin: Der eigene Database-Tab von FlyingPress deckt viele dieser Bereinigungen bereits ab – Post-Revisionen, Auto-Drafts, gelöschte Beiträge und Kommentare, abgelaufene Transients sowie eine Tabellen-Optimierung gegen Fragmentierung – inklusive automatischem Zeitplan (täglich, wöchentlich oder monatlich). Wichtig dabei: Vor jeder Datenbank-Bereinigung ein aktuelles Backup anlegen, und bei Post-Revisionen nicht auf null reduzieren – ein paar Versionen zur Wiederherstellung sind sinnvoll, unbegrenzt viele nicht. Diese Aufräumarbeit ist kein einmaliges Projekt, sondern gehört in die laufende Website-Pflege.

🧹 Wartung statt Feuerwehr: Wie Sie Datenbank-Pflege, Updates und Sicherheits-Checks sinnvoll in einen wiederkehrenden Rhythmus bringen, zeigt mein Artikel zu professioneller WordPress-Wartung für Unternehmen im Detail.

Schritt 5: Hosting und TTFB – das oft unterschätzte Fundament

Die TTFB (Time to First Byte) misst, wie lange es dauert, bis der Browser das erste Byte der Serverantwort erhält – darin stecken unter anderem Verbindungsaufbau, TLS-Handshake und die eigentliche Verarbeitung der Anfrage. Eine hohe TTFB verschlechtert alle nachfolgenden Ladephasen. Ihre Ursache kann dabei sowohl im Hosting und Netzwerk liegen als auch direkt im WordPress-Backend – etwa bei langsamer PHP-Verarbeitung, Datenbankabfragen oder fehlendem Page-Caching. Mehrere der bisherigen Maßnahmen wirken deshalb auch auf die TTFB zurück, insbesondere Page-Caching sowie Optimierungen an PHP, Plugins und Datenbank. Bild-, CSS- und JavaScript-Optimierungen verbessern dagegen überwiegend die Lade- und Renderingphasen nach dem ersten Byte.

Trotzdem ist Hosting bei vielen WordPress-Websites ein realer Faktor: Als grobe Orientierung nennt web.dev für die meisten Websites eine TTFB von höchstens rund 800 Millisekunden als Zielwert. Ob ein Hosting das erreicht, hängt weniger an der Bezeichnung „Shared“ oder „Managed“ als an der konkreten Infrastruktur, dem Serverstandort, Caching, Auslastung und der WordPress-Konfiguration – ein gutes Shared-Hosting kann darunter liegen, ein schlecht konfiguriertes Managed-Hosting darüber. Ein Baustein dabei: WordPress empfiehlt aktuell PHP 8.3 oder höher – PHP 7.4 wird vom PHP-Projekt bereits seit November 2022 nicht mehr unterstützt und sollte schon aus Sicherheitsgründen ersetzt werden. Neuere PHP-Versionen können zusätzlich Performancevorteile bringen, ohne dass Sie Code ändern müssen – wie stark diese ausfallen, hängt von Website und Workload ab. Prüfen Sie vor dem Wechsel, ob Theme und Plugins mit der neuen Version kompatibel sind; bei vielen Hostern lässt sich die PHP-Version anschließend direkt im Hosting-Panel umstellen.

Weil Hosting-Auswahl und TTFB-Tuning ein eigenes, umfangreiches Thema sind, halte ich diesen Abschnitt bewusst kurz.

🚀 Technische Tiefe zum Hosting: Eine ausführliche Checkliste inklusive konkreter Anbieter-Empfehlungen für den DACH-Raum finden Sie in meinem Artikel WordPress Hosting: Worauf Sie wirklich achten sollten.

Ergebnis prüfen und im Blick behalten

Nach der Umsetzung der fünf Schritte gehört ein erneuter Check dazu: Der Lighthouse-Labortest in PageSpeed Insights zeigt den unmittelbaren Effekt. Die realen Nutzerdaten in PageSpeed Insights und in der Google Search Console basieren dagegen auf einem rollierenden 28-Tage-Zeitraum und reagieren deshalb deutlich langsamer auf Änderungen. Performance ist damit kein einmaliges Projekt, das mit einem Häkchen abgeschlossen wird, sondern ein laufender Prozess – neue Plugins, neue Bilder und neue Inhalte verändern die Ausgangslage immer wieder.

Der Aufwand zahlt sich doppelt aus, denn Ladezeit ist längst kein reines Nutzerfreundlichkeits-Thema mehr. Core Web Vitals werden von Googles Rankingsystemen berücksichtigt, sind aber nur ein Teil der gesamten Bewertung einer Seite – gute Werte allein garantieren keine Top-Platzierung.

📊 Performance als Rankingfaktor: Wie Ladezeit und Core Web Vitals konkret mit Ihrer Sichtbarkeit bei Google zusammenhängen, ordnet mein Einsteiger-Guide zu SEO für KMU in den größeren Zusammenhang ein.

Fazit: Fünf Schritte, ein System

Eine langsame WordPress-Website hat fast nie eine einzelne Ursache – sie ist meist das Ergebnis mehrerer kleiner Nachlässigkeiten, die sich über Monate oder Jahre summieren. Die gute Nachricht: Die fünf Schritte aus diesem Artikel bauen bewusst aufeinander auf und lassen sich auch nach und nach umsetzen. Caching und Bilder liefern oft die schnellsten sichtbaren Erfolge, Plugin-Aufräumarbeit und Datenbank-Pflege sind der nachhaltige Unterbau, und Hosting/TTFB ist das Fundament, auf dem alles andere erst richtig wirkt.

Wenn Sie nach der Umsetzung immer noch an Grenzen stoßen oder schlicht keine Zeit für die laufende Pflege haben, muss das nicht bedeuten, selbst tiefer in die Technik einzusteigen. Für Unternehmen, die ihre Website lieber professionell entwickeln und betreuen lassen, finde ich als IT-Trainer und Webentwickler die passende Lösung – mehr dazu auf meiner Seite zur professionellen WordPress-Entwicklung in Wien.

Ihre Erfahrungen sind gefragt!

Wie schnell lädt Ihre WordPress-Website aktuell, und welcher der fünf Schritte bereitet Ihnen die meisten Kopfschmerzen? Haben Sie Caching und Bildoptimierung schon erfolgreich umgesetzt, oder hängt bei Ihnen noch alles am Hosting? In meinen weiteren WordPress Artikeln finden Sie mehr Praxis-Tipps für den Website-Alltag.

Quellen:

• CMS | Web Almanac 2025 – Core-Web-Vitals-Bestehensraten WordPress/Wix/Duda
• Performance | Web Almanac 2025 – TTFB-Verteilung, LCP-Pfad
• Page Weight | Web Almanac 2025 – Bildgewicht mobiler Startseiten
• Milliseconds Make Millions | Google/SOASTA – Ladezeit und Absprungwahrscheinlichkeit
• About PageSpeed Insights | Google for Developers
• Time to First Byte (TTFB) | web.dev
• WordPress Requirements – empfohlene PHP-Version
• Cache | WordPress Advanced Administration Handbook
• Database Settings | FlyingPress Documentation
• Page Experience | Google Search Central – Core Web Vitals als Rankingfaktor