WordPress-Seite langsam: die vier Hebel, die wirklich zählen

„Die Seite ist langsam“ ist ein Gefühl. Bevor daraus ein Projekt wird, sollte daraus eine Zahl werden. Denn in den meisten Fällen ist nicht die ganze Website langsam, sondern eine Handvoll konkreter Dinge: eine veraltete PHP-Version, fehlendes Caching, Bilder in Originalgröße und drei Skripte von Drittanbietern, die niemand mehr vermisst. In diesem Artikel liest du, wie du in zehn Minuten herausfindest, woran es wirklich liegt, welche Eingriffe am schnellsten wirken und wann tatsächlich das Theme das Problem ist.

Schritt 1: Messen, und zwar richtig

Öffne PageSpeed Insights und gib deine wichtigste Seite ein, nicht nur die Startseite. Prüfe die Seiten, auf denen Besucher tatsächlich landen und auf denen Anfragen entstehen. Der entscheidende Blick geht dabei nach oben, in den Bereich mit den Felddaten. Das sind reale Messwerte von echten Besuchern aus den letzten 28 Tagen. Der bunte Punktwert darunter stammt aus einem simulierten Test und ist nur ein Diagnosewerkzeug, keine Note.

Drei Werte reichen für die Einordnung. Der LCP misst, wann der größte sichtbare Inhalt fertig geladen ist, und sollte unter 2,5 Sekunden liegen. Der INP misst, wie schnell die Seite auf Eingaben reagiert, Zielwert unter 200 Millisekunden. Der CLS misst, wie stark das Layout beim Laden springt, Zielwert unter 0,1. Notiere diese drei Zahlen mit Datum, bevor du irgendetwas änderst. Dieser Ausgangswert ist später dein einziger Beweis, dass die Arbeit etwas gebracht hat.

Ein zweiter Blick lohnt sich in die Serverantwortzeit. Wenn schon das erste Byte spät kommt, hilft keine Bildoptimierung. Dann liegt das Problem vor der Seite, also bei PHP-Version, Datenbank, Caching oder Hosting.

Schritt 2: Die PHP-Version, der am meisten unterschätzte Hebel

PHP ist die Sprache, in der WordPress läuft. Neuere Versionen verarbeiten Anfragen deutlich schneller als alte, und der Wechsel kostet in der Regel keine Entwicklungsarbeit, sondern eine Einstellung beim Hoster. Damit ist es der beste Aufwand-Wirkung-Handel, den es in diesem Feld gibt.

Stand September 2026 solltest du auf PHP 8.3 oder 8.4 laufen. PHP 8.1 und älter bekommen keine Sicherheitsunterstützung mehr, und für PHP 8.2 endet sie zum Jahresende 2026. Wichtig: Die Umstellung gehört nicht spontan ins Livesystem, sondern zuerst auf eine Kopie. Ältere Plugins vertragen neue PHP-Versionen nicht immer, und genau dieser Test entscheidet, ob der Wechsel eine Verbesserung oder ein Ausfall wird.

Schritt 3: Caching, damit nicht jeder Aufruf neu gerechnet wird

Ohne Caching baut WordPress bei jedem einzelnen Aufruf die komplette Seite neu zusammen: Datenbank abfragen, PHP ausführen, HTML erzeugen. Bei einer Seite, deren Inhalt sich selten ändert, ist das reine Verschwendung. Ein Seiten-Cache legt das fertige Ergebnis ab und liefert es beim nächsten Aufruf direkt aus.

Für die meisten Unternehmensseiten genügt genau das, ergänzt um sinnvolle Browser-Regeln, damit wiederkehrende Besucher Bilder und Schriften nicht erneut laden. Ein Objekt-Cache lohnt sich vor allem bei Shops und Portalen mit vielen dynamischen Abfragen. Wichtig ist, es nicht zu übertreiben: Zwei konkurrierende Caching-Plugins gleichzeitig sind eine der häufigsten Ursachen für seltsame Fehler, die niemand reproduzieren kann. Ein Werkzeug, sauber eingerichtet, schlägt drei halbherzig konfigurierte.

Schritt 4: Bilder, der größte Brocken im Seitengewicht

Bilder machen in typischen Installationen den größten Teil der übertragenen Datenmenge aus, und sie sind gleichzeitig der Bereich mit dem einfachsten Gewinn. Die Ursache ist fast immer dieselbe: Jemand lädt Fotos direkt aus der Kamera oder aus dem Grafikprogramm hoch, mehrere tausend Pixel breit, obwohl sie im Layout nur 800 Pixel breit angezeigt werden.

• Passende Größe statt Originaldatei: Kein Bild sollte deutlich größer ausgeliefert werden, als es dargestellt wird.
• Modernes Format: WebP oder AVIF liefern bei vergleichbarer Qualität spürbar kleinere Dateien als klassisches JPEG.
• Nachladen, was unten liegt: Bilder außerhalb des sichtbaren Bereichs erst laden, wenn der Besucher sie erreicht. Das Hauptbild oben dagegen bewusst sofort laden.
• Feste Maße hinterlegen: Sind Breite und Höhe bekannt, reserviert der Browser den Platz und das Layout springt nicht. Das verbessert direkt den CLS-Wert.

