WordPress ist langsam? Erst TTFB, LCP und JavaScript unterscheiden

Wenn eine WordPress-Seite träge wirkt, liegt die Ursache nicht automatisch am Hosting. Manchmal kommt das HTML spät, manchmal wird das große Titelbild erst spät geladen, und manchmal reagieren Menüs oder Formulare verzögert, obwohl die Seite bereits sichtbar ist. Für diese drei Fälle ist die passende Maßnahme jeweils eine andere.

Wer direkt ein weiteres „Performance-Plugin“ installiert, riskiert überlappende Cache-Regeln, unübersichtliche Einstellungen und neue Fehlerquellen. Besser ist ein kurzer Diagnoseplan mit konkreter URL, Messmethode, vermuteter Ursache und überprüfbarer Änderung.

TTFB, LCP und JavaScript: drei verschiedene Signale

Time to First Byte (TTFB) umfasst die Zeit zwischen Beginn der Navigation und dem Eintreffen des ersten Antwort-Bytes. Dazu können Weiterleitungen, DNS-Auflösung, Verbindungsaufbau und TLS sowie die Wartezeit auf die Antwort beitragen. TTFB ist damit keine isolierte Stoppuhr für PHP oder die Datenbank.

Largest Contentful Paint (LCP) beschreibt den Zeitpunkt, an dem das größte geeignete sichtbare Bild-, Video- oder Textelement im Darstellungsbereich gerendert wird. Nach den Core-Web-Vitals-Grenzwerten gilt ein LCP von höchstens 2,5 Sekunden beim 75. Perzentil realer Seitenaufrufe als gut, getrennt nach Mobilgeräten und Desktop. Ein ordentlicher TTFB-Wert garantiert das nicht: Das LCP-Element kann noch spät entdeckt oder durch CSS und JavaScript verzögert werden.

JavaScript-Ausführung kann den Hauptthread des Browsers auslasten und die Reaktion auf Nutzereingaben beeinträchtigen. Dafür ist unter anderem der Core Web Vital INP relevant. Eine Seite kann schnell sichtbar sein und dennoch bei einem Klick hängen. Nicht jede JavaScript-Datei ist überflüssig; wichtig sind Funktion, Ausführungszeit und die tatsächlich beobachtete Verzögerung.

1. Eine einzelne URL statt pauschal „die Website“ messen

Halten Sie fest, auf welcher Seite das Problem auftritt: Startseite, Leistungsseite, Blogartikel, Produktdetailseite oder Checkout. Notieren Sie Datum, Gerätetyp, verwendetes Testwerkzeug und gegebenenfalls die Unterschiede zwischen Erstaufruf und wiederholtem Seitenbesuch.

PageSpeed Insights zeigt, soweit genügend Daten vorliegen, Felddaten aus echten Chrome-Nutzungen und dazu Laborhinweise. Lighthouse bietet eine reproduzierbare simulierte Perspektive, ist aber kein vollständiges Bild aller Besucher. Fehlen ausreichend Felddaten, ist der Wert unbekannt und nicht „null“. Ein einzelner Score beweist weder eine generelle Verbesserung noch eine SEO-Wirkung.

Eine Elementor-Startseite mit großem Hintergrundmotiv benötigt eine andere Analyse als eine WooCommerce-Kasse, die dynamische Preise, Warenkorbstatus und Zahlungsarten verarbeitet.

2. Hoher TTFB? Den Weg bis zur HTML-Antwort zerlegen

Prüfen Sie im Netzwerk-Wasserfall: Gibt es mehrere Weiterleitungen? Dauern DNS oder TLS-Verbindung ungewöhnlich lange? Entsteht die Wartezeit erst nach dem Senden der Anfrage? Erst danach ist eine Hypothese zur Serververarbeitung sinnvoll.

Je nach Befund kommen Cache-Eignung, dynamische Datenbankabfragen, externe Dienste oder die Antwort der Hosting-Umgebung als Untersuchungsfelder infrage. All das sind Kandidaten, keine vorweggenommene Schuldzuweisung an einen bestimmten Anbieter oder ein Plugin.

Besonders wichtig bei WooCommerce: Warenkorb, Kundenkonto und Checkout können persönliche oder sitzungsabhängige Informationen enthalten. Wer solche Seiten unbedacht wie einen statischen Blogartikel zwischenspeichert, riskiert falsche Inhalte. Änderungen an produktiven Cache-Ausnahmen gehören in einen abgesicherten, gesondert geprüften Ablauf.

3. Guter TTFB, schlechter LCP? Das größte sichtbare Element finden

