Cache-Dauer der Time to First Byte verkürzen

Cache-Dauer der Time to First Byte verkürzen

Dieser Artikel ist Teil unseres Leitfadens zur Time to First Byte (TTFB). Die Cache-Dauer ist die zweite Teilphase des TTFB. Sie misst die Zeit, die der Browser braucht, um seinen lokalen Cache und aktive Service Worker nach einer passenden Antwort zu durchsuchen. Zwar ist die Cache-Dauer selten der primäre Engpass. Trotzdem musst du sie verstehen, wenn deine Website Service Worker nutzt oder stark auf Caching-Strategien im Browser setzt.

Die Time to First Byte (TTFB) lässt sich in folgende Teilphasen unterteilen:

• Waiting + Redirect (oder Wartedauer)
• Worker + Cache (oder Cache-Dauer)
• DNS (oder DNS-Dauer)
• Connection (oder Verbindungsdauer)
• Request (oder Request-Dauer)

Du willst die Time to First Byte optimieren? Dieser Artikel behandelt die Cache-Dauer der Time to First Byte. Wenn du die Time to First Byte verstehen oder beheben willst und noch nicht weißt, was die Cache-Dauer bedeutet: Lies zuerst Was ist die Time to First Byte? und TTFB-Probleme erkennen und beheben, bevor du mit diesem Artikel weitermachst.

Hinweis: Meistens ist die Cache-Dauer der Time to First Byte kein Engpass. Lies also weiter, wenn du a) einen Service Worker nutzt oder b) wie ich ein Pagespeed-Enthusiast bist!

Normalerweise ist die Teilphase der Cache-Dauer kein Engpass beim TTFB und liegt zwischen 10 und 20 ms. Nutzt du einen Service Worker, ist ein Wert unter 60 ms akzeptabel.

Wie Service Worker die Time to First Byte beeinflussen

Service Worker können die Time to First Byte (TTFB) positiv wie negativ beeinflussen – allerdings nur auf Websites, die Service Worker tatsächlich einsetzen.

So wirken sich Service Worker auf den TTFB aus:

TTFB verlangsamen durch die Service-Worker-Startzeit: Der Wert workerStart gibt die Zeit an, die ein Service Worker zum Starten braucht, falls für die angeforderte Ressource einer aktiv ist. Diese Startzeit fließt direkt in die TTFB-Berechnung ein. Muss ein Service Worker erst starten oder aus einem beendeten Zustand reaktiviert werden, verzögert das die anfängliche Antwortzeit und verschlechtert den TTFB.

TTFB beschleunigen durch Caching: Mit einer Caching-Strategie wie stale-while-revalidate liefert ein Service Worker Inhalte direkt aus dem Cache aus, sofern vorhanden. Das sorgt bei häufig aufgerufenen Ressourcen für einen nahezu sofortigen TTFB, weil der Browser nicht auf eine Serverantwort warten muss. Diese Strategie eignet sich am besten für selten aktualisierte Inhalte – weniger für dynamisch erzeugte Seiten, die aktuelle Daten verlangen.

TTFB beschleunigen mit einer App-Shell: Bei Client-gerenderten Anwendungen kann das App-Shell-Modell (der Service Worker liefert die Grundstruktur der Seite sofort aus dem Cache und lädt Inhalte später dynamisch nach) den TTFB für dieses Grundgerüst auf fast null senken.

TTFB verlangsamen durch unoptimierten Code: Komplizierte und ineffiziente Service Worker bremsen den Cache-Lookup aus und verschlechtern damit auch den TTFB.

Sind Service Worker schlecht für den Pagespeed? Nein, in der Regel überhaupt nicht. Zwar können Service Worker den TTFB anfangs durch ihre Startzeit erhöhen. Langfristig bringen sie jedoch deutliche Performance-Gewinne, vor allem für wiederkehrende Besucher: Sie fangen Netzwerkanfragen ab, verwalten das Caching und ermöglichen Offline-Nutzung.

Caching-Strategien für Service Worker

Die Caching-Strategie deines Service Workers bestimmt, wie er Geschwindigkeit und Aktualität ausbalanciert. Jede Strategie wirkt sich anders auf die Teilphase der Cache-Dauer beim TTFB aus:

Cache-First (Cache mit Fallback auf das Netzwerk)

Der Service Worker prüft zuerst den Cache. Existiert eine gecachte Antwort, liefert er sie sofort aus. Wenn nicht, geht der Request an das Netzwerk. Diese Strategie sorgt für den schnellsten TTFB bei gecachten Ressourcen, birgt aber das Risiko veralteter Inhalte.

