Website-Ladezeit messen und richtig beurteilen

Wie schnell ist meine Website? Die Frage klingt einfach, lässt sich aber nicht mit einer einzigen Zahl vollständig beantworten.

Eine Website besitzt nicht nur den einen Zeitpunkt, an dem sie „geladen“ ist. Der Browser beginnt mit der Verbindung zum Server, empfängt HTML, lädt weitere Ressourcen und baut daraus schrittweise die sichtbare und interaktive Seite auf.

Deshalb können verschiedene Performance-Werkzeuge für dieselbe Website unterschiedliche Messwerte anzeigen – ohne dass eines davon zwangsläufig falsch ist.

In dieser Anleitung erklären wir dir, wie du die Ladezeit einer Website sinnvoll misst, welche Kennzahlen wichtig sind und wie du Messergebnisse richtig beurteilst.

Kurz erklärt: Beurteile die Geschwindigkeit einer Website nicht anhand einer einzigen Ladezeit oder eines einzelnen Tests. Aussagekräftiger ist die Kombination aus mehreren Messungen, verschiedenen Performance-Kennzahlen und – sofern verfügbar – Daten echter Besucher.

Warum gibt es nicht die eine Ladezeit? #

Beim Aufruf einer Website passieren zahlreiche Vorgänge nacheinander und teilweise gleichzeitig.

Vereinfacht:

URL aufrufen
    ↓
Verbindung herstellen
    ↓
Server verarbeitet Anfrage
    ↓
HTML wird übertragen
    ↓
Browser verarbeitet HTML
    ↓
CSS, JavaScript, Bilder und Fonts laden
    ↓
erste Inhalte werden sichtbar
    ↓
wichtiger Hauptinhalt erscheint
    ↓
weitere Ressourcen werden geladen
    ↓
Seite reagiert auf Benutzerinteraktionen

Je nachdem, welchen Teil dieses Ablaufs ein Werkzeug betrachtet, entsteht ein anderer Messwert.

Was beeinflusst die gemessene Ladezeit? #

Eine Messung hängt nicht nur von der Website selbst ab.

Auch die Bedingungen des Tests beeinflussen das Ergebnis. Dazu gehören beispielsweise:

• Standort des Testsystems,
• Netzwerkgeschwindigkeit und Latenz,
• verwendetes Gerät beziehungsweise simulierte Hardware,
• Browser,
• Cache-Zustand,
• Serverauslastung,
• externe Dienste und Ressourcen.

Deshalb kann dieselbe Website bei zwei Messungen unterschiedliche Ergebnisse liefern.

Was bedeutet TTFB? #

TTFB steht für Time to First Byte.

Die Kennzahl beschreibt vereinfacht die Zeit zwischen dem Beginn einer Anfrage und dem Eintreffen des ersten Bytes der HTTP-Antwort.

Anfrage beginnt
      ↓
Verbindung / Anfrage / Verarbeitung
      ↓
erstes Byte der Antwort
      ↑
     TTFB

TTFB kann Hinweise auf den frühen Teil der Anfrage liefern, ist aber keine vollständige Messung der Website-Ladezeit.

Eine gute TTFB bedeutet beispielsweise nicht automatisch, dass anschließend große Bilder, umfangreiches JavaScript oder externe Ressourcen schnell verarbeitet werden.

TTFB ist nicht nur „Servergeschwindigkeit“ #

TTFB wird häufig vereinfacht als reine Antwortzeit des Webservers bezeichnet. Das ist ungenau.

Der gemessene Wert kann mehrere Bestandteile umfassen, darunter Netzwerk- und Verbindungszeiten sowie die Verarbeitung der Anfrage auf der Serverseite.

Auch der Standort des messenden Systems relativ zum Server kann deshalb einen Einfluss haben.

Wichtig: Verwende TTFB als Diagnosewert, aber nicht als alleinige Bewertung der Geschwindigkeit einer Website oder eines Hosting-Servers.

Was bedeutet FCP? #

FCP steht für First Contentful Paint.

Der Wert beschreibt den Zeitpunkt, an dem der Browser erstmals Inhalt aus dem Dokument rendert, beispielsweise Text, ein Bild oder andere sichtbare Elemente.