Ermitteln Sie zunächst, welches Element den LCP ausmacht. Auf einer Elementor-Seite kann es ein Hero-Bild im Hintergrund einer Sektion, ein großes Produktfoto oder eine Überschrift sein. Erst mit dieser Information lässt sich entscheiden, ob die Priorisierung des Bildes, sein Format, der Download, eine Schrift oder blockierendes CSS relevant ist.

Ein großes Bild im sofort sichtbaren Bereich reflexartig per Lazy Loading zu verzögern, kann LCP verschlechtern. Ebenso löst die Komprimierung einer Datei nicht das Problem, wenn der Browser den Bildabruf erst nach mehreren CSS- oder JavaScript-Schritten startet.

Wägen Sie Design und Ladeverhalten ab: Ein klarer Bildzuschnitt, ein richtig dimensioniertes responsives Motiv und eine früh verfügbare Ressource können sinnvoller sein als das ersatzlose Entfernen sämtlicher Gestaltungselemente.

4. Sichtbar, aber nicht bedienbar? Skripte und Interaktion untersuchen

Öffnen Sie in den Browser-Entwicklertools die Performance-Ansicht. Suchen Sie nach längeren Hauptthread-Aufgaben und prüfen Sie die beteiligten Skripte. Mögliche Kandidaten sind Slider, eingebettete Videos, Marketing-Tags, Chat-Komponenten und unnötige Widgets. Ein langsamer Kontaktformular-Klick hat nicht zwingend dieselbe Ursache wie ein spät erscheinendes Titelbild.

Entfernen oder verzögern Sie Code nur nach einer Funktionsprüfung. Ein vermeintlich schnellerer Checkout, dessen Zahlungs- oder Versandlogik beschädigt ist, wäre keine Verbesserung. Testen Sie möglichst in Staging und dokumentieren Sie die Änderung sowie den Rückweg.

5. Prioritäten bei Elementor und mehrsprachigem WordPress

Kontrollieren Sie, welche Widgets und Erweiterungen auf der konkreten Seite tatsächlich gebraucht werden. Die reine Zahl installierter Plugins ist kein verlässlicher Geschwindigkeitswert. Ebenso muss die Wirkung zusätzlicher Sprachen über WPML nicht auf jeder Seite identisch sein. Achten Sie auf Sprachmenüs, Layoutunterschiede, Schriften und bei arabischen Versionen auf die Darstellung von rechts nach links.

Bewerten Sie anschließend den gesamten Weg des Nutzers: Startseite öffnen, eine Leistung finden, ein Kontaktformular ausfüllen beziehungsweise ein Produkt in den Warenkorb legen. Ein schöner Lighthouse-Wert nützt wenig, wenn eine geschäftskritische Funktion nach der Optimierung nicht mehr arbeitet.

Diagnose-Matrix

HTML-Antwort beginnt spät

Zuerst prüfen: Weiterleitungen, Netzwerk, Cache-Eignung, Backend

Passender Nachweis: Navigation-Timing und Netzwerk-Wasserfall

Großes Bild erscheint spät

Zuerst prüfen: LCP-Ressource, Ladepriorität, CSS

Passender Nachweis: LCP-Element und Ressourcen-Timing

Klick auf Menü/Formular verzögert

Zuerst prüfen: Hauptthread, Third-Party-Skripte, Event-Handler

Passender Nachweis: DevTools-Performance-Aufzeichnung

Mobil langsam, Desktop unauffällig

Zuerst prüfen: Bildgrößen, CPU, Layout, Netzwerkbedingungen

Passender Nachweis: vergleichbare mobile Tests und Felddaten

Häufige Fragen

Ist ein hoher TTFB-Wert automatisch ein Hosting-Problem?

Nein. Der Wert enthält auch Netz- und Verbindungsanteile sowie Weiterleitungen. Erst die zeitliche Zerlegung zeigt, wo eine weitere Analyse lohnt.

Führt ein guter Core-Web-Vitals-Bericht zu besseren Google-Rankings?

Nicht automatisch. Google weist darauf hin, dass gute technische Kennzahlen eine gute Nutzererfahrung unterstützen, aber keine Spitzenposition garantieren.

Sollte man gleich ein weiteres Cache- oder Optimierungs-Plugin installieren?

Nur wenn es einen nachgewiesenen Engpass mit vertretbarem Risiko behebt. Zuerst Messung, dann gezielte Änderung, dann erneute Prüfung unter möglichst vergleichbaren Bedingungen.

So sieht eine brauchbare Übergabe nach dem Test aus

Halten Sie URL, Gerät, Problembeobachtung, Messdaten-Herkunft, betroffene Ressource oder Funktion, konkrete Änderung und Ergebnis fest. Bei noch offenen Punkten kennzeichnen Sie die Ursache als Hypothese. Veröffentlichen Sie weder vertrauliche Kundenkennzahlen noch angebliche Verbesserungen, die nicht gemessen wurden.