Optimal für: statische Assets, Bilder, Fonts und Inhalte, die sich selten ändern.

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cachedResponse) => {
      if (cachedResponse) {
        return cachedResponse;
      }
      return fetch(event.request).then((networkResponse) => {
        const cache = await caches.open('v1');
        cache.put(event.request, networkResponse.clone());
        return networkResponse;
      });
    })
  );
});

Network-First (Netzwerk mit Fallback auf den Cache)

Der Service Worker versucht es immer zuerst über das Netzwerk. Schlägt der Netzwerk-Request fehl (z. B. wenn der Nutzer offline ist), wird die Version aus dem Cache ausgeliefert. Diese Strategie garantiert frische Inhalte bei bestehender Netzwerkverbindung, senkt den TTFB für Online-Nutzer aber nicht.

Optimal für: API-Responses, häufig aktualisierte Inhalte und Seiten, bei denen Aktualität entscheidend ist.

Stale-While-Revalidate

Der Service Worker liefert sofort die Version aus dem Cache aus (schneller TTFB) und ruft parallel im Hintergrund eine aktualisierte Fassung aus dem Netzwerk ab. Diese aktualisierte Version ersetzt die Kopie im Cache für den nächsten Aufruf. Das bietet oft die beste Balance zwischen Geschwindigkeit und Aktualität.

Optimal für: Inhalte, die sich regelmäßig ändern, aber keine Echtzeit-Genauigkeit erfordern – wie News-Artikel, Blogposts und Produktübersichten.

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.open('v1').then((cache) => {
      return cache.match(event.request).then((cachedResponse) => {
        const fetchPromise = fetch(event.request).then((networkResponse) => {
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
        return cachedResponse || fetchPromise;
      });
    })
  );
});

Konfiguration des Cache-Control-Headers

Während die Teilphase der Cache-Dauer beim TTFB gezielt die Zeit für Lookups im Service Worker und im Browser-Cache misst, bestimmen saubere Cache-Control-Header, ob der Browser den Server überhaupt kontaktieren muss. Korrekte Cache-Header können den gesamten TTFB für wiederkehrende Besucher praktisch komplett umgehen.

So sieht eine empfohlene Cache-Control-Konfiguration für verschiedene Ressourcentypen aus:

# HTML-Seiten (immer revalidieren)
Cache-Control: no-cache

# Statische Assets mit Content-Hashing (dauerhaft cachen)
Cache-Control: public, max-age=31536000, immutable

# Bilder ohne Content-Hashing (1 Woche cachen)
Cache-Control: public, max-age=604800

# API-Antworten (nicht cachen)
Cache-Control: no-store

Wichtige Direktiven im Überblick:

• no-cache: Der Browser muss die Antwort vor der Verwendung beim Server revalidieren. Das bedeutet nicht „nicht cachen“, sondern „immer zuerst prüfen“.
• no-store: Der Browser darf die Antwort überhaupt nicht cachen. Nutze das für sensible oder hochdynamische Inhalte.
• max-age: Die Anzahl der Sekunden, die die Antwort ohne Revalidierung aus dem Cache ausgeliefert werden darf.
• immutable: Signalisiert dem Browser, dass sich die Ressource niemals ändern wird. Kombiniere das bei statischen Assets mit Content-Hashes im Dateinamen (z. B. style.a1b2c3.css).
• public: Erlaubt Shared Caches (CDN, Proxy), die Antwort zu speichern. Nutze private für nutzerspezifische Inhalte.

Nutzt du ein CDN wie Cloudflare, kannst du zusätzlich Edge-Caching-Regeln einrichten. Eine detaillierte Anleitung findest du in unserem Leitfaden Cloudflare für Performance konfigurieren.

Back/Forward-Cache (bfcache)

Der Back/Forward-Cache (bfcache) ist eine Browser-Optimierung, die beim Verlassen einer Seite einen vollständigen Snapshot im Arbeitsspeicher ablegt. Klickt der Nutzer auf den Zurück- oder Vor-Button, wird die Seite sofort aus dem Speicher wiederhergestellt – was den TTFB (und jede andere Lademetrik) komplett eliminiert.

Seiten, die aus dem bfcache geladen werden, weisen in RUM-Daten einen TTFB von 0 Millisekunden auf, da überhaupt kein Netzwerk-Request stattfindet. Der Browser stellt die Seite einfach aus dem Snapshot im Arbeitsspeicher wieder her.

So stellst du sicher, dass deine Seiten für den bfcache infrage kommen:

• Verwende keine unload-Event-Listener (nutze stattdessen pagehide).
• Verwende kein Cache-Control: no-store auf dem HTML-Dokument.
• Schließe offene IndexedDB-Verbindungen, sobald die Seite ausgeblendet wird.
• Halte keine aktiven WebSocket- oder WebRTC-Verbindungen offen (schließe sie im pagehide-Event).