FCP betrachtet damit einen anderen Aspekt als TTFB.

Server antwortet
      ↓
Browser verarbeitet Seite
      ↓
erster relevanter Inhalt wird dargestellt
      ↑
     FCP

Was bedeutet LCP? #

LCP steht für Largest Contentful Paint.

Die Kennzahl betrachtet, wann das größte relevante Inhaltselement im sichtbaren Bereich gerendert wurde.

Das kann je nach Seite beispielsweise ein großes Bild, eine Überschrift oder ein anderer Inhaltsblock sein.

Ein großes Hero-Bild kann deshalb erheblichen Einfluss auf den LCP haben.

Die genaue Bedeutung von LCP sowie INP und CLS erklären wir unter Core Web Vitals erklärt: LCP, INP und CLS.

Was bedeutet „vollständig geladen“? #

Auch der Begriff „vollständig geladen“ ist nicht so eindeutig, wie er zunächst klingt.

Eine Website kann für den Besucher bereits vollständig nutzbar wirken, während im Hintergrund noch weitere Ressourcen oder Anfragen verarbeitet werden.

Umgekehrt kann ein technisches Ladeereignis bereits stattgefunden haben, obwohl eine wichtige externe Funktion noch nicht bereit ist.

Deshalb sollte eine einzelne Angabe wie „Load Time: 2,1 Sekunden“ nicht isoliert betrachtet werden.

Was sind Lab-Daten? #

Lab-Daten entstehen unter kontrollierten beziehungsweise simulierten Testbedingungen.

Ein Performance-Werkzeug lädt die Website mit definierten Bedingungen und misst dabei verschiedene Kennzahlen.

Das hat einen großen Vorteil: Tests lassen sich unter ähnlichen Bedingungen wiederholen und miteinander vergleichen.

Lab-Daten eignen sich deshalb besonders gut zur technischen Diagnose und zum Vergleich vor und nach einer Änderung.

Was sind Field-Daten? #

Field-Daten basieren auf Messungen unter realen Nutzungsbedingungen.

Sie zeigen, wie eine Website tatsächlich bei echten Besuchern beziehungsweise Geräten und Netzwerkbedingungen erlebt wurde, sofern für die betreffende Website oder URL genügend entsprechende Daten verfügbar sind.

Dadurch können Field-Daten eine andere Perspektive liefern als ein einzelner Lab-Test.

Kurz erklärt: Lab-Daten zeigen, wie eine Website unter bestimmten Testbedingungen funktioniert. Field-Daten zeigen, wie sie unter realen Nutzungsbedingungen tatsächlich erlebt wurde.

Warum können Lab- und Field-Daten unterschiedlich sein? #

Ein Lab-Test verwendet definierte Bedingungen. Reale Besucher nutzen dagegen unterschiedliche Geräte, Browser, Netzwerkverbindungen und Standorte.

Beispielsweise kann ein leistungsfähiger Desktop über eine schnelle Verbindung eine Website anders erleben als ein älteres Smartphone in einem Mobilfunknetz.

Unterschiedliche Ergebnisse sind deshalb nicht automatisch ein Widerspruch.

Was sind Core Web Vitals? #

Die Core Web Vitals sind Kennzahlen, mit denen bestimmte Aspekte der Nutzererfahrung einer Website gemessen werden.

Aktuell gehören dazu:

LCP → Largest Contentful Paint
      Ladeerlebnis

INP → Interaction to Next Paint
      Reaktionsfähigkeit

CLS → Cumulative Layout Shift
      visuelle Stabilität

Diese drei Werte betrachten unterschiedliche Aspekte einer Website und sollten deshalb nicht zu einer einzigen allgemeinen „Ladezeit“ zusammengefasst werden.

Welche Messwerte sind für mich wichtig? #

Das hängt davon ab, was du untersuchen möchtest.

Wenn du wissen möchtest, ob der Server früh auf eine Anfrage reagiert, kann TTFB interessant sein.

Wenn du wissen möchtest, wann wichtige sichtbare Inhalte erscheinen, sind Rendering-Kennzahlen wie FCP und LCP hilfreicher.

Wenn Benutzer über verzögerte Reaktionen auf Interaktionen berichten, ist wiederum die Interaktivität relevant.

