Informationen zum Optimieren des Messwerts „Time to First Byte“
Veröffentlicht: 19. Januar 2023, zuletzt aktualisiert: 28. November 2025
Time to First Byte (TTFB) ist ein grundlegender Messwert für die Webleistung, der allen anderen wichtigen Messwerten für die Nutzererfahrung wie First Contentful Paint (FCP) und Largest Contentful Paint (LCP) vorausgeht. Das bedeutet, dass hohe TTFB-Werte die nachfolgenden Messwerte erhöhen.
Es wird empfohlen, dass Ihr Server schnell genug auf Navigationsanfragen reagiert, damit das 75. Perzentil der Nutzer einen FCP innerhalb des „guten“ Schwellenwerts erlebt. Als grober Richtwert gilt, dass die meisten Websites eine TTFB von höchstens 0,8 Sekunden anstreben sollten.
TTFB messen
Bevor Sie die TTFB optimieren können, müssen Sie beobachten, wie sie sich auf die Nutzer Ihrer Website auswirkt. Sie sollten sich auf Felddaten als primäre Quelle für die Beobachtung der TTFB verlassen, da sie von Weiterleitungen beeinflusst wird. Labortools messen dagegen oft die endgültige URL und berücksichtigen diese zusätzliche Verzögerung daher nicht.
PageSpeed Insights ist eine Möglichkeit, sowohl Felddaten als auch Labordaten für öffentliche Websites zu erhalten, die im Chrome User Experience Report verfügbar sind.
Die TTFB für echte Nutzer wird oben im Abschnitt Erfahren Sie, was Ihre echten Nutzer erleben angezeigt:
Bei Labdaten werden TTFB-Probleme im Insight Latenz bei Dokumentanfragen angezeigt:
Weitere Möglichkeiten zum Messen der TTFB sowohl im Feld als auch im Labor finden Sie auf der Seite zum TTFB-Messwert.
Unterschiede zwischen Feld- und Labor-TTFB verstehen
Die TTFB im Labor und im Feld kann sich aus verschiedenen Gründen unterscheiden. Wenn dies der Fall ist, ist es wichtig, die Gründe dafür zu kennen, um die Labordaten effektiv zur Verbesserung der Nutzerfreundlichkeit einsetzen zu können.
Wenn die TTFB im Lab viel größer ist als die TTFB im Feld, deutet dies darauf hin, dass die Lab-Umgebung stärker eingeschränkt ist als die typische Nutzererfahrung. Das ist nicht unbedingt ein Problem, da die Laborergebnisse und Empfehlungen weiterhin gültig sind. Die Auswirkungen und die Verbesserung können jedoch übertrieben dargestellt werden.
Wenn die TTFB im Feld viel größer ist als die TTFB im Labor, deutet dies auf Probleme hin, die im Laborlauf nicht sichtbar sind, z. B. die Verwendung von serverseitigem Caching, Weiterleitungen oder Netzwerkunterschiede. In diesem Fall sind die Laborergebnisse und Empfehlungen möglicherweise weniger nützlich, da eines der Hauptprobleme fehlt.
Wenn du herausfinden möchtest, ob sich das serverseitige Caching auf die TTFB im Labor auswirkt, kannst du weniger häufig aufgerufene Seiten testen oder andere URL-Parameter verwenden, um nicht im Cache gespeicherte Inhalte abzurufen. So kannst du feststellen, ob die TTFB im Labor eher der TTFB im Feld entspricht. Es kann auch nützlich sein, das serverseitige Caching mit einem bestimmten URL-Parameter umgehen zu können. Weitere Informationen finden Sie im Abschnitt zu im Cache gespeicherten Inhalten.
Bei Weiterleitungen und Netzwerkunterschieden können Analysen dazu, wie und woher der Traffic auf Ihre Website gelangt, hilfreich sein, um festzustellen, ob es sich um potenzielle Probleme handelt.
Hohe TTFB-Werte im Feld mit Server-Timing beheben
Der Antwortheader Server-Timing kann im Backend Ihrer Anwendung verwendet werden, um verschiedene Backend-Prozesse zu messen, die zu einer hohen Latenz beitragen könnten. Die Struktur des Headerwerts ist flexibel und akzeptiert mindestens ein von Ihnen definiertes Handle. Optionale Werte sind ein Dauerwert (über dur) sowie eine optionale menschenlesbare Beschreibung (über desc).
Serving-Timing kann verwendet werden, um viele Backend-Prozesse von Anwendungen zu messen. Einige davon sollten Sie jedoch besonders im Auge behalten:
- Datenbankabfragen
- Gegebenenfalls die serverseitige Renderingzeit
- Datenträger-Suchvorgänge
- Cache-Treffer oder -Fehler auf Edge-Servern (bei Verwendung eines CDN)
Alle Teile eines Server-Timing-Eintrags sind durch Doppelpunkte getrennt. Mehrere Einträge können durch ein Komma getrennt werden:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
Der Header kann in der Sprache Ihrer Wahl für das Anwendungs-Backend festgelegt werden. In PHP können Sie den Header beispielsweise so festlegen:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
Wenn dieser Header festgelegt ist, werden Informationen angezeigt, die Sie sowohl im Labor als auch im Feld verwenden können.
In der Praxis wird für jede Seite mit einem festgelegten Server-Timing-Antwortheader das Attribut serverTiming in der Navigation Timing API ausgefüllt:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
Im Lab werden die Daten aus dem Antwortheader Server-Timing im Bereich Timings des Tabs Netzwerk in den Chrome-Entwicklertools visualisiert:
Hier wird Server-Timing verwendet, um zu messen, ob eine Anfrage für eine Ressource den CDN-Cache erreicht hat und wie lange es dauert, bis die Anfrage den Edge-Server des CDN und dann den Ursprung erreicht.
Server-Timings werden auch im Bereich „Netzwerk“ des Bereichs Leistung in den Chrome-Entwicklertools angezeigt:
Wenn Sie anhand der verfügbaren Daten festgestellt haben, dass die TTFB problematisch ist, können Sie mit der Behebung des Problems beginnen.
Möglichkeiten zur Optimierung der TTFB
Der schwierigste Aspekt bei der Optimierung der TTFB ist, dass der Frontend-Stack des Webs zwar immer HTML, CSS und JavaScript ist, die Backend-Stacks jedoch erheblich variieren können. Es gibt zahlreiche Backend-Stacks und Datenbankprodukte, die jeweils eigene Optimierungstechniken haben. Daher konzentriert sich dieser Leitfaden auf das, was für die meisten Architekturen gilt, und nicht nur auf Stack-spezifische Anleitungen.
Plattformspezifische Anleitung
Die Plattform, die Sie für Ihre Website verwenden, kann die TTFB stark beeinflussen. Die Leistung von WordPress wird beispielsweise durch die Anzahl und Qualität der Plug-ins oder die verwendeten Themes beeinflusst. Andere Plattformen sind ähnlich betroffen, wenn die Plattform angepasst wird. In der Dokumentation Ihrer Plattform finden Sie anbieterspezifische Hinweise, die die allgemeineren Leistungshinweise in diesem Beitrag ergänzen. Die Lighthouse-Statistik enthält auch einige eingeschränkte Stack-spezifische Hinweise.
Hosting, Hosting, Hosting
Bevor Sie andere Optimierungsansätze in Betracht ziehen, sollten Sie sich zuerst mit dem Hosting befassen. Es gibt hier keine spezifischen Empfehlungen, aber als allgemeine Faustregel gilt, dass der Host Ihrer Website in der Lage sein muss, den Traffic zu bewältigen, den Sie an ihn senden.
Shared Hosting ist im Allgemeinen langsamer. Wenn Sie eine kleine persönliche Website betreiben, auf der hauptsächlich statische Dateien bereitgestellt werden, ist das wahrscheinlich in Ordnung. Mit den folgenden Optimierungstechniken können Sie die TTFB so weit wie möglich reduzieren.
Wenn Sie jedoch eine größere Anwendung mit vielen Nutzern ausführen, die Personalisierung, Datenbankabfragen und andere intensive serverseitige Vorgänge umfasst, ist die Wahl des Hostings entscheidend, um die TTFB in der Praxis zu senken.
Bei der Auswahl eines Hostanbieters sollten Sie auf Folgendes achten:
- Wie viel Arbeitsspeicher ist Ihrer Anwendungsinstanz zugewiesen? Wenn Ihre Anwendung nicht genügend Arbeitsspeicher hat, wird sie überlastet und kann Seiten nicht so schnell wie möglich bereitstellen.
- Hält Ihr Hostanbieter Ihren Backend-Stack auf dem neuesten Stand? Wenn neue Versionen von Anwendungs-Backend-Sprachen, HTTP-Implementierungen und Datenbanksoftware veröffentlicht werden, verbessert sich die Leistung dieser Software im Laufe der Zeit. Es ist wichtig, mit einem Hostanbieter zusammenzuarbeiten, der diese Art von wichtiger Wartung priorisiert.
- Wenn Sie sehr spezifische Anwendungsanforderungen haben und Zugriff auf die Serverkonfigurationsdateien auf der niedrigsten Ebene benötigen, sollten Sie sich fragen, ob es sinnvoll ist, das Backend Ihrer eigenen Anwendungsinstanz anzupassen.
Es gibt viele Hostanbieter, die sich um diese Dinge kümmern. Wenn Sie jedoch auch bei dedizierten Hostanbietern lange TTFB-Werte feststellen, ist es möglicherweise an der Zeit, die Funktionen Ihres aktuellen Hostanbieters neu zu bewerten, damit Sie die bestmögliche Nutzererfahrung bieten können.
Content Delivery Network (CDN) verwenden
Das Thema CDN-Nutzung ist ein altbekanntes, aber aus gutem Grund: Sie können ein sehr gut optimiertes Anwendungs-Backend haben, aber Nutzer, die weit von Ihrem Ursprungsserver entfernt sind, können in der Praxis immer noch eine hohe TTFB haben.
CDNs lösen das Problem der Nutzerentfernung von Ihrem Ursprungsserver, indem sie ein verteiltes Netzwerk von Servern verwenden, die Ressourcen auf Servern im Cache speichern, die sich physisch näher an Ihren Nutzern befinden. Diese Server werden als Edge-Server bezeichnet.
CDN-Anbieter bieten möglicherweise auch Vorteile, die über Edge-Server hinausgehen:
- CDN-Anbieter bieten in der Regel extrem schnelle DNS-Auflösungszeiten.
- Ein CDN stellt Ihre Inhalte wahrscheinlich über Edge-Server mit modernen Protokollen wie HTTP/2 oder HTTP/3 bereit.
- HTTP/3 löst insbesondere das Head-of-Line-Blocking-Problem, das in TCP (auf dem HTTP/2 basiert) auftritt, durch die Verwendung des UDP-Protokolls.
- Ein CDN bietet wahrscheinlich moderne TLS-Versionen, was die Latenz bei der TLS-Aushandlung verringert. Insbesondere TLS 1.3 ist so konzipiert, dass die TLS-Aushandlung so kurz wie möglich gehalten wird.
- Einige CDN-Anbieter bieten eine Funktion, die oft als „Edge Worker“ bezeichnet wird. Dabei wird eine API verwendet, die der Service Worker API ähnelt, um Anfragen abzufangen, Antworten in Edge-Caches programmatisch zu verwalten oder Antworten vollständig umzuschreiben.
- CDN-Anbieter sind sehr gut darin, die Komprimierung zu optimieren. Die Komprimierung ist schwierig, wenn Sie sie selbst vornehmen, und kann in bestimmten Fällen mit dynamisch generiertem Markup, das im laufenden Betrieb komprimiert werden muss, zu langsameren Antwortzeiten führen.
- Außerdem speichern CDN-Anbieter komprimierte Antworten für statische Ressourcen automatisch im Cache, was zu einer optimalen Kombination aus Komprimierungsverhältnis und Antwortzeit führt.
Die Einführung eines CDN ist mit unterschiedlich hohem Aufwand verbunden, der von geringfügig bis erheblich reichen kann. Wenn Sie noch kein CDN verwenden, sollten Sie es jedoch mit hoher Priorität in Betracht ziehen, um die TTFB zu optimieren.
Nach Möglichkeit im Cache gespeicherte Inhalte verwenden
CDNs ermöglichen das Caching von Inhalten auf Edge-Servern, die sich physisch näher an den Besuchern befinden, sofern die Inhalte mit den entsprechenden Cache-Control-HTTP-Headern konfiguriert sind. Dies ist zwar nicht für personalisierte Inhalte geeignet, aber wenn eine Anfrage bis zum Ursprung zurückgeleitet werden muss, kann dies einen Großteil des Werts eines CDN zunichtemachen.
Bei Websites, deren Inhalte häufig aktualisiert werden, kann selbst eine kurze Caching-Zeit zu spürbaren Leistungssteigerungen führen, da nur der erste Besucher während dieser Zeit die volle Latenz bis zum Ursprungsserver erfährt, während alle anderen Besucher die im Cache gespeicherte Ressource vom Edge-Server wiederverwenden können. Einige CDNs ermöglichen die Cache-Entwertung bei Website-Releases, sodass Sie das Beste aus beiden Welten erhalten: lange Cache-Zeiten, aber sofortige Aktualisierungen bei Bedarf.
Selbst wenn das Caching korrekt konfiguriert ist, kann dies durch die Verwendung eindeutiger Abfragestring-Parameter für die Analysemessung ignoriert werden. Diese können für das CDN wie unterschiedliche Inhalte aussehen, obwohl sie identisch sind. Daher wird die im Cache gespeicherte Version nicht verwendet.
Ältere oder weniger besuchte Inhalte werden möglicherweise auch nicht im Cache gespeichert, was auf einigen Seiten zu höheren TTFB-Werten als auf anderen führen kann. Durch längere Caching-Zeiten können die Auswirkungen verringert werden. Beachten Sie jedoch, dass längere Caching-Zeiten die Wahrscheinlichkeit erhöhen, dass potenziell veraltete Inhalte bereitgestellt werden.
Die Auswirkungen von im Cache gespeicherten Inhalten betreffen nicht nur diejenigen, die CDNs verwenden. Die Serverinfrastruktur muss möglicherweise Inhalte aus kostspieligen Datenbankabfragen generieren, wenn im Cache gespeicherte Inhalte nicht wiederverwendet werden können. Daten, auf die häufiger zugegriffen wird, oder im Cache gespeicherte Seiten können oft eine bessere Leistung erzielen.
Mehrfache Seitenweiterleitungen vermeiden
Ein häufiger Grund für eine hohe TTFB sind Weiterleitungen. Weiterleitungen erfolgen, wenn eine Navigationsanfrage für ein Dokument eine Antwort erhält, die den Browser darüber informiert, dass die Ressource an einem anderen Ort vorhanden ist. Eine Weiterleitung kann die Latenz einer Navigationsanfrage erhöhen. Es kann aber noch schlimmer werden, wenn diese Weiterleitung auf eine andere Ressource verweist, die zu einer weiteren Weiterleitung führt usw. Dies kann sich insbesondere auf Websites auswirken, die viele Besucher über Anzeigen oder Newsletter erhalten, da diese zu Analysezwecken häufig über Analysedienste weitergeleitet werden. Wenn Sie Weiterleitungen, die Sie direkt steuern können, entfernen, kann das zu einer guten TTFB beitragen.
Es gibt zwei Arten von Weiterleitungen:
- Weiterleitungen innerhalb desselben Ursprungs, bei denen die Weiterleitung vollständig auf Ihrer Website erfolgt.
- Ursprungsübergreifende Weiterleitungen, bei denen die Weiterleitung zuerst auf einem anderen Ursprung erfolgt, z. B. über einen URL-Kürzungsdienst für soziale Medien, bevor die Nutzer auf Ihre Website gelangen.
Konzentrieren Sie sich darauf, Weiterleitungen mit demselben Ursprung zu vermeiden, da Sie diese direkt beeinflussen können. Dazu müssen Sie die Links auf Ihrer Website prüfen, um festzustellen, ob einer davon den Antwortcode 302 oder 301 zurückgibt. Häufig liegt das daran, dass das Schema https:// nicht angegeben wurde (Browser verwenden dann standardmäßig http://, was zu einer Weiterleitung führt) oder dass abschließende Schrägstriche in der URL nicht richtig angegeben oder ausgeschlossen wurden.
Ursprungsübergreifende Weiterleitungen sind schwieriger, da sie oft außerhalb Ihrer Kontrolle liegen. Versuchen Sie jedoch, mehrere Weiterleitungen nach Möglichkeit zu vermeiden, z. B. durch die Verwendung mehrerer Linkverkürzer beim Teilen von Links. Achten Sie darauf, dass die URL, die Sie Werbetreibenden oder Newslettern zur Verfügung stellen, die richtige finale URL ist, damit keine weitere Weiterleitung zu den von diesen Diensten verwendeten Weiterleitungen hinzugefügt wird.
Eine weitere wichtige Quelle für Weiterleitungszeit können HTTP-zu-HTTPS-Weiterleitungen sein. Eine Möglichkeit, dies zu umgehen, ist die Verwendung des Strict-Transport-Security-Headers (HSTS). Dadurch wird HTTPS beim ersten Besuch eines Ursprungs erzwungen und der Browser angewiesen, bei zukünftigen Besuchen sofort über das HTTPS-Schema auf den Ursprung zuzugreifen.
Sobald Sie eine gute HSTS-Richtlinie eingerichtet haben, können Sie den ersten Besuch eines Ursprungs beschleunigen, indem Sie Ihre Website der HSTS-Preload-Liste hinzufügen.
Markup an den Browser streamen
Browser sind so optimiert, dass sie Markup effizient verarbeiten, wenn es gestreamt wird. Das bedeutet, dass Markup in Blöcken verarbeitet wird, sobald es vom Server eintrifft. Das ist besonders bei großen Markup-Nutzlasten wichtig, da der Browser die Markup-Blöcke so schrittweise parsen kann, anstatt auf die gesamte Antwort zu warten, bevor er mit dem Parsen beginnt.
Browser sind zwar gut darin, Streaming-Markup zu verarbeiten, aber es ist wichtig, dass Sie alles tun, um den Stream am Laufen zu halten, damit die ersten Markup-Bits so schnell wie möglich auf dem Weg sind. Wenn das Backend die Dinge aufhält, ist das ein Problem. Da es viele Backend-Stacks gibt, würde es den Rahmen dieses Leitfadens sprengen, jeden einzelnen Stack und die Probleme, die bei jedem einzelnen auftreten können, zu behandeln.
React und andere Frameworks, die Markup bei Bedarf auf dem Server rendern können, verwenden einen synchronen Ansatz für das serverseitige Rendering. In neueren Versionen von React wurden jedoch Servermethoden für das Streaming von Markup während des Renderns implementiert. Sie müssen also nicht warten, bis eine React-Server-API-Methode die gesamte Antwort gerendert hat, bevor sie gesendet wird.
Eine weitere Möglichkeit, Markup schnell an den Browser zu streamen, ist das statische Rendering, bei dem HTML-Dateien während der Erstellung generiert werden. Da die gesamte Datei sofort verfügbar ist, können Webserver sie sofort senden. Die inhärente Natur von HTTP führt zu Streaming-Markup. Dieser Ansatz eignet sich zwar nicht für jede Seite auf jeder Website, z. B. für Seiten, die im Rahmen der Nutzererfahrung eine dynamische Antwort erfordern, kann aber für Seiten nützlich sein, bei denen das Markup nicht für einen bestimmten Nutzer personalisiert werden muss.
Service Worker verwenden
Die Service Worker API kann erhebliche Auswirkungen auf die TTFB für Dokumente und die von ihnen geladenen Ressourcen haben. Das liegt daran, dass ein Service Worker als Proxy zwischen dem Browser und dem Server fungiert. Ob sich dies auf die TTFB Ihrer Website auswirkt, hängt jedoch davon ab, wie Sie Ihren Service Worker einrichten und ob diese Einrichtung den Anforderungen Ihrer Anwendung entspricht.
- Verwenden Sie für Assets eine Stale-While-Revalidate-Strategie. Wenn sich ein Asset im Service Worker-Cache befindet, sei es ein Dokument oder eine vom Dokument benötigte Ressource, wird diese Ressource mit der Stale-While-Revalidate-Strategie zuerst aus dem Cache bereitgestellt. Anschließend wird das Asset im Hintergrund heruntergeladen und für zukünftige Interaktionen aus dem Cache bereitgestellt.
- Wenn Sie Dokumentressourcen haben, die sich nicht sehr oft ändern, kann die TTFB einer Seite mit einer „stale-while-revalidate“-Strategie fast sofort erreicht werden. Das funktioniert jedoch nicht so gut, wenn Ihre Website dynamisch generiertes Markup sendet, z. B. Markup, das sich je nachdem ändert, ob ein Nutzer authentifiziert ist. In solchen Fällen sollten Sie zuerst immer das Netzwerk aufrufen, damit das Dokument so aktuell wie möglich ist.
- Wenn in Ihrem Dokument nicht kritische Ressourcen geladen werden, die sich häufig ändern, das Abrufen der veralteten Ressource jedoch keine wesentlichen Auswirkungen auf die Nutzerfreundlichkeit hat (z. B. ausgewählte Bilder oder andere nicht kritische Ressourcen), kann die TTFB für diese Ressourcen mit einer Stale-While-Revalidate-Strategie erheblich reduziert werden.
- Verwenden Sie das Anwendungsshell-Modell für clientseitig gerenderte Anwendungen. Dieses Modell eignet sich am besten für SPAs, bei denen die „Shell“ der Seite sofort aus dem Service-Worker-Cache bereitgestellt werden kann und die dynamischen Inhalte der Seite später im Lebenszyklus der Seite eingefügt und gerendert werden.
103 Early Hints für renderkritische Ressourcen verwenden
Unabhängig davon, wie gut das Backend Ihrer Anwendung optimiert ist, muss der Server möglicherweise noch viel Arbeit leisten, um eine Antwort vorzubereiten. Dazu gehören auch aufwendige (aber notwendige) Datenbankarbeiten, die die Navigationsantwort verzögern. Dies kann dazu führen, dass einige nachfolgende, für das Rendern kritische Ressourcen verzögert werden, z. B. CSS oder in einigen Fällen JavaScript, das Markup auf dem Client rendert.
Der 103 Early Hints-Header ist ein früher Antwortcode, den der Server an den Browser senden kann, während das Backend mit der Vorbereitung des Markups beschäftigt ist. Mit diesem Header kann dem Browser signalisiert werden, dass es für das Rendering wichtige Ressourcen gibt, die die Seite herunterladen sollte, während das Markup vorbereitet wird. Bei unterstützten Browsern kann dies zu einem schnelleren Rendern von Dokumenten (CSS) und einem schnelleren Seitenaufbau führen.
Ein Nachteil von 103 Early Hints ist, dass sie wie das Caching die „echte“ TTFB einer Website verschleiern können. Wenn eine Serverinfrastruktur langsam ist (entweder weil sie zu wenig Leistung hat oder der Code optimiert werden muss), ist das bei Verwendung von 103 Early Hints möglicherweise weniger offensichtlich, da die TTFB schnell aussieht. Websites, die 103 Early Hints verwenden, sollten die tatsächliche Serverzeit messen (über Server-Timing oder finalResponseHeadersStart der PerformanceNavigationTiming API).
Fazit
Da es so viele Kombinationen von Backend-Anwendungsstacks gibt, kann kein Artikel alles abdecken, was Sie tun können, um die TTFB Ihrer Website zu senken. Es gibt jedoch einige Optionen, mit denen Sie versuchen können, die Dinge auf der Serverseite etwas zu beschleunigen.
Wie bei der Optimierung aller Messwerte ist der Ansatz weitgehend ähnlich: Messen Sie die TTFB im Feld, verwenden Sie Labortools, um die Ursachen zu ermitteln, und wenden Sie dann nach Möglichkeit Optimierungen an. Einige Techniken sind für Ihre Situation möglicherweise nicht geeignet, andere wahrscheinlich schon. Wie immer müssen Sie Ihre Felddaten im Auge behalten und bei Bedarf Anpassungen vornehmen, um eine möglichst schnelle Nutzererfahrung zu gewährleisten.