Reduzierung des Teilschritts Cache Duration des Time to First Byte

Reduzierung der Cache Duration des Time to First Byte

Dieser Artikel ist Teil unseres Leitfadens zum Time to First Byte (TTFB). Die Cache Duration ist der zweite Teilschritt des TTFB und stellt die Zeit dar, die der Browser damit verbringt, seinen lokalen Cache und alle aktiven Service Worker auf eine passende Antwort zu überprüfen. Obwohl die Cache Duration selten der primäre Engpass ist, ist ihr Verständnis wichtig für Websites, die Service Worker verwenden oder stark auf Browser-Caching-Strategien setzen.

Der Time to First Byte (TTFB) kann in die folgenden Teilschritte unterteilt werden:

• Waiting + Redirect (oder Waiting Duration)
• Worker + Cache (oder Cache Duration)
• DNS (oder DNS Duration)
• Connection (oder Connection Duration)
• Request (oder Request Duration)

Möchten Sie den Time to First Byte optimieren? Dieser Artikel befasst sich mit dem Teil Cache Duration des Time to First Byte. Wenn Sie den Time to First Byte verstehen oder beheben möchten und nicht wissen, was Cache Duration bedeutet, lesen Sie bitte Was ist der Time to First Byte und Time to First Byte Probleme identifizieren und beheben, bevor Sie mit diesem Artikel beginnen.

Hinweis: Normalerweise ist der Teil Cache Duration des Time to First Byte kein Engpass. Lesen Sie also weiter, wenn Sie a) einen Service Worker verwenden oder b) ein Pagespeed-Enthusiast wie ich sind!

Normalerweise ist der Teilschritt Cache Duration des Time to First Byte kein Engpass und findet innerhalb von 10 bis 20 ms statt. Bei Verwendung eines Service Workers ist eine Zeit unter 60 ms akzeptabel.

Wie wirken sich Service Worker auf den Time to First Byte aus?

Service Worker können sowohl positive als auch negative Auswirkungen auf den Time to First Byte (TTFB) haben, aber nur für Websites, die Service Worker verwenden.

Hier erfahren Sie, wie sich Service Worker auf den TTFB auswirken:

Verlangsamung des TTFB aufgrund der Startzeit des Service Workers: Der workerStart-Wert stellt die Zeit dar, die ein Service Worker zum Starten benötigt, falls einer für die angeforderte Ressource vorhanden ist. Diese Startzeit ist in der TTFB-Berechnung enthalten. Wenn ein Service Worker aus einem beendeten Zustand heraus gestartet oder fortgesetzt werden muss, kann dies die anfängliche Antwortzeit verzögern und den TTFB erhöhen.

Beschleunigung des TTFB durch Caching: Durch die Verwendung einer Caching-Strategie wie stale-while-revalidate kann ein Service Worker Inhalte direkt aus dem Cache bereitstellen, sofern diese verfügbar sind. Dies führt zu einem nahezu sofortigen TTFB für häufig aufgerufene Ressourcen, da der Browser nicht auf eine Serverantwort warten muss. Diese Strategie eignet sich am besten für selten aktualisierte Inhalte und weniger für dynamisch generierte Inhalte, die aktuelle Informationen erfordern.

Beschleunigung des TTFB mit App-Shell: Bei Client-gerenderten Anwendungen kann das App-Shell-Modell (bei dem ein Service Worker eine grundlegende Seitenstruktur aus dem Cache liefert und Inhalte später dynamisch nachlädt) den TTFB für diese Basisstruktur auf fast Null reduzieren.

Verlangsamung des TTFB durch nicht optimierten Code: Komplizierte und ineffiziente Service Worker können den Cache-Suchprozess verlangsamen und dadurch auch den TTFB erhöhen.

Sind Service Worker schlecht für die Pagespeed? Nein (normalerweise) sind sie überhaupt nicht schlecht. Während Service Worker den TTFB aufgrund der Startzeit anfangs erhöhen können, kann ihre Fähigkeit, Netzwerkanfragen abzufangen, Caching zu verwalten und Offline-Unterstützung zu bieten, langfristig zu erheblichen Performance-Verbesserungen führen, insbesondere für wiederkehrende Besucher einer Website.

Caching-Strategien für Service Worker