Eine gute Performance-Analyse beginnt deshalb mit der Frage:

Welches Problem möchte ich eigentlich messen?

Website mit Google PageSpeed Insights messen #

Google PageSpeed Insights ist ein bekanntes Werkzeug zur Analyse der Website-Performance.

Es kann Lab-Daten aus Lighthouse und – sofern für die betreffende Seite beziehungsweise Herkunft ausreichend Daten verfügbar sind – reale Nutzungsdaten aus dem Chrome User Experience Report darstellen.

Dadurch eignet sich PageSpeed Insights sowohl für eine erste technische Analyse als auch zur Betrachtung der Core Web Vitals.

Die einzelnen Bereiche und Empfehlungen erklären wir im nächsten Artikel unter Google PageSpeed Insights richtig verwenden.

Mobile und Desktop getrennt betrachten #

Performance-Ergebnisse für mobile Geräte und Desktop-Systeme können deutlich voneinander abweichen.

Das ist nicht überraschend: Ein Smartphone besitzt andere Leistungsmerkmale und kann über eine andere Netzwerkverbindung auf eine Website zugreifen als ein Desktop-PC.

Beurteile deshalb nicht ausschließlich den Desktop-Test, nur weil dort ein höherer Performance-Wert erreicht wird.

Wenn ein erheblicher Teil deiner Besucher mobile Geräte verwendet, ist die mobile Nutzung mindestens ebenso relevant.

Warum ist der Standort des Tests wichtig? #

Daten müssen zwischen dem Testsystem und den beteiligten Servern übertragen werden.

Je größer beziehungsweise ungünstiger die Netzwerkdistanz und Route, desto höher kann die Latenz ausfallen.

Eine Website mit primärer Zielgruppe in der Schweiz oder in Mitteleuropa sollte deshalb nicht ausschließlich anhand eines einzelnen Tests von einem weit entfernten Standort beurteilt werden.

Für vergleichbare Messungen solltest du möglichst ähnliche Teststandorte verwenden.

Was bedeutet Latenz? #

Latenz beschreibt vereinfacht die Verzögerung bei der Datenübertragung zwischen zwei Punkten.

Sie ist nicht dasselbe wie Bandbreite.

Eine Verbindung kann eine hohe maximale Datenrate besitzen und trotzdem eine relativ hohe Latenz aufweisen.

Bei Websites können zahlreiche Netzwerkvorgänge stattfinden, weshalb Latenz für die wahrgenommene Geschwindigkeit relevant sein kann.

Cache beeinflusst Messergebnisse #

Beim ersten Aufruf einer Website müssen möglicherweise Ressourcen geladen werden, die bei einem späteren Besuch bereits im Browser-Cache vorhanden sind.

Auch serverseitige Cache-Systeme können dazu führen, dass eine bereits vorbereitete beziehungsweise zwischengespeicherte Antwort schneller bereitgestellt wird als eine Anfrage, die vollständig neu erzeugt werden muss.

Deshalb solltest du wissen, ob du einen sogenannten kalten oder bereits aufgewärmten Zustand misst.

Was bedeutet Cold Cache und Warm Cache? #

Vereinfacht:

Cold Cache
→ benötigte Daten sind noch nicht im relevanten Cache vorhanden

Warm Cache
→ benötigte Daten können bereits aus einem Cache bereitstehen

Welche Caches beteiligt sind, hängt von der Website und Infrastruktur ab.

Bei Performance-Vergleichen solltest du möglichst unter vergleichbaren Bedingungen messen.

Ein einzelner Test reicht nicht #

Netzwerke und Server arbeiten nicht unter vollkommen konstanten Bedingungen.

Eine Messung kann beispielsweise durch eine kurzfristige Netzwerkverzögerung oder einen externen Dienst beeinflusst werden.

Führe deshalb mehrere Messungen durch und achte auf wiederkehrende Muster.

Beispiel:

Test 1 → 1,8 s
Test 2 → 2,0 s
Test 3 → 1,9 s

anderer Test:

Test 1 → 1,7 s
Test 2 → 8,4 s
Test 3 → 1,8 s

