Hauptbereich
Agency
technisches-seo

TTFB und Critical Rendering Path — der Initial Load von Server bis erstem Paint

Redaktion ·

TTFB und Critical Rendering Path — der Initial Load von Server bis erstem Paint

Zwischen dem Klick auf einen Link und dem ersten sichtbaren Pixel passieren zwei Dinge nacheinander: Erst muss der Server überhaupt anfangen zu antworten — das misst TTFB. Dann muss der Browser aus dem ankommenden HTML, CSS und JavaScript ein Bild bauen — das ist der Critical Rendering Path. Beide hängen direkt zusammen: Ein langsamer Server verschiebt alles Nachfolgende nach hinten, und ein blockierter Render-Pfad macht selbst aus einem schnellen Server eine gefühlt lahme Seite. Wer Ladezeiten ernst optimieren will, muss beide Hälften verstehen — sonst dreht man am falschen Hebel.

TTFB — was genau gemessen wird

TTFB steht für Time to First Byte: die Zeit zwischen dem Start der Navigation zu einer Seite und dem Moment, in dem das erste Byte der Antwort beim Browser eintrifft (Quelle: web.dev, abgerufen 2026-06-06). Wichtig ist die Betonung auf erstes Byte — nicht das ganze Dokument, nicht das erste Pixel, sondern das allererste Stück Antwort. TTFB ist damit kein Ladezeit-Wert im Alltagssinn, sondern der Startschuss für alles Weitere.

Der Wert setzt sich aus mehreren Phasen zusammen, die der Browser nacheinander durchläuft, bevor der Server überhaupt antworten kann:

  • Redirect-Zeit — jede 301/302-Weiterleitung kostet eine komplette zusätzliche Runde.
  • Service-Worker-Startzeit — falls ein Service Worker die Anfrage abfängt.
  • DNS-Lookup — Auflösung des Domainnamens in eine IP-Adresse.
  • Verbindungsaufbau und TLS-Handshake — TCP-Handshake plus Aufbau der verschlüsselten Verbindung.
  • Server-Verarbeitung — die eigentliche Arbeit auf dem Server, bis das erste Byte rausgeht.

Erst wenn diese Kette durchlaufen ist, beginnt die Übertragung. Jeder dieser Schritte ist ein eigener potenzieller Bremsklotz, und genau deshalb ist es wichtig zu wissen, welche Phase bei dir dominiert — die Browser-Devtools zeigen das im Netzwerk-Tab pro Request auf.

Der Schwellenwert — was als gut gilt

Der Richtwert von web.dev ist klar: 0,8 Sekunden (800 Millisekunden) oder weniger gelten als gut, gemessen am 75. Perzentil. Werte über 1,8 Sekunden gelten als schlecht (Quelle: web.dev, abgerufen 2026-06-06). Dazwischen liegt der Graubereich „verbesserungswürdig”.

Diese 800 ms sind ein grober Orientierungswert, kein hartes Ranking-Limit. TTFB selbst ist auch kein eigenständiger Core-Web-Vitals-Wert — es taucht in keinem der drei offiziellen Metriken direkt auf. Trotzdem ist es entscheidend, und der Grund dafür ist Mechanik, nicht Marketing.

Warum TTFB der Startschuss für LCP ist

TTFB geht jeder anderen sinnvollen Ladezeit-Metrik voraus (Quelle: web.dev, abgerufen 2026-06-06). First Contentful Paint kann nicht früher passieren als der Eingang des ersten Bytes. Und der Largest Contentful Paint — der Core-Web-Vitals-Wert, der das größte sichtbare Element misst — sitzt zeitlich noch weiter hinten in der Kette.

Die Konsequenz ist unangenehm einfach: Ein schlechter TTFB macht einen guten LCP unmöglich. Wenn der Server 1,5 Sekunden braucht, bevor das erste Byte kommt, kann der LCP rechnerisch nicht unter diesen 1,5 Sekunden landen — egal wie schlank dein CSS ist oder wie clever du Bilder lädst. TTFB ist das Fundament; alle Optimierung am Frontend baut darauf auf. Besonders hart trifft das Single-Page-Apps mit Client-seitigem Rendering: Dort wartet der Nutzer erst auf das erste Byte und dann noch auf das JavaScript, das die Seite zusammenbaut.

TTFB-Hebel — wo man wirklich Zeit gewinnt

Die wirksamsten Hebel sitzen auf der Server- und Verbindungsebene:

