Website-Performance messen: vom Symptom zur Ursache

Was „langsam“ konkret bedeutet

Ein Leser kann lange auf die erste Antwort warten oder eine Antwort schnell erhalten, während Bilder und Skripte später die Darstellung verzögern. Eine Suche kann langsam sein, obwohl die Startseite sofort lädt. Beschreibe deshalb den betroffenen Ablauf. Notiere Gerät, Verbindung, Anmeldung und Seitentyp, soweit diese für den Test relevant sind.

Bei dynamischen Websites sind außerdem Hintergrundjobs und Lastspitzen zu beachten. Ein Test ohne Besucher kann anders ausfallen als ein Kampagnenmoment. Das bedeutet nicht, dass ein Labortest wertlos ist. Seine Bedingungen und Grenzen müssen nur offen benannt werden. Vergleiche Beobachtungen, die wirklich dieselbe Frage beantworten.

Serverantwort und Browserarbeit

Der Server berechnet oder liefert eine Antwort. Der Browser lädt weitere Ressourcen, verarbeitet Code und zeichnet die Seite. Beide Ebenen können Engpässe enthalten. Eine große Bilddatei wird nicht dadurch klein, dass mehr CPU im Hosting vorhanden ist. Eine langsame Datenbankabfrage wird nicht allein durch weniger CSS beseitigt.

Core Web Vitals einordnen

Core Web Vitals beschreiben Aspekte der Nutzererfahrung. LCP betrachtet das Laden eines wesentlichen sichtbaren Inhalts, INP die Reaktionsfähigkeit und CLS unerwartete Layoutverschiebungen. Aktuelle Definitionen und Schwellen werden bei Google und web.dev geprüft. Werte aus einem einzelnen lokalen Test sind keine gemessenen Felddaten echter Besucher.

Felddaten spiegeln reale Nutzung in einem betrachteten Zeitraum wider. Labordaten helfen, ein Problem unter kontrollierten Bedingungen zu untersuchen. Ein Werkzeug kann beides nebeneinander darstellen. Achte auf die Kennzeichnung, statt alle Zahlen als denselben Nachweis zu behandeln.

Einen kleinen Messplan aufstellen

Wähle Startseite, einen langen Artikel und eine wichtige dynamische Funktion. Teste unangemeldet und, falls relevant, mit einem sicheren Testkonto. Halte Cachezustand und Netzwerkkonfiguration fest. Ein kalter Abruf und ein wiederholter Cacheabruf können bewusst getrennte Messfälle sein.

• Den Ablauf und sein erwartetes Ergebnis beschreiben.
• Den verwendeten Testaufbau dokumentieren.
• Wiederholungen durchführen, wenn Streuung erkennbar ist.
• Ressourcen und Fehlermeldungen mit dem Zeitpunkt verbinden.
• Eine Änderung nach derselben Methode vergleichen.

Maßnahmen nach Ursache auswählen

Bei großen Bildern prüfst du Format, Breite und Kompression. Bei langen Skriptausführungen untersuchst du unnötige Bibliotheken und tatsächlich benötigte Interaktionen. Bei langsamen Serverantworten helfen Anwendungsauswertung, Datenbankprüfung und Cacheanalyse. Die Maßnahme muss zum Befund passen.

Der Cache-Ratgeber erklärt, warum individuelle Inhalte gesondert behandelt werden. Ein Cache-HIT kann eine öffentliche Inhaltsseite verbessern, beantwortet aber nicht die Frage nach einem langsamen Warenkorb oder Import. Pauschales Caching ist dafür kein fachgerechter Ersatz.

Wann mehr Ressourcen sinnvoll sind

Wenn die notwendige, sinnvoll optimierte Last den vorhandenen Rahmen überschreitet, kann ein Tarifwechsel helfen. Dafür brauchst du einen belegten Zusammenhang: welche Ressource ist betroffen, welche Aufgabe benötigt sie und welche Grenze wird erreicht? Ein subjektiver Eindruck reicht selten für eine präzise Auswahl.

Prüfe nach dem Wechsel denselben Ablauf erneut. Ein Verbesserungsnachweis gilt für diese Messung, nicht als allgemeine Garantie. Der Artikel über Ressourcen hilft, RAM, CPU und Prozessgrenzen auseinanderzuhalten. Eine ehrliche Performanceübergabe nennt Testart, Bedingungen, Ergebnisse und noch offene Besucherbeobachtungen.