Beim zweiten Beispiel sollte zunächst untersucht werden, weshalb eine Messung deutlich aus der Reihe fällt, bevor daraus eine allgemeine Aussage über die Website abgeleitet wird.

Immer dieselbe URL vergleichen #

Die Startseite ist nicht automatisch repräsentativ für die gesamte Website.

Eine einfache Kontaktseite kann beispielsweise deutlich weniger Ressourcen benötigen als eine umfangreiche Produktseite oder ein Online-Shop.

Wenn du Optimierungen vergleichst, verwende deshalb dieselbe URL vor und nach der Änderung.

Vorher:
/produkt/beispiel/

Nachher:
/produkt/beispiel/

Nur so vergleichst du denselben Seitentyp.

Mehrere wichtige Seitentypen testen #

Für eine umfassendere Beurteilung solltest du nicht ausschließlich die Startseite messen.

Je nach Website können beispielsweise folgende Seitentypen sinnvoll sein:

Startseite
wichtige Leistungsseite
Blogartikel
Landingpage
Produktseite
Shop-Kategorieseite
Checkout

Eine einzelne schnelle Seite beweist nicht, dass sämtliche anderen Bereiche dieselbe Performance besitzen.

Tests vor und nach Änderungen dokumentieren #

Wenn du eine Performance-Maßnahme beurteilen möchtest, solltest du Ausgangs- und Endzustand dokumentieren.

Beispiel:

URL:
https://example.com/beispiel/

Test:
mobil

Teststandort:
gleich

Datum:
gleiches Testfenster

VOR Änderung:
Messwerte notieren

Änderung:
Hero-Bild optimiert

NACH Änderung:
Messwerte erneut erfassen

Dadurch kannst du besser beurteilen, ob die konkrete Änderung tatsächlich eine messbare Verbesserung gebracht hat.

Nicht zehn Dinge gleichzeitig ändern #

Wenn du gleichzeitig Bilder komprimierst, Caching änderst, Plugins deaktivierst, JavaScript entfernst und die PHP-Version wechselst, kann die Website anschließend schneller sein – du weißt aber kaum noch, welche Maßnahme welchen Effekt hatte.

Für eine saubere Diagnose sind kontrollierte Änderungen besser.

Praxis-Tipp: Messen → eine nachvollziehbare Änderung durchführen → erneut messen. So erkennst du wesentlich besser, welche Optimierung tatsächlich wirkt.

Performance-Score und Ladezeit sind nicht dasselbe #

Viele Analysewerkzeuge berechnen aus mehreren Messwerten einen Score.

Ein solcher Score ist praktisch, um Ergebnisse schnell einzuordnen, aber er ist nicht identisch mit einer direkt gemessenen Ladezeit.

Ein Wert wie:

Performance: 92

bedeutet nicht:

Die Website ist zu 92 % schnell.

Der Score wird anhand einer bestimmten Methodik aus verschiedenen Messwerten berechnet.

Nicht ausschließlich auf 100 Punkte optimieren #

Ein perfekter Score kann ein motivierendes Ziel sein, sollte aber nicht zum Selbstzweck werden.

Eine Maßnahme kann theoretisch einen Messwert verbessern und gleichzeitig die tatsächliche Website verschlechtern – beispielsweise wenn ein wichtiges Bild sichtbar zu stark komprimiert wird oder eine benötigte Funktion entfernt wird.

Performance-Optimierung sollte deshalb immer technische Messwerte und die tatsächliche Nutzererfahrung gemeinsam berücksichtigen.

Warum können zwei Performance-Tools unterschiedliche Ergebnisse liefern? #

Unterschiedliche Werkzeuge können andere Teststandorte, Geräteprofile, Netzwerkbedingungen, Browser oder Berechnungsmethoden verwenden.

Deshalb solltest du die absoluten Zahlen verschiedener Dienste nicht unkritisch gegeneinander ausspielen.

Für Vorher-Nachher-Vergleiche ist es sinnvoll, möglichst dasselbe Werkzeug mit vergleichbaren Einstellungen zu verwenden.

Was bedeutet Wasserfallanalyse? #

Eine Wasserfall- beziehungsweise Waterfall-Ansicht zeigt, welche Ressourcen eine Seite lädt und wann die jeweiligen Anfragen beginnen beziehungsweise enden.