Der dauerhafte Teil dieser Aufgabe ist organisatorisch, nicht technisch: Wer Inhalte pflegt, braucht eine klare Regel, in welcher Größe Bilder hochgeladen werden. Sonst wächst das Problem nach jeder Redaktionsrunde nach.

Schritt 5: Ballast entfernen statt Symptome kaschieren

Jedes Plugin bringt eigenes CSS und JavaScript mit, und viele laden es auf allen Seiten, auch dort, wo ihre Funktion gar nicht vorkommt. Das Formular-Plugin lädt auf der Startseite, der Slider auf dem Impressum. Geh die Liste der aktiven Erweiterungen durch und stell zu jeder zwei Fragen: Wird sie wirklich gebraucht, und wird sie noch gepflegt? Alles, was mit Nein beantwortet wird, fliegt raus. Deaktivieren genügt nicht, deinstallieren ist der Punkt.

Der zweite blinde Fleck sind Drittanbieter-Skripte: Tracking, Chat-Fenster, Bewertungs-Widgets, eingebettete Karten und Videos. Sie laden Code von fremden Servern, auf deren Geschwindigkeit du keinen Einfluss hast, und sie sind besonders häufig schuld an schlechten Reaktionszeiten. Stell bei jedem die harte Frage: Was passiert, wenn wir es weglassen? In der Praxis überlebt diese Frage selten die Hälfte. Karten und Videos lassen sich außerdem so einbinden, dass sie erst nach einem Klick wirklich geladen werden.

Schritt 6: Wenn Hosting oder Theme das Problem sind

Bleibt die Serverantwortzeit auch nach Caching und PHP-Update hoch, liegt es am Hosting. Sehr günstige Pakete teilen sich Ressourcen mit vielen anderen Kunden, und an Spitzenzeiten merkst du genau das. Ein Wechsel auf ein Paket mit garantierten Ressourcen ist dann kein Luxus, sondern die Voraussetzung dafür, dass alle anderen Maßnahmen überhaupt wirken können.

Das Theme kommt bewusst zuletzt. Es gibt Baukasten-Themes, die für jede einzelne Sektion Extra-Code mitbringen und dadurch strukturell langsam sind. Ehrlich eingeordnet: Ein Theme-Wechsel ist kein Optimierungsschritt, sondern ein Relaunch mit entsprechendem Aufwand. Deshalb gehört er ans Ende der Liste und nur dann in die Diskussion, wenn die einfachen Ursachen nachweislich ausgeschlossen sind. Wenn du an diesem Punkt ohnehin über einen Neubau nachdenkst, lohnt der Blick auf den Website-Kosten-Rechner für eine erste Größenordnung.

Was Tempo fürs Geschäft bedeutet

Ladezeit ist kein Selbstzweck und auch kein Wettbewerb um Punktwerte. Sie wirkt an zwei Stellen. Erstens auf die Sichtbarkeit, weil Google die tatsächliche Nutzererfahrung als Signal verwendet. Zweitens, und wichtiger, auf das Verhalten deiner Besucher: Wer wartet, springt ab, und zwar besonders auf dem Smartphone und besonders bei Besuchern, die dich noch nicht kennen. Genau die willst du gewinnen.

Deshalb ist die richtige Erfolgskennzahl nicht der Punktwert, sondern das Verhältnis von Besuchern zu Anfragen. Miss vorher, miss vier Wochen später, vergleiche. Alles andere ist Selbstbeschäftigung. Wie sich Wirkung sauber nachweisen lässt, haben wir im Beitrag Kein neuer Name für UX beschrieben, und welche Rolle laufender Betrieb dabei spielt, steht in WordPress-Wartung: warum Updates allein nicht reichen. Denn Tempo ist kein Zustand, den man einmal herstellt. Nach jedem größeren Update kann es wieder kippen.

Fazit

Die meisten langsamen WordPress-Seiten sind keine schwierigen Fälle. Sie laufen auf einer alten PHP-Version, haben kein funktionierendes Caching, liefern Bilder in Originalgröße aus und schleppen Erweiterungen mit, die niemand mehr braucht. Diese vier Punkte lassen sich in wenigen Tagen abarbeiten und bringen zusammen fast immer den größten Teil der möglichen Verbesserung. Wichtig sind nur zwei Dinge: vorher messen, damit du den Fortschritt belegen kannst, und jede Änderung erst auf einer Kopie testen, damit aus einer Optimierung kein Ausfall wird.

• web.dev (Google): Core Web Vitals (Schwellenwerte: LCP unter 2,5 s, INP unter 200 ms, CLS unter 0,1)
• Google: PageSpeed Insights (Felddaten aus echten Nutzerzugriffen der letzten 28 Tage plus Labormessung)
• The PHP Group: Supported Versions (Sicherheitsunterstützung für PHP 8.2 endet am 31.12.2026, PHP 8.1 und älter sind abgekündigt)