CDN einsetzen. Ein Content Delivery Network stellt Edge-Server geografisch näher an den Nutzer, bringt moderne Protokolle (HTTP/2, HTTP/3) mit und beschleunigt DNS-Auflösung und Verbindungsaufbau. Für Sites mit Publikum über mehrere Regionen ist das oft der größte Einzelgewinn.

Caching konfigurieren. Korrekt gesetzte Cache-Control-Header lassen Edge- und Server-Caches greifen. Selbst kurze Cache-Zeiten helfen auf stark besuchten Seiten enorm — nur der erste Besucher im Zeitfenster zahlt die volle Latenz, alle danach bekommen die zwischengespeicherte Antwort. Wichtig: bei Releases gezielt invalidieren, und keine sinnlosen Query-Parameter anhängen, die jeden Aufruf zum Cache-Miss machen.

Redirects vermeiden. Weiterleitungen sind ein häufiger TTFB-Killer, weil jede einen kompletten zusätzlichen Roundtrip kostet (Quelle: web.dev, abgerufen 2026-06-06). Prüfe gerade die Same-Origin-Redirects, die du selbst kontrollierst. Ein HSTS-Header eliminiert die HTTP-zu-HTTPS-Weiterleitung; mit HSTS-Preload sparst du sie sogar beim allerersten Besuch.

Server-Arbeit reduzieren. Schnellere Datenbankabfragen, weniger synchrone Backend-Arbeit pro Request, Streaming des Markups statt Warten auf das fertige Dokument. Und mit 103 Early Hints kann der Server dem Browser schon während der Backend-Verarbeitung sagen, welche kritischen Ressourcen er parallel laden soll.

Der Critical Rendering Path — vom Byte zum Pixel

Sobald das erste Byte da ist, übernimmt der Browser. Der Critical Rendering Path ist die Sequenz von Schritten, die er durchläuft, um aus rohem Code ein sichtbares Bild zu machen. Die Reihenfolge ist fest:

  1. HTML → DOM. Der Browser parst das ankommende HTML und baut daraus das Document Object Model — die Baumstruktur aller Elemente.
  2. CSS → CSSOM. Parallel parst er das CSS und baut das CSS Object Model — die Baumstruktur aller Stilregeln.
  3. Render-Tree. DOM und CSSOM werden zusammengeführt zu einem Render-Tree, der nur die sichtbaren Elemente mit ihren berechneten Stilen enthält.
  4. Layout (auch Reflow). Der Browser berechnet die genaue Position und Größe jedes Elements auf der Seite.
  5. Paint. Die berechneten Pixel werden tatsächlich auf den Bildschirm gemalt.

Erst nach Schritt 5 sieht der Nutzer etwas. Der entscheidende Punkt: Diese Kette kann an mehreren Stellen ins Stocken geraten — und zwar reproduzierbar, weil bestimmte Ressourcen den Pfad blockieren.

Was den Pfad blockiert — render-blocking CSS und JS

Zwei Ressourcentypen halten den Render-Pfad an:

Render-blocking CSS. CSS ist standardmäßig render-blocking. Der Browser muss das gesamte CSSOM aufgebaut haben, bevor er den Render-Tree bilden und überhaupt etwas malen darf — sonst würde er ein unstilisiertes Layout zeigen und dann umspringen. Heißt: Jedes externe Stylesheet im <head> verzögert den ersten Paint, bis es vollständig geladen und geparst ist. Große CSS-Dateien oder viele einzelne Stylesheet-Requests sind hier der typische Bremsklotz. Siehe auch render-blocking resources.

Synchrones JavaScript. Trifft der HTML-Parser auf ein <script> ohne async- oder defer-Attribut, stoppt er. Er muss das Skript erst herunterladen, parsen und ausführen, bevor er mit dem HTML weitermacht — denn das Skript könnte das DOM verändern. Ein einzelnes synchrones Skript hoch im <head> kann den DOM-Aufbau für hunderte Millisekunden anhalten.

Hebel für den Critical Rendering Path

Das Ziel: möglichst wenige Ressourcen blockieren den ersten Paint, und die, die nötig sind, kommen so früh wie möglich an.

Kritisches CSS inline. Das CSS, das für den sichtbaren Bereich (above the fold) gebraucht wird, direkt ins HTML einbetten. So muss der Browser nicht auf einen externen Request warten, um den ersten Paint zu machen. Das restliche CSS lädt asynchron nach.