Vereinfacht:

HTML       ███████
CSS           ████
Font           █████
Bild 1          █████████
Bild 2             ███████
JavaScript       ███████████
API                      █████

Damit kannst du beispielsweise erkennen, ob eine große Bilddatei, ein externer Dienst oder eine andere Ressource besonders lange benötigt.

Die Anzahl der Requests allein ist kein Qualitätsmaß #

Eine Seite mit mehr HTTP-Anfragen ist nicht automatisch langsamer als eine Seite mit weniger Anfragen.

Größe, Priorität, Caching, Protokoll, Abhängigkeiten und Verarbeitung der Ressourcen spielen ebenfalls eine Rolle.

Eine reine Zielvorgabe wie „unter 50 Requests“ ist deshalb keine universelle Performance-Regel.

Die Gesamtgröße einer Seite richtig beurteilen #

Die übertragene Datenmenge ist ein nützlicher Hinweis, insbesondere bei bildlastigen Websites.

Sie sollte aber ebenfalls im Kontext betrachtet werden.

Eine Fotogalerie benötigt naturgemäß mehr Bilddaten als eine einfache Textseite.

Das Ziel ist nicht, jede Website auf dieselbe Gesamtgröße zu zwingen, sondern unnötige Datenübertragung zu vermeiden.

Wie Bilder effizient vorbereitet werden, erklären wir unter Bilder für das Web optimieren: Dateigröße, Format und SEO.

Externe Ressourcen können die Performance beeinflussen #

Websites laden häufig Inhalte von anderen Diensten.

Dazu können beispielsweise gehören:

Webfonts
Analyse-Dienste
Videos
Karten
Social-Media-Inhalte
Werbe- oder Tracking-Dienste
externe JavaScript-Bibliotheken

Die Antwortzeit dieser Ressourcen kontrollierst du nicht vollständig selbst.

Wenn ein externer Dienst langsam reagiert, kann sich das deshalb auf bestimmte Aspekte deiner Website auswirken.

Langsame Website bedeutet nicht automatisch langsames Hosting #

Wenn eine Website langsam wirkt, wird häufig sofort der Hosting-Server verantwortlich gemacht.

Das kann eine mögliche Ursache sein, ist aber längst nicht die einzige.

Eine Website kann beispielsweise durch große Bilder, aufwendige Datenbankabfragen, Plugins, Themes, JavaScript oder externe Dienste ausgebremst werden.

Umgekehrt kann eine ineffiziente Anwendung auch auf leistungsfähiger Infrastruktur langsam bleiben.

Wie du solche Ursachen systematisch eingrenzt, behandeln wir unter Langsame Website: Ursachen systematisch finden.

Serverzeit und Frontend-Zeit unterscheiden #

Für die Diagnose ist es hilfreich, grob zwischen der Erzeugung beziehungsweise Bereitstellung einer Antwort und der anschließenden Verarbeitung im Browser zu unterscheiden.

Server / Backend
→ Anfrage verarbeiten
→ HTML bereitstellen

Browser / Frontend
→ HTML analysieren
→ CSS verarbeiten
→ JavaScript ausführen
→ Bilder laden
→ Seite darstellen

Wenn der Server schnell antwortet, der Browser anschließend aber sehr große Ressourcen verarbeiten muss, kann die Seite trotzdem langsam wirken.

Umgekehrt kann ein schlankes Frontend durch eine sehr langsame serverseitige Verarbeitung ausgebremst werden.

Warum ein schnelles Internet beim Entwickler täuschen kann #

Wer eine Website über eine schnelle Glasfaserverbindung und einen leistungsfähigen Computer testet, erlebt möglicherweise kaum Verzögerungen.

Besucher können jedoch andere Bedingungen haben.

Deshalb sind simulierte mobile Testbedingungen und reale Nutzungsdaten hilfreich. Sie zeigen Aspekte, die beim eigenen Aufruf auf einem schnellen Arbeitsplatzrechner kaum auffallen.

Performance auf einem Smartphone selbst testen #

Neben automatisierten Werkzeugen lohnt sich ein echter Praxistest.

