Reduziere den Cache-Dauer-Anteil der Time to First Byte

Reduziere die Cache-Dauer der Time to First Byte

Dieser Artikel ist Teil unseres Time to First Byte (TTFB)-Guides. Die Cache-Dauer ist der zweite Teilbereich der TTFB. Sie stellt die Zeit dar, die der Browser benötigt, um seinen lokalen Cache und aktive Service Worker nach einer passenden Antwort zu durchsuchen. Die Cache-Dauer ist selten der primäre Engpass. Dennoch ist das Verständnis wichtig für Seiten, die Service Worker nutzen oder stark auf Caching-Strategien des Browsers angewiesen sind.

Die Time to First Byte (TTFB) lässt sich in folgende Teilbereiche untergliedern:

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

Willst du die Time to First Byte optimieren? Dieser Artikel behandelt die Cache-Dauer der Time to First Byte. Du willst die Time to First Byte verstehen oder beheben? Du weißt nicht, was die Cache-Dauer bedeutet? Lies Was ist die Time to First Byte und Behebe und identifiziere Time to First Byte-Probleme, bevor du hier startest.

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

Normalerweise ist der Cache-Dauer-Teilbereich der Time to First Byte kein Engpass. Er dauert 10 bis 20 ms. Bei der Nutzung eines Service Workers ist eine Zeit unter 60 ms akzeptabel.

Wie beeinflussen Service Worker die Time to First Byte?

Service Worker können die Time to First Byte (TTFB) positiv und negativ beeinflussen. Das gilt nur für Websites, die Service Worker nutzen.

So beeinflussen Service Worker die TTFB:

Verlangsamung der TTFB durch die Startzeit des Service Workers: Der workerStart-Wert stellt die Zeit dar, die ein Service Worker zum Starten benötigt. Diese Startzeit fließt in die TTFB-Berechnung ein. Muss ein Service Worker gestartet oder aus einem beendeten Zustand fortgesetzt werden, verzögert das die anfängliche Antwortzeit. Die TTFB steigt.

Beschleunigung der TTFB durch Caching: Mit einer Caching-Strategie wie stale-while-revalidate liefert ein Service Worker Inhalte direkt aus dem Cache. Das führt zu einer fast sofortigen TTFB für häufig aufgerufene Ressourcen. Der Browser wartet nicht auf eine Serverantwort. Diese Strategie eignet sich am besten für selten aktualisierte Inhalte. Dynamisch generierte Inhalte mit Bedarf an aktuellen Daten profitieren weniger.

Beschleunigung der TTFB mit App-Shell: Bei clientseitig gerenderten Anwendungen reduziert das App-Shell-Modell die TTFB der Grundstruktur auf fast null. Dabei liefert der Service Worker eine grundlegende Seitenstruktur aus dem Cache. Inhalte lädt er später dynamisch nach.

Verlangsamung der TTFB durch unoptimierten Code: Komplizierte und ineffiziente Service Worker verlangsamen den Cache-Suchprozess. Dadurch verlangsamt sich auch die TTFB.

Sind Service Worker schlecht für den Pagespeed? Nein, meistens gar nicht. Service Worker erhöhen anfangs die TTFB durch ihre Startzeit. Langfristig führen sie aber zu massiven Leistungsverbesserungen. Sie fangen Netzwerkanfragen ab, verwalten das Caching und bieten Offline-Unterstützung. Das hilft besonders wiederkehrenden Besuchern einer Seite.

Service-Worker-Caching-Strategien

Die Caching-Strategie deines Service Workers bestimmt die Balance zwischen Geschwindigkeit und Aktualität. Jede Strategie hat andere Auswirkungen auf den Cache-Dauer-Teilbereich der TTFB:

Cache-First (Cache Falling Back to Network)

Der Service Worker prüft zuerst den Cache. Existiert eine gecachte Antwort, liefert er sie sofort aus. Wenn nicht, geht die Anfrage ans Netzwerk. Diese Strategie liefert die schnellste TTFB für gecachte Ressourcen. Sie birgt jedoch das Risiko, veraltete Inhalte auszuliefern.

Am besten für: statische Assets, Bilder, Schriftarten 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 (Network Falling Back to Cache)

Der Service Worker versucht immer zuerst das Netzwerk. Schlägt die Netzwerkanfrage fehl (z. B. der Nutzer ist offline), liefert er die gecachte Version. Diese Strategie garantiert aktuelle Inhalte bei verfügbarer Netzwerkverbindung. Sie reduziert jedoch nicht die TTFB für Online-Nutzer.

Am besten für: API-Antworten, oft aktualisierte Inhalte und Seiten, bei denen Aktualität entscheidend ist.

Stale-While-Revalidate

Der Service Worker liefert die gecachte Version sofort aus (schnelle TTFB). Gleichzeitig holt er im Hintergrund eine aktualisierte Version aus dem Netzwerk. Diese aktualisierte Version ersetzt die gecachte Kopie für den nächsten Besuch. Das ist oft die beste Balance zwischen Geschwindigkeit und Aktualität.

Am besten für: Inhalte, die sich regelmäßig ändern, aber keine Echtzeit-Genauigkeit erfordern. Beispiele sind Nachrichtenartikel, Blogposts und Produktlisten.

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;
      });
    })
  );
});

Cache-Control-Header-Konfiguration

