Die Performance wird schlechter. Eine Seite, die in zwei Sekunden geladen hat, braucht jetzt vier. Irgendetwas hat sich geändert.
Die Fehlersuche beantwortet: Was hat sich geändert? Warum ist die Performance schlechter geworden?
Mögliche Ursachen: Eine neue Funktion hat ein grosses JavaScript-Bundle mitgebracht. Eine Datenbankabfrage ist langsam geworden. Ein Skript eines Drittanbieters wurde eingebaut. Bilder sind grösser geworden. Der Server ist überlastet.
Eine systematische Fehlersuche findet die Ursache. Eine systematische Behebung beseitigt sie.
Ein Ablauf für die Fehlersuche
Schritt eins: das Symptom erkennen. Der LCP stieg von zwei auf vier Sekunden. Der CLS stieg von 0,05 auf 0,2. Der INP stieg von 100 auf 400 Millisekunden.
Schritt zwei: der Zeitverlauf. Wann hat die Verschlechterung begonnen? Letzte Woche? Gestern? Vor einer Stunde? Der Zeitverlauf grenzt die Suche ein.
Schritt drei: Zusammenhang mit Änderungen herstellen. Welcher Code hat sich geändert? Welche Funktionen sind live gegangen? Was hat sich an der Infrastruktur geändert? Der Zusammenhang zeigt die Ursache.
Schritt vier: die Ursache eingrenzen. Die Performance ist schlechter geworden. Hypothese: das neue JavaScript-Bundle. Test: den LCP messen, wenn das neue Bundle deaktiviert ist. Der LCP liegt wieder bei zwei Sekunden. Die Hypothese ist bestätigt.
Schritt fünf: beheben oder zurückrollen. Du behebst die Ursache (Bundle optimieren) oder rollst zurück (Änderung rückgängig machen). Die Entscheidung hängt vom Schweregrad ab.
Ein Praxisbeispiel: Performance-Einbruch in einem Onlineshop
Symptom: Der LCP stieg von zwei Sekunden auf 3,5 Sekunden. Erkannt durch eine Warnung im Monitoring.
Zeitverlauf: Die Verschlechterung trat am Dienstagmorgen ein. Das Team hatte am Montagabend eine neue Empfehlungs-Engine veröffentlicht.
Zusammenhang: Das zeitliche Zusammentreffen deutet darauf hin, dass die Empfehlungs-Engine die Ursache ist.
Isolationstest: Die Empfehlungs-Engine deaktivieren. Der LCP liegt wieder bei zwei Sekunden. Die Empfehlungs-Engine ist als Ursache bestätigt.
Untersuchung: Die Empfehlungs-Engine lädt Produktbilder für die Empfehlungen. Die Bilder sind nicht optimiert (Originalgrösse, keine Komprimierung). 50 Produktbilder zu laden macht die Seite zwei Megabyte grösser.
Behebung: die Bilder der Empfehlungs-Engine optimieren. Bilder komprimieren, Bilder unterhalb des sichtbaren Bereichs per Lazy Loading laden. Die Bildgrösse sinkt auf 500 Kilobyte. Der LCP verbessert sich auf 2,2 Sekunden.
Ausrollen: Die Empfehlungs-Engine zurückrollen und die optimierte Version veröffentlichen. Der LCP liegt wieder bei 2,2 Sekunden.
Häufige Performance-Probleme und Lösungen
Problem eins: ein grosses JavaScript-Bundle
- Symptom: LCP langsam, INP langsam
- Ursache: Eine neue Funktion bringt Code mit, das Bundle wächst
- Lösung: Die Funktion per Code Splitting aufteilen und per Lazy Loading laden
- Erwartete Verbesserung: Der LCP wird um 0,5 Sekunden besser
Problem zwei: langsame Datenbankabfragen
- Symptom: langsame TTFB
- Ursache: Eine Datenbankabfrage wird langsam (fehlender Index, Abfrage verbindet viele Tabellen)
- Lösung: Datenbankindex hinzufügen, Abfrage optimieren, Ergebnisse zwischenspeichern
- Erwartete Verbesserung: Die TTFB wird um 200 Millisekunden besser
Problem drei: nicht optimierte Bilder
- Symptom: LCP langsam, hoher Bandbreitenverbrauch
- Ursache: Die Bilder sind gross (unkomprimiert, falsches Format)
- Lösung: Bilder komprimieren, in WebP umwandeln, responsive Bilder nutzen
- Erwartete Verbesserung: Der LCP wird um eine Sekunde besser
Problem vier: Skripte von Drittanbietern
- Symptom: LCP langsam, Seite reagiert träge
- Ursache: Analyse-, Tracking- und Anzeigenskripte von Drittanbietern bremsen die Seite
- Lösung: Drittanbieter-Skripte per Lazy Loading laden, einen Web Worker nutzen, asynchron laden
- Erwartete Verbesserung: Der LCP wird um 0,5 Sekunden besser, der INP um 100 Millisekunden
Problem fünf: CLS durch Anzeigen oder eingebettete Inhalte
- Symptom: Layout-Sprünge beim Lesen
- Ursache: Anzeigen laden und nehmen Platz ein, der Inhalt springt
- Lösung: Platz für Anzeigen reservieren, Anzeigen unterhalb des sichtbaren Bereichs per Lazy Loading laden
- Erwartete Verbesserung: Der CLS sinkt von 0,2 auf 0,05
Monitoring zur frühen Erkennung
Warnung bei schlechten Werten: Überschreitet der LCP 2,5 Sekunden, wird das Team gewarnt.
Warnung bei Verschlechterung: Steigt der LCP gegenüber dem Ausgangswert um mehr als 0,5 Sekunden, wird das Team gewarnt.
Warnung bei Auswirkung aufs Geschäft: Sinkt der Abschluss der Anmeldung um ein Prozent, wird das Team gewarnt (das kann auf ein Performance-Problem hindeuten).
Ein Praxisbeispiel: Warnungen in einer SaaS-Firma
- Warnung eins: wenn der LCP 2,5 Sekunden überschreitet
- Warnung zwei: wenn eine Verschlechterung erkannt wird (LCP steigt innerhalb eines Tages um 50 Prozent)
- Warnung drei: wenn die Core Web Vitals bei mehr als fünf Prozent der Nutzer von „gut“ auf „verbesserungswürdig“ rutschen
- Warnung vier: wenn der Abschluss der Anmeldung unter das Ziel fällt (das kann auf ein Performance-Problem der Kassenseite hindeuten)
Wenn eine Warnung auslöst: Das Entwicklerteam untersucht das Problem innerhalb einer Stunde. Die Ursache wird gefunden. Die Behebung geht noch am selben Tag live.
Ein Praxisbeispiel: Performance-Problem bei der Zahlungsabwicklung
Symptom: Die Abbruchrate an der Kasse stieg von 15 auf 25 Prozent. Es begann an einem Donnerstag.
Untersuchung: Die Performance der Kassenseite war schlechter geworden. Die Interaktionszeit der Zahlen-Schaltfläche stieg von 200 Millisekunden auf eine Sekunde.
Zeitverlauf: Der Zahlungsdienstleister hatte am Donnerstagmorgen etwas an seiner Infrastruktur geändert.
Ursache: Der Zahlungsdienstleister war von Kalifornien nach Europa umgezogen. Die Netzwerklatenz vom Nutzer zum Zahlungsdienstleister stieg um 200 Millisekunden. Die gesamte Zahlungsabwicklung dauerte nun eine Sekunde.
Lösung: einen CDN-Edge-Standort in der Nähe des Nutzers nutzen. Die Zahlungsanfrage läuft über den lokalen CDN-Edge. Der CDN-Edge leitet sie an den europäischen Zahlungsdienstleister weiter. Die Netzwerklatenz sinkt. Die Zahlungsabwicklung dauert wieder 200 Millisekunden.
Ergebnis: Die Abbruchrate an der Kasse liegt wieder bei 15 Prozent.
Auswirkung aufs Geschäft: 5.000 Kassenvorgänge im Monat bei 15 Prozent Abbruch sind 750 gescheiterte Conversions. Bei einem Bestellwert von 100 Dollar sind das 75.000 Dollar entgangener Umsatz im Monat. Die Behebung des Latenzproblems sparte dem Unternehmen 75.000 Dollar im Monat.
Häufig gestellte Fragen
Wie erkenne ich, ob ein Performance-Problem vom Code oder von der Infrastruktur kommt?
Teste beides. Deaktiviere den neuen Code (Rollback). Wird die Performance wieder normal, liegt es am Code. Bleibt sie langsam, liegt es an der Infrastruktur. Grenze die Ursache systematisch ein. Gib nicht der Infrastruktur die Schuld, wenn der Code die Ursache ist (und umgekehrt). Mit dem Website-Builder von WEMASY kannst du das direkt auf deiner Website einrichten.
Soll ich zurückrollen oder beheben, wenn die Performance schlechter wird?
Der Schweregrad entscheidet. Ist die Verschlechterung stark (der LCP steigt von zwei auf fünf Sekunden), rolle sofort zurück. Das Nutzererlebnis leidet. Behebe das Problem später. Ist die Verschlechterung gering (der LCP steigt von zwei auf 2,3 Sekunden), behebe es direkt. Das Risiko eines Rollbacks ist dann kleiner als das Risiko, eine unfertige Lösung auszuspielen.
Wie verhindere ich, dass Performance-Probleme in die Produktion gelangen?
Teste die Performance in der CI/CD-Pipeline. Miss die Performance vor jedem Deployment. Wird das Performance-Budget überschritten, blockiere das Deployment. So verhinderst du Verschlechterungen, bevor sie entstehen.
Was ist, wenn das Performance-Problem nur zeitweise auftritt?
Zeitweise Probleme sind schwerer zu finden. Sammle mehr Daten. Beobachte länger. Mögliche Ursachen: ein Netzwerkproblem (tritt in langsamen Netzen auf), ein Traffic-Problem (tritt bei Spitzenlast auf), ein Browserproblem (tritt in bestimmten Browsern auf). Grenze den Bereich ein. Teste die Hypothese in einem bestimmten Netzwerk, zu einer bestimmten Zeit oder in einem bestimmten Browser.
Wie kommuniziere ich Performance-Probleme an Nutzer?
Transparenz schafft Vertrauen. Ist ein Performance-Problem bekannt und wird behoben, sag es deinen Nutzern. Beispiel: Die Kassenseite ist wegen der Umstellung des Zahlungsdienstleisters langsamer. Die Behebung wird bis morgen erwartet. Wir untersuchen es. Transparenz senkt den Frust.
Brauche ich einen Performance-Ingenieur in Bereitschaft?
Bei geschäftskritischen Seiten (Onlineshop, SaaS) ja. Der Ingenieur in Bereitschaft reagiert innerhalb von 30 Minuten auf Performance-Warnungen. Er untersucht das Problem und spielt eine Behebung oder einen Rollback aus. So wirkt sich ein Performance-Problem nicht lange auf Nutzer aus.