Die Caching-Strategie, die Ihr Service Worker verwendet, bestimmt, wie er Geschwindigkeit und Aktualität gegeneinander abwägt. Jede Strategie hat unterschiedliche Auswirkungen auf den Teilschritt Cache Duration des TTFB:

Cache-First (Cache mit Fallback auf das Netzwerk)

Der Service Worker prüft zuerst den Cache. Wenn eine Antwort im Cache vorhanden ist, wird sie sofort zurückgegeben. Wenn nicht, geht die Anfrage an das Netzwerk. Diese Strategie liefert den schnellsten TTFB für gecachte Ressourcen, birgt aber das Risiko, veraltete Inhalte auszuliefern.

Bestens geeignet 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 (Netzwerk mit Fallback auf den Cache)

Der Service Worker versucht immer zuerst das Netzwerk. Wenn die Netzwerkanfrage fehlschlägt (z. B. wenn der Benutzer offline ist), wird die Version aus dem Cache bereitgestellt. Diese Strategie gewährleistet aktuelle Inhalte, wenn das Netzwerk verfügbar ist, reduziert aber nicht den TTFB für Online-Nutzer.

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

Stale-While-Revalidate

Der Service Worker gibt sofort die Version aus dem Cache zurück (schneller TTFB) und ruft gleichzeitig im Hintergrund eine aktualisierte Version aus dem Netzwerk ab. Die aktualisierte Version ersetzt die Kopie im Cache für den nächsten Besuch. Dies ist oft das beste Gleichgewicht zwischen Geschwindigkeit und Aktualität.

Bestens geeignet für: Inhalte, die sich regelmäßig ändern, aber keine Echtzeit-Genauigkeit erfordern, wie Nachrichtenartikel, Blog-Posts 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;
      });
    })
  );
});

Konfiguration des Cache-Control-Headers

Während der Teilschritt Cache Duration des TTFB speziell die Zeit misst, die für die Suche im Service Worker und im Browser-Cache aufgewendet wird, bestimmen korrekte Cache-Control-Header, ob der Browser den Server überhaupt kontaktieren muss. Korrekte Cache-Header können den gesamten TTFB für wiederkehrende Besucher effektiv umgehen.

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

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

# Statische Assets mit Content-Hashing (ewig 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

Erläuterung der wichtigsten Direktiven:

• no-cache: Der Browser muss beim Server revalidieren, bevor er eine Kopie aus dem Cache verwendet. Das bedeutet nicht „nicht cachen“, sondern „immer zuerst prüfen“.
• no-store: Der Browser darf die Antwort überhaupt nicht cachen. Verwenden Sie dies für sensible oder hochdynamische Inhalte.
• max-age: Die Anzahl der Sekunden, die die Antwort ohne Revalidierung aus dem Cache bereitgestellt werden kann.
• immutable: Teilt dem Browser mit, dass sich die Ressource niemals ändern wird. Kombinieren Sie dies mit Dateinamen mit Content-Hash (z. B. style.a1b2c3.css) für statische Assets.
• public: Erlaubt das Caching der Antwort durch Shared Caches (CDN, Proxy). Verwenden Sie private für benutzerspezifische Inhalte.

Wenn Sie ein CDN wie Cloudflare verwenden, können Sie auch Regeln für das Edge-Caching konfigurieren. In unserem Leitfaden erfahren Sie, wie Sie Cloudflare für optimale Performance konfigurieren.

Back/Forward Cache (bfcache)

Der Back/Forward Cache (bfcache) ist eine Browser-Optimierung, die einen vollständigen Snapshot einer Seite im Speicher ablegt, wenn der Benutzer die Seite verlässt. Wenn der Benutzer die Zurück- oder Vorwärts-Schaltfläche drückt, wird die Seite sofort aus dem Speicher wiederhergestellt, wodurch der TTFB (und alle anderen Lade-Metriken) vollständig eliminiert wird.

Seiten, die aus dem bfcache bereitgestellt werden, zeigen in RUM Daten einen TTFB von 0 Millisekunden an, da überhaupt keine Netzwerkanfrage gestellt wird. Der Browser stellt die Seite einfach aus seinem Snapshot im Arbeitsspeicher wieder her.

Um sicherzustellen, dass Ihre Seiten für den bfcache in Frage kommen:

• Verwenden Sie keine unload Event-Listener (verwenden Sie stattdessen pagehide).
• Verwenden Sie kein Cache-Control: no-store für das HTML-Dokument.
• Schließen Sie alle offenen IndexedDB-Verbindungen, wenn die Seite ausgeblendet wird.
• Halten Sie keine aktiven WebSocket- oder WebRTC-Verbindungen (schließen Sie diese im pagehide-Event).

Sie können die bfcache-Eignung in den Chrome DevTools unter dem Tab Application im Bereich „Back/Forward Cache“ testen. Chrome listet alle Gründe auf, warum die Seite nicht für den bfcache in Frage kam.

Für Websites mit ausgeprägten Back/Forward-Navigationsmustern (z. B. E-Commerce-Kategorie- und Produktseiten, Suchergebnisseiten) kann der bfcache den wahrgenommenen TTFB für einen großen Teil der Navigationen drastisch verbessern.

So messen Sie den Teilschritt Cache Duration des Time to First Byte

Sie können den Teilschritt Cache Duration des 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 Duration
  const cacheDuration = dnsStart - waitEnd;

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

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

So finden Sie TTFB-Probleme, die durch eine hohe Cache Duration verursacht werden

Um die Auswirkungen zu ermitteln, die echte Benutzer durch die Cache Duration erfahren, müssen Sie ein RUM-Tool wie CoreDash verwenden. Mit Real User Monitoring können Sie die Core Web Vitals sehr detailliert verfolgen.

Navigieren Sie in CoreDash einfach zu „Time to First Byte“ und sehen Sie sich die Details der Aufschlüsselung an. Hier wird die Aufschlüsselung des TTFB in all seine Teilschritte angezeigt und es wird genau angegeben, wie lange die cacheDuration für das 75. Perzentil dauert.

So minimieren Sie die Auswirkungen der Service Worker Cache-Zeit

Zur Optimierung des TTFB bei Verwendung von Service Workern:

• Minimieren Sie die Komplexität der Service Worker-Scripte, um die Startzeit zu verkürzen.
• Implementieren Sie effiziente Caching-Strategien innerhalb des Service Workers (bevorzugen Sie stale-while-revalidate für Navigationsanfragen).
• Erwägen Sie das Pre-Caching kritischer Ressourcen während der Installation des Service Workers.
• Überwachen und analysieren Sie regelmäßig die Auswirkungen von Service Workern auf den TTFB Ihrer Website.
• Verwenden Sie navigation preload, um die Netzwerkanfrage parallel zum Start des Service Workers zu ermöglichen. Dies verhindert, dass die Boot-Zeit des Service Workers zum TTFB addiert wird.

Aktivieren Sie Navigation Preload in Ihrem Service Worker mit:

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

Machen Sie die Implementierung richtig, und Service Worker beschleunigen Ihre Website für wiederkehrende Besucher. Machen Sie es falsch, und jeder Seitenaufruf zahlt den Preis für die Boot-Zeit.

Weiterführende Literatur: Optimierungs-Leitfäden

Verwandte Leitfäden:

• 103 Early Hints: Beginnen Sie mit dem Laden kritischer Ressourcen, bevor die Serverantwort bereit ist, als Ergänzung zu Ihrer Caching-Strategie.
• Cloudflare für Performance konfigurieren: Richten Sie CDN-Edge-Caching, Cache-Regeln und Seiten-Regeln ein, um Ihre Caching-Strategie auf Edge-Ebene zu optimieren.

TTFB-Teilschritte: Vollständige Leitfäden

Die Cache Duration ist einer von fünf Teilschritten des TTFB. Erkunden Sie die anderen Teilschritte, um das Gesamtbild zu verstehen:

• TTFB-Probleme identifizieren und beheben: Der diagnostische Ausgangspunkt für jede TTFB-Optimierung.
• Waiting Duration: Weiterleitungen, Browser-Queuing und HSTS-Optimierung.
• DNS Duration: Auswahl des DNS-Anbieters, TTL-Konfiguration und dns-prefetch.
• Connection Duration: TCP-Handshake, TLS-Optimierung, HTTP/3 und preconnect.
• Request Duration: Server-Verarbeitungszeit, Datenbankabfragen und Backend-Optimierung.