Der Cache-Dauer-Teilbereich der TTFB misst die Suchzeit im Service-Worker- und Browser-Cache. Korrekte Cache-Control-Header bestimmen jedoch, ob der Browser den Server überhaupt kontaktieren muss. Richtige Cache-Header umgehen die gesamte TTFB für wiederkehrende Besucher komplett.

Hier ist eine empfohlene Cache-Control-Konfiguration für verschiedene Ressourcentypen:

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

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

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

# API-Antworten (kein Caching)
Cache-Control: no-store

Wichtige Direktiven erklärt:

• no-cache: Der Browser muss beim Server revalidieren, bevor er eine gecachte Kopie nutzt. Das heißt nicht „nicht cachen“. Es heißt „immer zuerst prüfen“.
• no-store: Der Browser darf die Antwort gar 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: Sagt dem Browser, dass sich die Ressource nie ändert. Kombiniere das mit Content-gehashten Dateinamen (z. B. style.a1b2c3.css) für statische Assets.
• public: Erlaubt das Caching der Antwort durch geteilte Caches (CDN, Proxy). Nutze private für nutzerspezifische Inhalte.

Nutzt du ein CDN wie Cloudflare, kannst du auch Edge-Caching-Regeln konfigurieren. Sieh dir unseren Guide an, wie du Cloudflare für Performance konfigurierst. Dort findest du detaillierte Anweisungen.

Back/Forward Cache (bfcache)

Der Back/Forward Cache (bfcache) ist eine Browser-Optimierung. Sie speichert einen kompletten Snapshot einer Seite im Arbeitsspeicher, wenn der Nutzer die Seite verlässt. Drückt der Nutzer den Zurück- oder Vorwärts-Button, wird die Seite sofort aus dem Speicher wiederhergestellt. Das eliminiert die TTFB (und jede andere Lade-Metrik) komplett.

Seiten aus dem bfcache zeigen in RUM-Daten eine TTFB von 0 Millisekunden. Es findet gar keine Netzwerkanfrage statt. Der Browser stellt die Seite einfach aus seinem In-Memory-Snapshot wieder her.

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

• Nutze keine unload-Event-Listener (nutze stattdessen pagehide).
• Nutze nicht Cache-Control: no-store im HTML-Dokument.
• Schließe alle offenen IndexedDB-Verbindungen, wenn die Seite ausgeblendet wird.
• Halte keine aktiven WebSocket- oder WebRTC-Verbindungen (schließe sie im pagehide-Event).

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

Für Seiten mit starkem Zurück-/Vorwärts-Navigationsverhalten (z. B. E-Commerce-Kategorie- und Produktseiten, Suchergebnisseiten) verbessert der bfcache die gefühlte TTFB dramatisch. Das gilt für einen Großteil der Navigationen.

Wie man den Cache-Dauer-Teilbereich der Time to First Byte misst

Du kannst den Cache-Dauer-Teilbereich der Time to First Byte mit diesem Snippet messen:

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

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

  // berechne die Cache-Dauer
  const cacheDuration = dnsStart - waitEnd;

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

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

Wie du TTFB-Probleme durch eine hohe Cache-Dauer findest

Um die Auswirkungen der Cache-Dauer auf echte Nutzer zu finden, brauchst du ein RUM-Tool wie CoreDash. Mit Real User Monitoring kannst du die Core Web Vitals sehr detailliert tracken.

Navigiere in CoreDash einfach zu „Time to First Byte“ und sieh dir die Breakdown-Details an. Das zeigt dir die Aufschlüsselung der TTFB in alle ihre Teilbereiche. Du siehst genau, wie lange die cacheDuration für das 75. Perzentil dauert.

Wie du die Auswirkungen der Service-Worker-Cache-Zeit minimierst

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

• Minimiere die Komplexität der Service-Worker-Skripte, um die Startzeit zu reduzieren.
• Implementiere effiziente Caching-Strategien im Service Worker (bevorzuge stale-while-revalidate für Navigationsanfragen).
• Erwäge das Pre-Caching kritischer Ressourcen während der Service-Worker-Installation.
• Überwache und analysiere regelmäßig den Einfluss von Service Workern auf die TTFB deiner Seite.
• Nutze navigation preload. So läuft die Netzwerkanfrage parallel zum Service-Worker-Start. Das verhindert, dass die Boot-Zeit des Service Workers zur TTFB addiert wird.

Aktiviere navigation preload in deinem Service Worker mit:

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

Setze es richtig um, und Service Worker beschleunigen deine Seite für wiederkehrende Besucher. Setze es falsch um, und jeder Seitenaufruf zahlt die Boot-Kosten.

Weiterführende Literatur: Optimierungs-Guides

Verwandte Guides:

• 103 Early Hints: Starte das Laden kritischer Ressourcen, bevor die Serverantwort bereit ist. Das ergänzt deine Caching-Strategie.
• Cloudflare für Performance konfigurieren: Richte CDN-Edge-Caching, Cache-Regeln und Page Rules ein. So optimierst du deine Caching-Strategie auf Edge-Ebene.

TTFB-Teilbereiche: Vollständige Guides

Die Cache-Dauer ist einer von fünf Teilbereichen der TTFB. Entdecke die anderen Teilbereiche, um das Gesamtbild zu verstehen:

• TTFB-Probleme beheben und identifizieren: Der diagnostische Startpunkt für jede TTFB-Optimierung.
• Wartezeit: Redirects, 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.
• Anfragedauer: Server-Verarbeitungszeit, Datenbankabfragen und Backend-Optimierung.