Kurz gesagt: Prüfe zuerst, ob die Wartezeit vor dem ersten Inhalt entsteht, beim Laden von Bildern oder erst bei der Bedienung. Miss dieselbe Seite mehrmals unter vergleichbaren Bedingungen. Installiere erst dann eine Optimierung, wenn sie zum beobachteten Engpass passt.
Bevor du anfängst
- Öffne Startseite, eine wichtige Unterseite und das Backend getrennt voneinander.
- Vergleiche einen ausgeloggten Aufruf am Smartphone mit deinem gewohnten Desktop-Browser.
- Notiere, seit wann es langsam ist und ob kurz vorher Plugins, Inhalte oder Hosting geändert wurden.
1. Lege fest, was genau zu langsam ist
Wähle drei typische Seiten: etwa die Startseite, eine Leistungsseite und eine Kontakt- oder Produktseite. Lade jede mehrfach und notiere, wann der Inhalt sichtbar wird und wann du ihn bedienen kannst. Ein einzelner guter Aufruf kann aus einem bereits gefüllten Cache kommen; ein einzelner schlechter kann durch dein Netz beeinflusst sein.
Gib die öffentliche Seitenadresse in PageSpeed Insights ein und starte „Analysieren“. Vergleiche die Ansichten für Mobilgeräte und Desktop; notiere vor allem LCP für den großen sichtbaren Inhalt und Hinweise zu langsamen Ressourcen. Unterscheide die aktuelle Labormessung von gegebenenfalls vorhandenen Daten echter Besucher. Für kleine Websites können diese Besucherdaten fehlen. Prüfe Menü und Formulare zusätzlich selbst: Der Gesamtwert einer Lademessung beschreibt nicht jeden späteren Klick.
- Lange leere Fläche vor dem ersten Inhalt: Serverantwort und Seitenaufbereitung untersuchen.
- Text erscheint, das große Titelbild deutlich später: Bilddatei und Ladepriorität prüfen.
- Inhalt ist da, Klicks reagieren verzögert: Skripte und Browserauslastung untersuchen.
- Nur das Backend ist langsam: administrative Prozesse, Datenbank und externe Anbindungen prüfen.
2. Wartet der Browser schon auf den Server?
Wenn bereits die Antwort für das HTML-Dokument lange dauert, bringt ein kleineres Logo wenig. Die Wartezeit auf die erste Antwort wird häufig als TTFB bezeichnet. Darin steckt auch der Netzwerkweg; sie ist kein reiner Messwert der WordPress-Rechenzeit. Wiederholt lange Wartezeiten über verschiedene Verbindungen hinweg sind ein Anlass, die Seitenaufbereitung und das Hosting genauer zu prüfen.
Vergleiche einen ersten und einen wiederholten ausgeloggten Aufruf. Ist nur der zweite deutlich schneller, arbeitet wahrscheinlich eine Zwischenspeicherung mit. Das kann für Inhaltsseiten sinnvoll sein, erklärt aber noch nicht die Geschwindigkeit ungecachter Seiten. Bitte den Hoster bei anhaltenden Problemen um zeitlich passende Ressourcen- und Fehlerdaten. Die Aussage „mehr Arbeitsspeicher nötig“ sollte durch einen konkreten Engpass begründet sein.
- Netzwerkansicht öffnen In Chrome oder Edge klickst du mit der rechten Maustaste auf die Seite, wählst „Untersuchen“ und dann „Netzwerk“ beziehungsweise „Network“. Aktiviere für diesen Vergleich „Cache deaktivieren“ und lade neu. Das betrifft den Browser-Cache, solange die Entwicklerwerkzeuge offen sind; ein Server-Cache bleibt aktiv.
- Die erste Dokumentanfrage ansehen Wähle die Zeile vom Typ „document“ beziehungsweise den Filter „Doc“. Unter „Timing“ zeigt „Waiting for server response“ beziehungsweise TTFB die Wartephase. Ist sie bei mehreren Aufrufen lang, untersuchst du zuerst Server, Anwendung und Verbindung.
- Danach Bild- und Skriptdateien vergleichen Kommt das Dokument schnell, die Seite aber spät, filtere nach „Img“ oder „JS“ und prüfe große Dateien sowie spät startende Downloads. Die Spalten Größe, Zeit und Wasserfall helfen beim Vergleich. Schließe die Entwicklerwerkzeuge nach dem Test wieder.
Ein langsames Backend braucht eine eigene Diagnose: Ein Seiten-Cache für Besucher beschleunigt nicht automatisch das Speichern eines Beitrags. Notiere die konkrete langsame Aktion und ihren Zeitpunkt, damit Server- und Anwendungsprotokolle dazu passen.
3. Große Bilder gezielt kleiner und früher sichtbar machen
Ein Foto mit mehreren Tausend Pixeln Breite ist oft unnötig, wenn es nur in einer kleinen Karte erscheint. Wähle beim Bildblock oder im Builder eine passende Bildgröße statt automatisch „Vollständige Größe“, sofern diese Auswahl angeboten wird. Eine 400 Pixel breite Karte braucht nicht grundsätzlich das 5.000 Pixel breite Original; hochauflösende Displays und größere Ansichten müssen trotzdem scharf bleiben. Vergleiche deshalb die Darstellung auf den tatsächlich genutzten Bildschirmbreiten, statt jede Datei auf einen pauschalen Wert zu verkleinern.
Das zentrale Bild im ersten sichtbaren Bereich sollte nicht erst nach einer Nutzeraktion oder spät durch ein Skript angefordert werden. Bilder weiter unten können dagegen verzögert laden. Reservierter Platz verhindert, dass Text und Schaltflächen beim Nachladen verrutschen. Nach jeder Umstellung solltest du verschiedene Bildschirmbreiten prüfen: Ein gutes Desktop-Bild kann auf dem Smartphone weiterhin viel zu groß sein.
- Das LCP-Element finden Klappe im PageSpeed-Bericht den Hinweis zum LCP-Element beziehungsweise zu dessen Ressourcen auf. Die genaue Bezeichnung hängt von der Berichtsversion ab. Prüfe das dort genannte Bild oder den Textblock, statt automatisch das Logo zu optimieren.
- Geladene Datei und sichtbare Größe vergleichen Filtere in der Netzwerkansicht nach Bildern und öffne die Vorschau des betreffenden Eintrags. Vergleiche dessen Abmessungen und Übertragungsgröße mit dem sichtbaren Platz auf der Seite. Prüfe nach einer Änderung, ob der Browser wirklich eine kleinere Variante lädt und das Motiv weiterhin scharf wirkt.
4. Plugins und externe Skripte nach Wirkung prüfen
Die Anzahl installierter Plugins ist kein zuverlässiges Maß für Geschwindigkeit. Eine einzelne aufwendige Erweiterung kann mehr bewirken als mehrere kleine. Auffällig sind Funktionen, die überall laden, obwohl sie nur auf einer Unterseite gebraucht werden, oder Dienste, auf deren Antwort die Seite warten muss.
Erstelle vor Eingriffen eine Sicherung und teste auf einer geschützten Kopie. Schalte dort jeweils eine verdächtige Funktion ab und wiederhole dieselbe Messung. Prüfe auch Einwilligungsdialoge, Karten, Chats, Videos und Tracking. Entferne keine geschäftlich benötigte Funktion, nur weil ein Messwert dadurch besser aussieht. Entscheidend ist, ob du dieselbe Aufgabe mit weniger Ladeaufwand zuverlässig erfüllen kannst.
Optimierung kann Funktionen beschädigen: Zusammenfassen, Verzögern oder Umordnen von JavaScript kann Menüs, Formulare und Zahlarten beeinträchtigen. Aktiviere solche Optionen einzeln und kontrolliere nach jeder Änderung die wichtigsten Nutzerwege.
5. Cache passend zur Seite einsetzen
Ein Seiten-Cache liefert bereits erzeugte Inhalte aus und kann die Serverarbeit deutlich reduzieren. Dafür muss klar sein, welche Inhalte für alle Besucher gleich sind und wann eine gespeicherte Fassung ungültig wird. Eine Leistungsseite hat andere Anforderungen als ein Warenkorb oder ein angemeldeter Kundenbereich.
Kläre zuerst, ob Hosting, WordPress-Plugin oder ein vorgeschalteter Dienst bereits Seiten zwischenspeichern. Mehrere unabhängig konfigurierte Lösungen machen die Fehlersuche unnötig schwer. Halte personalisierte Bereiche aus dem öffentlichen Seiten-Cache heraus und teste, ob Änderungen nach dem Veröffentlichen sichtbar werden. Prüfe außerdem, ob ein geleerter Cache bei hohem Besucheraufkommen den Server vorübergehend stärker belastet.
6. Die Verbesserung im Alltag bestätigen
Vergleiche nach der Optimierung genau die zuvor ausgewählten Seiten unter ähnlichen Bedingungen. Prüfe Laden, Scrollen, Menü, Formular und bei einem Shop die Kasse in einer geeigneten Testumgebung. Bewahre die vorherigen Messwerte auf. So lässt sich später erkennen, ob eine neue Erweiterung die Verbesserung wieder aufgehoben hat.
Wenn du Hilfe benötigst, sind konkrete Adressen, Gerät, beobachtete Wartezeit und eine Messung hilfreicher als ein einzelner Screenshot mit rotem Punktestand. Dazu gehört die Information, ob Besucher und Backend gleichermaßen betroffen sind. Mit dieser Eingrenzung lässt sich gezielt am größten Engpass arbeiten, statt mehrere Optimierungsplugins auf Verdacht übereinanderzulegen.
Häufige Fragen
Brauche ich für eine schnelle Website einen PageSpeed-Wert von 100?
Nein. Der Wert ist eine hilfreiche Orientierung aus einer bestimmten Messung. Wichtiger sind sichtbare Ladezeit, stabile Darstellung und zuverlässige Bedienung auf den tatsächlich genutzten Seiten und Geräten.
Macht ein Cache-Plugin auch mein Backend schneller?
Ein öffentlicher Seiten-Cache meist nicht. Speichern, Suchen oder Produktverwaltung lösen andere Prozesse aus. Dafür müssen unter anderem Datenbankabfragen, Plugins und externe Verbindungen betrachtet werden.
Ist mein Hosting schuld?
Das ist möglich, aber nicht aus einer langsamen Seite allein ableitbar. Wiederholt hohe Serverwartezeiten und passende Ressourcenmessungen liefern Hinweise. Große Bilder oder blockierende Skripte können auch auf leistungsfähigem Hosting langsam sein.
Soll ich alle ungenutzten Plugins löschen?
Nicht mehr benötigte Erweiterungen zu entfernen ist sinnvoll. Kläre vorher, ob sie noch Inhalte, Formulare oder Daten verwalten, und sichere die Seite. Eine geringere Anzahl allein garantiert keine bessere Ladezeit.