JavaScript defern oder async. defer lässt das Skript im Hintergrund laden und führt es erst aus, wenn das HTML fertig geparst ist — der Parser läuft ohne Unterbrechung durch. async lädt ebenfalls parallel, führt aber aus, sobald das Skript da ist (Reihenfolge nicht garantiert). Für die meisten Skripte, die nicht sofort gebraucht werden, ist defer die sichere Wahl.

Kritische Ressourcen minimieren. Weniger und kleinere blockierende Dateien. Ungenutztes CSS entfernen, Stylesheets bündeln statt zwölf einzeln zu laden, Schriften vorausladen statt sie spät zu entdecken.

Ressourcen priorisieren. Mit preload, preconnect und fetchpriority dem Browser früh sagen, was wichtig ist — damit das LCP-Bild oder die kritische Schrift nicht hinter unwichtigen Requests in der Warteschlange hängt.

Wie sich diese Hebel im konkreten Audit auswirken, zeigt PageSpeed Insights — dort tauchen render-blocking Ressourcen als explizite Empfehlung auf.

Wie beide Hälften zusammenspielen

TTFB und Critical Rendering Path sind keine getrennten Welten, sondern zwei Etappen desselben Laufs. TTFB bestimmt, wann der Browser anfangen kann zu arbeiten. Der Critical Rendering Path bestimmt, wie schnell er aus dem Material ein Bild baut. Optimierst du nur die eine Hälfte, bleibt die andere der Flaschenhals.

Ein praktisches Bild: TTFB ist die Zeit, bis das Paket beim Empfänger klingelt. Der Critical Rendering Path ist die Zeit vom Klingeln bis das Paket ausgepackt und aufgebaut ist. Beide zusammen ergeben das, was der Nutzer als „die Seite lädt” erlebt — und beide zusammen entscheiden über den LCP, den Google in den Core Web Vitals bewertet.

FAQ

Ist TTFB selbst ein Core-Web-Vitals-Wert?

Nein. Die drei Core Web Vitals sind LCP, INP und CLS — TTFB ist keiner davon. TTFB ist aber die Vorstufe, die LCP nach unten begrenzt: Ein TTFB von 1,5 Sekunden macht einen LCP unter 1,5 Sekunden rechnerisch unmöglich. Deshalb taucht TTFB in jedem ernsthaften Performance-Audit als Diagnose-Wert auf.

Welcher TTFB-Wert ist gut?

Als Richtwert gelten 0,8 Sekunden (800 ms) oder weniger am 75. Perzentil. Über 1,8 Sekunden gilt als schlecht, dazwischen als verbesserungswürdig (Quelle: web.dev, abgerufen 2026-06-06). Das ist eine Orientierung, kein hartes Limit — aber je niedriger, desto mehr Spielraum hast du im restlichen Ladevorgang.

Was ist der Unterschied zwischen async und defer bei Skripten?

Beide laden das Skript parallel zum HTML-Parsing und blockieren den Parser nicht beim Download. Der Unterschied ist die Ausführung: defer wartet, bis das HTML fertig geparst ist, und führt Skripte in Dokumentreihenfolge aus. async führt aus, sobald das Skript geladen ist — egal wie weit der Parser ist und ohne garantierte Reihenfolge. Für abhängige Skripte ist defer die sichere Wahl.

Warum blockiert CSS das Rendering, obwohl es nur Aussehen betrifft?

Weil der Browser kein unstilisiertes Layout zeigen und dann nachträglich umspringen will. Er muss das komplette CSSOM kennen, um den Render-Tree korrekt zu bauen — sonst wäre der erste Paint falsch und müsste neu gemalt werden. Deshalb wartet er, bis das render-blocking CSS vollständig da ist. Die Lösung ist nicht, CSS zu entfernen, sondern das kritische CSS inline zu stellen und den Rest asynchron nachzuladen.

Bringt ein CDN immer einen besseren TTFB?

Nicht zwangsläufig. Ein CDN hilft vor allem bei Verbindungs- und DNS-Latenz und bei geografisch verteiltem Publikum. Wenn dein TTFB dagegen von langsamer Server-Verarbeitung dominiert wird — etwa schwere Datenbankabfragen pro Request — löst ein CDN das nicht. Deshalb gilt: erst im Netzwerk-Tab schauen, welche Phase dominiert, dann den passenden Hebel wählen.

Themenuebersicht

Technisches SEOCore Web VitalsPageSpeed & Performance