Öffne wichtige Seiten auf einem Smartphone und achte darauf, wie sich die Website tatsächlich verhält.

Beobachte beispielsweise:

Wann erscheint der Hauptinhalt?

Springt das Layout während des Ladens?

Kann ich schnell mit der Seite interagieren?

Erscheinen Bilder rechtzeitig?

Blockiert ein Cookie-Banner die Bedienung?

Reagiert die Navigation unmittelbar?

Solche Beobachtungen ersetzen keine technische Messung, ergänzen sie aber sinnvoll.

Website nicht nur im eingeloggten Zustand testen #

Content-Management-Systeme können sich für angemeldete Administratoren anders verhalten als für normale Besucher.

Caches können beispielsweise für eingeloggte Benutzer umgangen werden.

Teste deshalb die öffentliche Website zusätzlich in einem privaten Browserfenster, in dem du nicht im CMS angemeldet bist.

Messungen während Wartungsarbeiten vermeiden #

Wenn gerade Backups, Imports, Updates oder andere intensive Arbeiten laufen, können Messungen unter Umständen nicht repräsentativ sein.

Dasselbe gilt bei einer gerade frisch geleerten Cache-Struktur, wenn du eigentlich den normalen Besucherzustand beurteilen möchtest.

Dokumentiere deshalb bei wichtigen Vergleichen die Testbedingungen.

Was ist eine gute Ladezeit? #

Die Frage nach einer einzigen „guten Ladezeit“ ist zu allgemein.

Google definiert für die Core Web Vitals konkrete Schwellenwerte. Für LCP gilt beispielsweise eine Bewertung von bis zu 2,5 Sekunden beim 75. Perzentil als „gut“.

Das bedeutet jedoch nicht, dass jede andere denkbare Ladezeitkennzahl ebenfalls pauschal unter 2,5 Sekunden liegen muss.

Verschiedene Kennzahlen messen unterschiedliche Dinge.

Wichtig: Übertrage einen Grenzwert für eine bestimmte Performance-Kennzahl nicht einfach auf sämtliche anderen Ladezeitwerte.

Was bedeutet 75. Perzentil? #

Bei realen Nutzungsdaten werden nicht einfach nur einzelne Best- oder Durchschnittswerte betrachtet.

Das 75. Perzentil bedeutet vereinfacht, dass 75 Prozent der betrachteten Erfahrungen einen Wert erreichen, der gleich gut oder besser als dieser Grenzwert ist.

Dadurch werden nicht nur besonders schnelle Einzelaufrufe betrachtet.

Performance und SEO #

Website-Performance kann auch im Zusammenhang mit der Google-Suche relevant sein. Die Core Web Vitals sind Teil der von Google betrachteten Page-Experience-Signale.

Das bedeutet jedoch nicht, dass ein besserer Performance-Score automatisch zu einer bestimmten Rankingverbesserung führt.

Technische Performance sollte vor allem deshalb optimiert werden, weil eine schnelle und stabile Website für Besucher besser nutzbar ist.

Performance-Messung ist Diagnose, kein Wettbewerb #

Es ist wenig sinnvoll, ausschließlich einen Score mit einer völlig anderen Website zu vergleichen.

Ein einfacher Blog, ein komplexer Online-Shop und eine Webanwendung besitzen unterschiedliche Anforderungen.

Aussagekräftiger ist die Frage:

Wo liegen bei meiner Website konkrete Engpässe und welche davon kann ich sinnvoll verbessern?

Performance regelmäßig erneut prüfen #

Eine Website verändert sich.

Neue Plugins, Bilder, Tracking-Scripts, Fonts, Videos oder Funktionen können die Performance beeinflussen.

Deshalb ist eine Messung nicht für immer gültig.

Besonders nach größeren Änderungen lohnt sich eine erneute Kontrolle.

Wann sollte ich erneut messen? #

Eine erneute Performance-Messung ist besonders sinnvoll nach:

Website-Relaunch
Theme-Wechsel
größeren Plugin-Änderungen
neuen Tracking- oder Marketing-Scripts
Einbau großer Bilder oder Videos
Caching-Änderungen
Server- oder PHP-Änderungen
größeren Shop-Erweiterungen

