Eine Website-Antwortzeit von unter 200 ms bezeichnet bei btlabs Core die Time to First Byte (TTFB): die Zeit vom Beginn der Navigation bis zum Eintreffen des ersten Antwortbytes. Der Wert beschreibt weder die vollständige Ladezeit noch den Lighthouse-Score. Ohne Rohdaten zu Test-URL, Testregion, Cache-Zustand, Median und p95 ist „unter 200 ms“ jedoch kein allgemein belegtes Leistungsversprechen.
Diese Abgrenzung ist wichtig. In mehr als 20 Jahren Webentwicklung habe ich bei KMU oft gesehen, dass ein einzelner guter Messwert präsentiert wird, ohne die Messgröße und die Testbedingungen zu erklären. Ein Bestwert kann korrekt sein und trotzdem wenig darüber aussagen, wie stabil die Website-Antwortzeit im Alltag ist.
Eine belastbare Aussage zur Website-Geschwindigkeit braucht eine klare Messgröße, ein offenes Messprotokoll und Ergebnisse, die sich unter denselben Bedingungen reproduzieren lassen.
Was die Website-Antwortzeit tatsächlich misst
Die Time to First Byte misst laut web.dev die Zeit vom Beginn der Navigation bis zum Eintreffen des ersten Antwortbytes. In die TTFB fließen mehrere Phasen ein:
- mögliche Weiterleitungen,
- der Start eines Service Workers, falls vorhanden,
- die DNS-Auflösung,
- der Aufbau der Verbindung und die TLS-Verhandlung,
- die Übertragung der Anfrage und die Verarbeitung bis zum ersten Antwortbyte.
Die TTFB wird häufig verkürzt als Server-Antwortzeit einer Website bezeichnet. Die Bezeichnung ist nicht vollständig, weil auch Netzwerkphasen vor der eigentlichen Verarbeitung auf dem Server enthalten sind. Serverstandort, Routing und Entfernung zwischen Testregion und Rechenzentrum beeinflussen die Website-Antwortzeit ebenso wie die Anwendung selbst.
In diesem Beitrag bezeichnet „Antwortzeit“ deshalb konsequent die TTFB. Die Website-Reaktionszeit nach einem Klick innerhalb einer bereits geladenen Benutzeroberfläche ist eine andere Messgröße.
Website-Antwortzeit unter 200 ms richtig einordnen
web.dev nennt eine TTFB von höchstens 0,8 Sekunden beziehungsweise 800 ms als groben Richtwert für einen guten Wert. Mehr als 1,8 Sekunden gelten als schlecht; der Bereich dazwischen gilt als verbesserungsbedürftig. TTFB ist allerdings kein Core Web Vital. Die Schwellenwerte dienen daher als Orientierung und nicht als alleinige Bewertung der Nutzererfahrung.
Eine gemessene Website-Antwortzeit von unter 200 ms wäre ein sehr schneller Einzelwert. Daraus folgt jedoch keine Garantie, dass jede URL, jeder Aufruf und jede Region dauerhaft unter 200 ms bleibt. Dynamische Funktionen, personalisierte Inhalte, ein Cache Miss oder eine hohe Serverauslastung können zu anderen Ergebnissen führen.
Für btlabs Core liegt in den bereitgestellten Unterlagen kein vollständiger Rohdatensatz mit Testdatum, Einzelmessungen, Median und p95 vor. Deshalb ist „unter 200 ms“ hier als zu prüfende Leistungsangabe und nicht als abschließend dokumentiertes Messergebnis eingeordnet. Ein belastbarer Nachweis setzt die Veröffentlichung einer vollständigen Messreihe voraus.
TTFB, Ladezeit, LCP und Lighthouse-Score unterscheiden
TTFB: Wann beginnt die Antwort?
TTFB endet, sobald das erste Antwortbyte eintrifft. Zu diesem Zeitpunkt können Bilder, Schriften, Stylesheets und JavaScript-Dateien noch fehlen. Eine niedrige TTFB schafft gute Voraussetzungen, belegt aber nicht, dass die gesamte Seite bereits sichtbar oder bedienbar ist.
Vollständige Ladezeit: Wann endet der Ladevorgang?
Die vollständige Ladezeit ist keine einzelne, überall identisch definierte Leistungskennzahl. Je nach Werkzeug kann sie sich auf das Ladeereignis oder auf einen späteren Zeitpunkt mit geringer Netzwerkaktivität beziehen. Medien, Schriften, Skripte und externe Dienste können den Ladevorgang verlängern, obwohl das erste HTML-Byte bereits eingetroffen ist.
Largest Contentful Paint: Wann erscheint der größte sichtbare Inhalt?
Der Largest Contentful Paint (LCP) misst laut web.dev die Renderzeit des größten sichtbaren Bildes, Textblocks oder Videos im Darstellungsbereich. Der LCP gehört zu den Core Web Vitals und wird relativ zum Beginn der Navigation ermittelt.
TTFB und LCP messen unterschiedliche Zeitpunkte, sind aber miteinander verbunden: Verzögerungen bis zum ersten Byte sind Teil der gesamten LCP-Zeit. Eine langsame TTFB kann den LCP verschlechtern. Eine schnelle TTFB garantiert dagegen keinen guten LCP, wenn beispielsweise das zentrale Titelbild zu groß ist oder erst spät angefordert wird.
Lighthouse-Score: Wie wird die Gesamtleistung bewertet?
Der Lighthouse-Performance-Score ist laut Chrome for Developers ein gewichteter Durchschnitt mehrerer Metrik-Scores. Im dokumentierten Bewertungsmodell fließen unter anderem First Contentful Paint, Speed Index, Largest Contentful Paint, Total Blocking Time und Cumulative Layout Shift ein. Die Gewichtungen können sich mit neuen Lighthouse-Versionen ändern.
Der Lighthouse-Score ist deshalb nicht mit der Server-Antwortzeit einer Website gleichzusetzen. Eine Website kann eine schnelle TTFB und trotzdem einen mäßigen Lighthouse-Score haben. Umgekehrt kann ein guter Lighthouse-Labortest regionale oder sporadische Schwächen der Website-Antwortzeit überdecken.
Messprotokoll für eine reproduzierbare Messung
Eine reproduzierbare Messung setzt identische Bedingungen voraus. Für btlabs Core und jede andere Website sollte das Messprotokoll mindestens folgende Angaben enthalten:
- Testgegenstand: vollständige Domain und konkrete URL,
- Seitentyp: Startseite, Inhaltsseite, Suchseite oder dynamische Funktion,
- Antwort: HTTP-Status und mögliche Weiterleitungskette,
- Zeitpunkt: Datum, Uhrzeit und Zeitzone der Messreihe,
- Werkzeug: Name und Version des Messwerkzeugs,
- Testregion: beispielsweise Norditalien oder Mitteleuropa,
- Verbindung: festgelegtes Netzwerkprofil,
- Cache-Zustand: Cold Cache und Warm Cache getrennt,
- Stichprobe: Anzahl der Aufwärmläufe und ausgewerteten Messungen,
- Ergebnisse: Einzelwerte, Median und p95,
- Kontext: Serverstandort, CDN-Nutzung und dynamische Funktionen.
Für den Nachweis einer Website-Antwortzeit von unter 200 ms muss eine feste öffentliche btlabs-Core-URL definiert werden. Zusätzlich sollten mehrere typische Inhaltsseiten in die Messung einfließen. Nur die schnellste URL zu veröffentlichen, würde kein repräsentatives Bild des Systems liefern.
Cold Cache und Warm Cache getrennt messen
Ein Cold Cache bedeutet, dass die angeforderte Antwort noch nicht aus einem vorbereiteten Zwischenspeicher geliefert werden kann. Die Anwendung muss Inhalte möglicherweise aus einer Datenquelle lesen und neu aufbereiten. Das führt typischerweise zu einem Cache Miss.
Beim Warm Cache liegt die Antwort oder ein wesentlicher Teil davon bereits im Cache. Ein Cache Hit kann die TTFB deutlich reduzieren. Beide Zustände beantworten unterschiedliche Fragen:
- Der Cold-Cache-Test zeigt die Leistung, wenn Inhalte neu verarbeitet werden müssen.
- Der Warm-Cache-Test zeigt die Auslieferung häufig angefragter Inhalte.
- Das Verhältnis von Cache Hit zu Cache Miss zeigt, wie oft Nutzer von der zwischengespeicherten Antwort profitieren.
Cold Cache und Warm Cache in einem Durchschnitt zu vermischen, erschwert die Einordnung. Ein transparenter Bericht weist beide Messreihen getrennt aus und dokumentiert, wie der jeweilige Zustand hergestellt wurde.
Median und p95 statt einzelner Bestwerte
Der Median ist der mittlere Wert einer sortierten Messreihe: Die Hälfte der Messungen liegt darunter, die andere Hälfte darüber. Der Median reagiert weniger empfindlich auf einzelne Ausreißer als ein arithmetischer Durchschnitt.
Der p95-Wert ist das 95. Perzentil. 95 Prozent der Messungen sind gleich schnell oder schneller; fünf Prozent liegen darüber. Der p95 zeigt, wie sich die Website-Antwortzeit unter ungünstigeren, aber regelmäßig auftretenden Bedingungen verhält.
Für ein KMU sind beide Kennzahlen relevant. Der Median beschreibt den typischen Fall. Der p95 zeigt, ob ein System stabil bleibt oder ein Teil der Besucher deutlich länger wartet. Ein Einzelwert unter 200 ms belegt nur, dass diese Geschwindigkeit einmal erreicht wurde. Erst Median und p95 zeigen, wie wiederholbar die Leistung ist.
Welche Architektur eine schnelle TTFB unterstützt
Eine schnelle Website entsteht nicht durch eine einzelne Optimierung. Entscheidend ist eine Architektur, die unnötige Verarbeitung und Übertragung vermeidet:
- Schlankes Frontend: Weniger unnötiger Code reduziert Datenmenge und Verarbeitung im Browser.
- Serverseitige Verarbeitung: Vorbereitete Inhalte können früher ausgeliefert werden als Inhalte, die erst vollständig im Browser entstehen.
- Gezieltes Caching: Wiederkehrende Anfragen müssen nicht jedes Mal neu verarbeitet werden.
- Kurze Weiterleitungsketten: Jede zusätzliche Weiterleitung erzeugt einen weiteren Netzwerkschritt.
- Optimierte Medienauslieferung: Passende Formate und Größen verbessern vor allem LCP und vollständige Ladezeit.
- Wenige Drittanbieter-Skripte: Externe Dienste erhöhen Abhängigkeiten und können Rendering sowie Interaktivität verzögern.
btlabs Core ist als zentrales digitales Fundament konzipiert, aus dem Websites und weitere Ausgabekanäle auf eine gemeinsame Inhaltsbasis zugreifen. Die technischen Hintergründe erläutere ich im Beitrag über die Architektur von btlabs Core. Eine geeignete Architektur schafft gute Voraussetzungen, ersetzt aber keine Messung unter realen Bedingungen.
Was die Website-Antwortzeit beeinflusst
Selbst bei unverändertem Code kann die Server-Antwortzeit einer Website schwanken. Typische Ursachen sind:
- die Entfernung zwischen Testregion und Serverstandort,
- das Routing des Netzbetreibers,
- die aktuelle Auslastung von Hosting, Datenbank oder Anwendung,
- ein Cache Hit oder Cache Miss,
- personalisierte Inhalte und angemeldete Nutzer,
- dynamische Such-, Buchungs- oder Shop-Funktionen,
- externe Schnittstellen und Drittanbieter-Skripte,
- eine instabile lokale Netzverbindung.
Für Unternehmen in Südtirol sind Messungen aus einer relevanten mitteleuropäischen Testregion sinnvoll. Richtet sich eine Website an Menschen in Italien und im DACH-Raum, sollten zusätzliche Messreihen aus beiden Zielgebieten erfolgen. Ein Test aus einem Rechenzentrum nahe am Server bildet die Erfahrung weiter entfernter Nutzer nicht zuverlässig ab.
So prüfst Du die Website-Antwortzeit
Für einen belastbaren Vergleich brauchst Du vor allem ein einheitliches Vorgehen:
- Wähle drei bis fünf repräsentative öffentliche URLs.
- Notiere HTTP-Status und Weiterleitungen jeder URL.
- Lege ein Messwerkzeug und eine feste Testregion fest.
- Führe mehrere Aufwärmläufe durch, die nicht in die Auswertung einfließen.
- Erfasse danach mindestens 20 Messungen pro URL und Cache-Zustand.
- Trenne Cold Cache und Warm Cache konsequent.
- Speichere die Einzelwerte und berechne Median sowie p95.
- Wiederhole die Messung zu einem zweiten Zeitpunkt.
- Vergleiche Systeme nur unter denselben Testbedingungen.
Prüfe anschließend nicht nur die TTFB, sondern die gesamte Website-Performance. Für die wahrgenommene Qualität zählen zusätzlich sichtbarer Inhalt, visuelle Stabilität, Interaktivität und eine klare Nutzerführung.
Nach dem Launch legt ein Performance Budget für KMU-Websites Grenzwerte für Bilder, Skripte und zentrale Leistungskennzahlen fest. Dadurch bleibt Geschwindigkeit eine laufende Qualitätsanforderung.
Warum dieser Beitrag keinen Vorher-Nachher-Vergleich enthält
Ein Vorher-Nachher-Vergleich ist nur aussagekräftig, wenn beide Systeme mit vergleichbaren Inhalten und Funktionen, derselben Testregion, demselben Werkzeug und getrennten Cache-Zuständen gemessen werden. Solche gleichartig erhobenen Vergleichsdaten liegen in den bereitgestellten Unterlagen nicht vor.
Ich verzichte deshalb auf konstruierte oder methodisch ungleiche Vergleichswerte. In der Arbeit mit KMU ist ein klar benannter fehlender Datensatz hilfreicher als eine eindrucksvolle Zahl ohne prüfbare Grundlage.
Welche Daten ein btlabs-Core-Messbericht enthalten muss
Damit „unter 200 ms“ als dokumentierte Website-Antwortzeit gelten kann, muss der Messbericht folgende Daten offenlegen:
- getestete Domain und konkrete Test-URLs,
- Datum und Uhrzeit der Messung,
- Werkzeug, Version und Testregion,
- Serverstandort und relevante Infrastruktur,
- Anzahl der Aufwärmläufe und Messungen,
- Cold-Cache- und Warm-Cache-Ergebnisse,
- Median und p95 je URL und Cache-Zustand,
- Rohwerte oder einen exportierbaren Messbericht,
- Ausreißer mit nachvollziehbarer Einordnung.
Redaktioneller Stand: 25. März 2026. Infrastruktur, Inhalte und externe Dienste können sich ändern. Eine veröffentlichte Messreihe benötigt deshalb ein Aktualisierungsdatum und sollte nach wesentlichen Änderungen wiederholt werden.
Fragen und Antworten zur Website-Antwortzeit
Was ist ein guter TTFB-Wert für eine Website?
web.dev nennt höchstens 800 ms als groben Richtwert für eine gute TTFB. Für ein konkretes KMU-Projekt berücksichtige ich zusätzlich Median, p95, Zielregion und Seitentyp, weil ein einzelner Grenzwert die Nutzererfahrung nicht vollständig abbildet.
Bedeutet eine TTFB unter 200 ms, dass die Website in 200 ms geladen ist?
Nein. Unter 200 ms bedeutet nur, dass das erste Antwortbyte innerhalb dieses Zeitraums eingetroffen ist. Bilder, Schriften, JavaScript und sichtbare Inhalte können danach noch geladen und gerendert werden.
Warum ist der Warm Cache schneller als der Cold Cache?
Beim Warm Cache können vorbereitete Daten oder Antworten direkt ausgeliefert werden, was häufig zu einem Cache Hit führt. Beim Cold Cache muss das System Inhalte möglicherweise neu erzeugen. Deshalb müssen beide Zustände getrennt gemessen werden.
Warum zeigt Lighthouse einen anderen Wert als ein TTFB-Test?
Lighthouse bewertet mehrere gewichtete Leistungsmetriken unter festgelegten Laborbedingungen. Ein TTFB-Test betrachtet dagegen nur den Zeitraum bis zum ersten Antwortbyte. Beide Messungen beantworten unterschiedliche Fragen.
Ist TTFB ein Core Web Vital?
Nein, TTFB gehört nicht zu den Core Web Vitals. Die Kennzahl beeinflusst jedoch nachgelagerte Ladephasen und kann dadurch den Largest Contentful Paint verzögern.
Soll ich die TTFB mobil oder am Desktop messen?
Für vergleichbare Messreihen solltest Du feste und dokumentierte Bedingungen verwenden. Ergänzende mobile Tests sind sinnvoll, weil Mobilfunk, schwächere Geräte und wechselnde Netzqualität die reale Nutzererfahrung beeinflussen.
Wie viele Messungen brauche ich?
Ein einzelner Test reicht nicht für eine belastbare Aussage. Für einen pragmatischen KMU-Check empfehle ich nach mehreren Aufwärmläufen mindestens 20 ausgewertete Messungen pro URL und Cache-Zustand sowie die Auswertung von Median und p95.
Kann ich zwei Website-Systeme direkt vergleichen?
Ja, sofern Inhalte und Funktionen vergleichbar sind und Testregion, Werkzeug, Anzahl der Messungen sowie Cache-Zustände übereinstimmen. Der Vergleich einer einfachen Startseite mit einer personalisierten Shop-Seite wäre methodisch nicht belastbar.
Garantiert btlabs Core dauerhaft eine Website-Antwortzeit unter 200 ms?
Nein. Aus einer einzelnen Messung lässt sich keine dauerhafte Garantie für jede URL, Region und Funktion ableiten. Die Angabe kann erst mit einem vollständigen Messprotokoll, Rohwerten, Median und p95 als belegtes Ergebnis gelten.
Fazit: Website-Antwortzeit nachvollziehbar bewerten
Eine niedrige TTFB ist wertvoll, weil nachgelagerte Ladephasen erst nach Beginn der Antwort fortschreiten können. Die Website-Antwortzeit ist jedoch nur ein Teil der Website-Qualität. Für Dein Unternehmen zählen zusätzlich eine stabile Auslieferung, schnell sichtbare Inhalte, verständliche Nutzerführung und ein langfristig beherrschbares System.
Bei btlabs Core sollte „unter 200 ms“ deshalb nicht als isolierter Bestwert stehen. Notwendig ist eine dokumentierte Messreihe mit relevanten Testregionen, getrenntem Cold Cache und Warm Cache, Median, p95 und zugänglichen Rohdaten. So wird aus einer Leistungsangabe eine nachvollziehbare Messung.
