Time to First Byte Die Antwortzeit des Servers entscheidet darüber, ob Arbeit am Frontend überhaupt wirkt
Time to First Byte misst die Zeit bis zum ersten Byte der Antwort. Der Wert zählt nicht zu den Core Web Vitals, ist aber ihre Wurzel: Er steckt als erster Abschnitt in jeder Ladezeit des Hauptinhalts und bildet die Untergrenze für alles, was danach kommt. In der eigenen Erhebung ist er der Grund, warum die Mehrheit der zu langsamen Auftritte zu langsam ist.
Orientierung: 800 MillisekundenEigene Zahlen: Stand August 2026
Woraus der Wert besteht
Bis zum ersten Byte passieren fünf Dinge: die Auflösung des Namens, der Aufbau der Verbindung, die Aushandlung der Verschlüsselung, mögliche Weiterleitungen und die Verarbeitung der Anfrage auf dem Server. Die ersten drei Schritte kosten auf einer gut eingerichteten Plattform zusammen selten mehr als hundert Millisekunden. Weiterleitungen sind ein häufiger, leicht behebbarer Posten: Jede Kette von Aufruf zu Ziel kostet eine volle Rundreise.
Der Löwenanteil entsteht im letzten Schritt, und dort entscheidet eine einzige Frage: Kommt die Antwort aus dem Zwischenspeicher oder aus der Anwendung. Ein Treffer im Cache kostet Millisekunden, ein Fehlschlag kostet die volle Verarbeitung samt Datenbank- und Repository-Zugriffen.
Warum der Wert über den Erfolg jeder Optimierung entscheidet
Die Schwelle für die Ladezeit des Hauptinhalts liegt bei 2,5 Sekunden. Wenn davon 1,5 Sekunden vergehen, bevor das erste Byte eintrifft, bleiben für Übertragung, Aufbau und Darstellung eine Sekunde. Das reicht auf einer Mobilverbindung nicht. Deshalb ist die Reihenfolge der Arbeit nicht verhandelbar: erst die Antwortzeit, dann das Frontend.
Die eigene Erhebung zeigt, wie häufig dieser Fall ist. Bei 80,3 Prozent der AEM-Auftritte mit zu langsamem Hauptinhalt liegt bereits die Antwortzeit über dem Grenzwert, bei Magnolia sind es 78,8 Prozent. Über alle gemessenen Auftritte liegt der Median bei 666 Millisekunden für AEM und 668 Millisekunden für Magnolia; bei den zu langsamen Auftritten steigt er auf 1.565 beziehungsweise 1.668 Millisekunden.
Die drei Muster, die die Trefferquote senken
- Parameter ohne eigene Seite. Kampagnen- und Tracking-Parameter erzeugen entweder eine eigene Cache-Variante oder umgehen den Cache ganz. Beides lässt sich in der Cache-Regel abfangen.
- Zu grobe Invalidierung. Verwirft jede Veröffentlichung große Teile des Zwischenspeichers, arbeitet die Plattform in redaktionsstarken Phasen faktisch ohne Cache.
- Sitzungen für anonyme Besucher. Wird für jeden Besuch eine Sitzung angelegt, ist jede Auslieferung individuell und damit nicht wiederverwendbar.
Alle drei sind messbar, und zwar als Trefferquote je Seitentyp im laufenden Betrieb. Diese Zahl gehört neben die Nutzerdaten, weil sie die Ursache zeigt, die jene nur als Wirkung ausweisen.
Was der Wert nicht löst
Eine niedrige Antwortzeit ergibt für sich genommen noch keine guten Core Web Vitals. Sie schafft den Raum dafür. Reaktionszeit und Layoutstabilität entstehen vollständig im Browser und bleiben von der Serverzeit unberührt. Ein häufiger Trugschluss in Migrationsprojekten lautet, mit dem Wechsel in eine Cloud-Umgebung seien die Werte erledigt; tatsächlich verbessert sich die Auslieferung, während dieselben Skripte, Tags und Personalisierungen im Browser dieselben Werte erzeugen wie vorher.
Zusammenhang mit den drei bewerteten Kennzahlen
Die Antwortzeit wirkt direkt auf die Ladezeit des Hauptinhalts und indirekt auf die Reaktionszeit, weil eine spät eintreffende Seite ihre Skripte später ausführt und damit häufiger mit frühen Eingaben kollidiert. Auf die Layoutstabilität wirkt sie nicht.
Wie sich die Werte im DACH-Raum verteilen und welche Datensätze dahinterstehen, steht im Core Web Vitals Benchmark. Die systemnahen Ursachen stehen auf den Seiten zu Adobe Experience Manager Performance und Magnolia CMS Performance.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie sehen, ob Ihre Werte im Betrieb oder im Frontend entstehen.
Häufige Fragen zu Time to First Byte
Was ist Time to First Byte?
Die Zeit zwischen dem Aufruf einer Seite und dem Eintreffen des ersten Byte der Antwort. Darin stecken Namensauflösung, Verbindungsaufbau, Verschlüsselung, Weiterleitungen und die Verarbeitungszeit auf dem Server. Google nennt 800 Millisekunden als Orientierung.
Ist Time to First Byte ein Core Web Vital?
Nein. Der Wert zählt nicht zu den drei bewerteten Kennzahlen, steckt aber als erster Abschnitt in jedem Largest Contentful Paint. Eine Seite mit 1,5 Sekunden Antwortzeit kann die Schwelle von 2,5 Sekunden praktisch nicht mehr halten, unabhängig davon, wie gut das Frontend arbeitet.
Wie hoch ist der Wert bei großen Plattformen im DACH-Raum?
Der Median liegt bei 666 Millisekunden für Adobe Experience Manager und 668 Millisekunden für Magnolia CMS. Bei den Auftritten, deren Hauptinhalt zu langsam lädt, liegt er dagegen bei 1.565 beziehungsweise 1.668 Millisekunden.
Hilft ein Content Delivery Network?
Für die Auslieferung ja, weil Wege kürzer werden und die Anwendung entlastet wird. Für die Verarbeitung im Browser nicht: Reaktionszeit und Layoutstabilität entstehen nach der Auslieferung und bleiben unberührt. Ein Content Delivery Network ist eine Grundlage, keine Maßnahme, die für sich genommen grüne Werte erzeugt.
Woran erkennt man, dass die Cache-Schicht das Problem ist?
An der Streuung. Ist der Wert für einzelne Seitentypen gut und für andere schlecht, trifft der Cache unterschiedlich. Typische Ursachen sind Anfragen mit Parametern, die eigene Varianten erzeugen, eine Invalidierung, die bei jeder Veröffentlichung zu viel verwirft, und Sitzungen, die für anonyme Besucher angelegt werden und jede Auslieferung individualisieren.