Du kannst die bfcache-Tauglichkeit in den Chrome DevTools im Tab „Application“ unter „Back/Forward Cache“ testen. Chrome listet dort alle Gründe auf, warum eine Seite nicht für den bfcache qualifiziert war.

Auf Websites mit typischen Vor- und Zurück-Navigationsmustern (z. B. Kategorieseiten und Produktdetails im E-Commerce oder Suchergebnisseiten) kann der bfcache den gefühlten TTFB für einen großen Teil der Aufrufe massiv verbessern.

So misst du die Cache-Dauer der Time to First Byte

Mit diesem Snippet misst du die Teilphase der Cache-Dauer bei der Time to First Byte:

new PerformanceObserver((entryList) => {
  const [navigationEntry] = entryList.getEntriesByType('navigation');

  // Relevante Zeitstempel ermitteln
  const activationStart = navigationEntry.activationStart || 0;
  const waitEnd = Math.max(
    (navigationEntry.workerStart || navigationEntry.fetchStart) -
    activationStart,
    0,
  );
  const dnsStart = Math.max(
    navigationEntry.domainLookupStart - activationStart,
    0,
  );

  // Cache-Dauer berechnen
  const cacheDuration = dnsStart - waitEnd;

  // Ergebnisse ausgeben
  console.log('%cTTFB cacheDuration', 'color: blue; font-weight: bold;');
  console.log(cacheDuration);

}).observe({
  type: 'navigation',
  buffered: true
});

TTFB-Probleme durch eine hohe Cache-Dauer finden

Um zu ermitteln, wie sich die Cache-Dauer auf echte Nutzer auswirkt, brauchst du ein RUM-Tool wie CoreDash. Mit Real User Monitoring überwachst du die Core Web Vitals bis ins Detail.

Navigiere in CoreDash einfach zu „Time to First Byte“ und öffne die Detailaufschlüsselung. Dort siehst du den TTFB in all seine Teilphasen zerlegt und erfährst genau, wie viel Zeit die cacheDuration für das 75. Perzentil beansprucht.

Einfluss der Service-Worker-Cache-Dauer minimieren

So optimierst du den TTFB bei der Nutzung von Service Workern:

• Halte Service-Worker-Skripte schlank, um die Startzeit zu verkürzen.
• Implementiere effiziente Caching-Strategien im Service Worker (bevorzuge stale-while-revalidate für Navigations-Requests).
• Nutze Pre-Caching für kritische Ressourcen bereits während der Installation des Service Workers.
• Überwache und analysiere regelmäßig, wie sich Service Worker auf den TTFB deiner Website auswirken.
• Nutze navigation preload, um den Netzwerk-Request parallel zum Start des Service Workers auszuführen. So verhinderst du, dass die Boot-Zeit des Service Workers den TTFB verlängert.

Aktiviere Navigation Preload in deinem Service Worker so:

self.addEventListener('activate', (event) => {
  event.waitUntil(
    (async () => {
      if (self.registration.navigationPreload) {
        await self.registration.navigationPreload.enable();
      }
    })()
  );
});

Stimmt die Implementierung, beschleunigen Service Worker deine Website für wiederkehrende Besucher spürbar. Machst du es falsch, zahlt jeder einzelne Seitenaufruf die Boot-Kosten.

Weiterführende Artikel: Leitfäden zur Optimierung

Passende Leitfäden:

• 103 Early Hints: Lade kritische Ressourcen schon, bevor die Serverantwort fertig ist – die ideale Ergänzung zu deiner Caching-Strategie.
• Cloudflare für Performance konfigurieren: Richte CDN-Edge-Caching, Cache-Rules und Page-Rules ein, um deine Caching-Strategie direkt auf Edge-Ebene zu optimieren.

TTFB-Teilphasen: Vollständige Leitfäden

Die Cache-Dauer ist eine von fünf Teilphasen des TTFB. Sieh dir auch die anderen Teilphasen an, um das Gesamtbild zu verstehen:

• TTFB-Probleme erkennen und beheben: der diagnostische Ausgangspunkt für jede TTFB-Optimierung.
• Wartedauer: Weiterleitungen, Browser-Queuing und HSTS-Optimierung.
• DNS-Dauer: Auswahl des DNS-Providers, TTL-Konfiguration und dns-prefetch.
• Verbindungsdauer: TCP-Handshake, TLS-Optimierung, HTTP/3 und preconnect.
• Request-Dauer: Server-Verarbeitungszeit, Datenbankabfragen und Backend-Optimierung.