Website-Erreichbarkeit ist etwas anderes als Performance #

Eine Website kann erreichbar sein und trotzdem langsam reagieren.

Umgekehrt misst ein Performance-Test nicht automatisch zuverlässig, ob eine Website rund um die Uhr verfügbar ist.

Für die kontinuierliche Überwachung der Erreichbarkeit werden Monitoring-Systeme eingesetzt.

Dieses Thema behandeln wir unter Website-Monitoring: Erreichbarkeit und Ausfälle überwachen.

Praktischer Ablauf für eine Performance-Messung #

repräsentative URL auswählen
        ↓
Testbedingungen festlegen
        ↓
mobil und Desktop prüfen
        ↓
mehrere Messungen durchführen
        ↓
Messwerte dokumentieren
        ↓
auffällige Ressourcen identifizieren
        ↓
eine konkrete Ursache untersuchen
        ↓
gezielte Änderung durchführen
        ↓
unter vergleichbaren Bedingungen erneut messen
        ↓
Ergebnis bewerten

Welche Werte sollte ich dokumentieren? #

Welche Daten sinnvoll sind, hängt vom verwendeten Werkzeug ab. Für einen reproduzierbaren Vergleich können beispielsweise folgende Informationen hilfreich sein:

getestete URL
Datum und Uhrzeit
Testwerkzeug
mobil oder Desktop
Teststandort, falls auswählbar
TTFB
FCP
LCP
weitere Core Web Vitals
übertragene Datenmenge
auffällige Ressourcen
durchgeführte Änderung

Damit kannst du spätere Messungen wesentlich besser einordnen.

Häufige Fehler beim Messen der Website-Geschwindigkeit #

nur einen einzigen Test durchführen

nur die Startseite testen

nur Desktop betrachten

unterschiedliche Tools direkt vergleichen

unterschiedliche Teststandorte ignorieren

Cache-Zustand nicht berücksichtigen

Performance-Score mit Sekunden verwechseln

nur auf 100 Punkte optimieren

mehrere Änderungen gleichzeitig durchführen

jede langsame Website sofort dem Hosting zuschreiben

Messwerte ohne tatsächliche Nutzererfahrung beurteilen

Checkliste für eine aussagekräftige Messung #

Welche URL möchte ich untersuchen?
        ↓
Welches Problem möchte ich messen?
        ↓
Sind die Testbedingungen vergleichbar?
        ↓
Mobil UND Desktop berücksichtigt?
        ↓
Mehrere Tests durchgeführt?
        ↓
Lab- und Field-Daten unterschieden?
        ↓
TTFB und Rendering getrennt betrachtet?
        ↓
auffällige Ressourcen geprüft?
        ↓
nur eine gezielte Änderung durchgeführt?
        ↓
erneut unter gleichen Bedingungen gemessen?
        ↓
tatsächliche Website zusätzlich selbst getestet?

Zusammenfassung #

Die Geschwindigkeit einer Website lässt sich nicht sinnvoll mit einer einzigen Zahl beschreiben. Beim Laden einer Seite spielen Serverantwort, Netzwerk, Browser, Bilder, CSS, JavaScript, externe Dienste und viele weitere Faktoren zusammen.

Messwerte wie TTFB, FCP und LCP betrachten unterschiedliche Abschnitte dieses Ablaufs. Lab-Daten entstehen unter kontrollierten Testbedingungen, während Field-Daten reale Nutzungserfahrungen abbilden.

Für aussagekräftige Vergleiche solltest du dieselbe URL unter möglichst vergleichbaren Bedingungen mehrfach testen und mobile sowie Desktop-Szenarien berücksichtigen.

Ein Performance-Score ist dabei eine hilfreiche Orientierung, aber kein Selbstzweck. Entscheidend ist, konkrete Engpässe zu identifizieren und anschließend zu prüfen, ob eine gezielte Optimierung tatsächlich eine Verbesserung bringt.

Gute Performance-Analyse bedeutet nicht, möglichst viele Zahlen zu sammeln. Sie bedeutet, unter vergleichbaren Bedingungen zu messen, die richtigen Kennzahlen zu verstehen und daraus die richtige technische Maßnahme abzuleiten.