Verlaag het Cache Duration Onderdeel van de Time to First Byte

Verlaag de Cache Duration van de Time to First Byte

Dit artikel is onderdeel van onze Time to First Byte (TTFB) gids. De cache duration is het tweede onderdeel van de TTFB en vertegenwoordigt de tijd die de browser besteedt aan het controleren van de lokale cache en eventuele actieve service workers voor een overeenkomend antwoord. Hoewel de cache duration zelden de primaire bottleneck is, is het begrijpen ervan belangrijk voor websites die service workers gebruiken of sterk afhankelijk zijn van browser caching strategieën.

De Time to First Byte (TTFB) kan worden opgedeeld in de volgende onderdelen:

• Waiting + Redirect (of waiting duration)
• Worker + Cache (of cache duration)
• DNS (of DNS duration)
• Connection (of connection duration)
• Request (of request duration)

Wil je de Time to First Byte optimaliseren? Dit artikel behandelt het cache duration gedeelte van de Time to First Byte. Als je de Time to First Byte wilt begrijpen of oplossen en niet weet wat de cache duration betekent, lees dan wat is de Time to First Byte en Time to First Byte problemen identificeren en oplossen voordat je met dit artikel begint.

Let op: meestal is het Cache Duration gedeelte van de Time to First Byte geen bottleneck. Dus lees verder als a) je een service worker gebruikt, of b) je een pagespeed liefhebber bent zoals ik!

Meestal is het cache duration onderdeel van de Time to First Byte geen bottleneck en gebeurt dit binnen 10 tot 20 ms. Bij gebruik van een service worker is een acceptabele tijd onder de 60ms.

Hoe Beïnvloeden Service Workers de Time to First Byte?

Service workers kunnen zowel een positieve als een negatieve impact hebben op de Time to First Byte (TTFB), maar alleen voor websites die Service Workers gebruiken.

Hier is hoe service workers TTFB beïnvloeden:

Vertragen van de TTFB door de Opstarttijd van de Service Worker: De workerStart waarde vertegenwoordigt de tijd die het kost voor een Service Worker om op te starten als er een aanwezig is voor de aangevraagde resource. Deze opstarttijd is inbegrepen in de TTFB berekening. Als een Service Worker moet worden gestart of hervat vanuit een beëindigde status, kan dit een vertraging toevoegen aan de initiële responstijd en de TTFB verhogen.

Versnellen van de TTFB door caching: Door een caching strategie zoals stale-while-revalidate te gebruiken, kan een service worker content direct uit de cache serveren als deze beschikbaar is. Dit leidt tot een vrijwel onmiddellijke TTFB voor vaak opgevraagde resources, aangezien de browser niet hoeft te wachten op een server respons. Deze strategie werkt het beste voor niet vaak bijgewerkte content in plaats van dynamisch gegenereerde content die up-to-date informatie vereist.

Versnellen van de TTFB met app-shell: Voor client-rendered applicaties kan het app shell model (waarbij een service worker een basis paginastructuur uit de cache levert en later dynamisch content laadt) de TTFB voor die basisstructuur reduceren tot bijna nul.

Vertragen van de TTFB met ongeoptimaliseerde code: Ingewikkelde en inefficiënte service workers kunnen het cache zoekproces vertragen en daardoor ook de TTFB vertragen.

Zijn service workers slecht voor pagespeed? Nee (meestal) zijn ze helemaal niet slecht. Hoewel Service Workers in eerste instantie de TTFB kunnen verhogen vanwege de opstarttijd, kan hun vermogen om netwerkverzoeken te onderscheppen, caching te beheren en offline ondersteuning te bieden leiden tot serieuze prestatieverbeteringen op de lange termijn, vooral voor terugkerende bezoekers van een site.

Service Worker Caching Strategieën

De caching strategie die je service worker gebruikt, bepaalt hoe deze snelheid en versheid balanceert. Elke strategie heeft verschillende implicaties voor het cache duration onderdeel van de TTFB:

Cache-First (Cache Falling Back to Network)

De service worker controleert eerst de cache. Als er een gecached antwoord bestaat, wordt dit onmiddellijk geretourneerd. Zo niet, dan gaat het verzoek naar het netwerk. Deze strategie levert de snelste TTFB voor gecachete resources, maar loopt het risico verouderde content te serveren.

Het beste voor: statische assets, afbeeldingen, lettertypen en content die niet vaak verandert.

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)

De service worker probeert altijd eerst het netwerk. Als het netwerkverzoek mislukt (bijv. de gebruiker is offline), wordt de gecachete versie geserveerd. Deze strategie garandeert verse content wanneer het netwerk beschikbaar is, maar verlaagt de TTFB voor online gebruikers niet.

Het beste voor: API responses, vaak bijgewerkte content en pagina's waar versheid cruciaal is.

Stale-While-Revalidate

De service worker retourneert onmiddellijk de gecachete versie (snelle TTFB) en haalt tegelijkertijd op de achtergrond een bijgewerkte versie van het netwerk op. De bijgewerkte versie vervangt de gecachete kopie voor het volgende bezoek. Dit is vaak de beste balans tussen snelheid en versheid.

Het beste voor: content die regelmatig verandert maar geen real time nauwkeurigheid vereist, zoals nieuwsartikelen, blogposts en productvermeldingen.

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 Configuratie

Hoewel het cache duration onderdeel van de TTFB specifiek de tijd meet die wordt besteed aan service worker en browser cache lookups, bepalen juiste Cache-Control headers of de browser überhaupt contact moet maken met de server. Correcte cache headers kunnen de volledige TTFB effectief omzeilen voor terugkerende bezoekers.

Hier is een aanbevolen Cache-Control configuratie voor verschillende soorten resources:

# HTML pages (always revalidate)
Cache-Control: no-cache

# Static assets with content hashing (cache forever)
Cache-Control: public, max-age=31536000, immutable

# Images without content hashing (cache for 1 week)
Cache-Control: public, max-age=604800

# API responses (no caching)
Cache-Control: no-store

Belangrijkste directives uitgelegd:

• no-cache: de browser moet revalideren met de server voordat een gecachete kopie wordt gebruikt. Dit betekent niet "niet cachen"; het betekent "altijd eerst controleren."
• no-store: de browser mag de response helemaal niet cachen. Gebruik dit voor gevoelige of zeer dynamische content.
• max-age: het aantal seconden dat de response vanuit de cache kan worden geserveerd zonder revalidatie.
• immutable: vertelt de browser dat de resource nooit zal veranderen. Combineer dit met content hashed bestandsnamen (bijv. style.a1b2c3.css) voor statische assets.
• public: staat toe dat de response wordt gecached door gedeelde caches (CDN, proxy). Gebruik private voor gebruikersspecifieke content.

Bij het gebruik van een CDN zoals Cloudflare, kun je ook edge caching regels configureren. Bekijk onze gids over hoe je Cloudflare voor prestaties kunt configureren voor gedetailleerde instructies.

Back/Forward Cache (bfcache)

De back/forward cache (bfcache) is een browser optimalisatie die een complete snapshot van een pagina in het geheugen opslaat wanneer de gebruiker wegnavegeert. Wanneer de gebruiker op de terug- of vooruitknop drukt, wordt de pagina onmiddellijk hersteld vanuit het geheugen, waardoor de TTFB (en elke andere laadmetriek) volledig wordt geëlimineerd.

Pagina's die vanuit de bfcache worden geserveerd, tonen een TTFB van 0 milliseconden in RUM data omdat er helemaal geen netwerkverzoek wordt gedaan. De browser herstelt eenvoudigweg de pagina vanuit de in-memory snapshot.

Om ervoor te zorgen dat je pagina's in aanmerking komen voor bfcache:

• Gebruik geen unload event listeners (gebruik in plaats daarvan pagehide).
• Gebruik geen Cache-Control: no-store op het HTML document.
• Sluit eventuele open IndexedDB verbindingen wanneer de pagina verborgen is.
• Houd geen actieve WebSocket of WebRTC verbindingen open (sluit ze in het pagehide event).

Je kunt de geschiktheid voor bfcache testen in Chrome DevTools onder het tabblad Application, in de sectie "Back/Forward Cache". Chrome zal eventuele redenen vermelden waarom de pagina niet in aanmerking kwam voor bfcache.

Voor sites met aanzienlijke terug/vooruit navigatiepatronen (bijv. e-commerce categorie- en productpagina's, zoekresultatenpagina's), kan bfcache de waargenomen TTFB drastisch verbeteren voor een groot deel van de navigaties.

Hoe Meet Je het Cache Duration Onderdeel van de Time to First Byte

Je kunt het cache duration onderdeel van de Time to First Byte meten met deze snippet:

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

  // get the relevant timestamps
  const activationStart = navigationEntry.activationStart || 0;
  const waitEnd = Math.max(
    (navigationEntry.workerStart || navigationEntry.fetchStart) -
    activationStart,
    0,
  );
  const dnsStart = Math.max(
    navigationEntry.domainLookupStart - activationStart,
    0,
  );

  // calculate the cache duration
  const cacheDuration = dnsStart - waitEnd;

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

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

Hoe Vind Je TTFB Problemen Veroorzaakt door een Hoge Cache Duration

Om de impact te vinden die echte gebruikers ervaren als gevolg van de cache duration, moet je een RUM tool zoals CoreDash gebruiken. Real User Monitoring stelt je in staat om de Core Web Vitals in groot detail te volgen.

Navigeer in CoreDash eenvoudigweg naar "Time to First Byte" en bekijk de breakdown details. Dit laat je de TTFB breakdown zien in al zijn onderdelen en vertelt je precies hoe lang de cacheDuration duurt voor het 75e percentiel.

Hoe de Impact van Service Worker Cache Tijd te Minimaliseren

Om de TTFB te optimaliseren bij het gebruik van Service Workers:

• Minimaliseer de complexiteit van Service Worker scripts om de opstarttijd te verlagen.
• Implementeer efficiënte caching strategieën binnen de Service Worker (geef de voorkeur aan stale-while-revalidate voor navigatieverzoeken).
• Overweeg het pre-cachen van kritieke resources tijdens de installatie van de Service Worker.
• Monitor en analyseer regelmatig de impact van Service Workers op de TTFB van je site.
• Gebruik navigation preload om het netwerkverzoek parallel te laten plaatsvinden met het opstarten van de service worker. Dit voorkomt dat de opstarttijd van de service worker wordt toegevoegd aan de TTFB.

Schakel navigation preload in je service worker in met:

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

Krijg de implementatie goed en service workers zullen je site versnellen voor terugkerende bezoekers. Krijg het verkeerd en elke paginalading betaalt de opstartkosten.

Verder Lezen: Optimalisatiegidsen

Gerelateerde gidsen:

• 103 Early Hints: begin met het laden van kritieke resources voordat het serverantwoord gereed is, als aanvulling op je caching strategie.
• Configureer Cloudflare voor Prestaties: stel CDN edge caching, cache regels en pagina regels in om je caching strategie op edge-niveau te optimaliseren.

TTFB Onderdelen: Complete Gidsen

De cache duration is een van de vijf onderdelen van de TTFB. Verken de andere onderdelen om het volledige plaatje te begrijpen:

• Identificeer en Los TTFB Problemen Op: het diagnostische startpunt voor alle TTFB optimalisatie.
• Waiting Duration: redirects, browser queuing en HSTS optimalisatie.
• DNS Duration: DNS provider selectie, TTL configuratie en dns-prefetch.
• Connection Duration: TCP handshake, TLS optimalisatie, HTTP/3 en preconnect.
• Request Duration: server verwerkingstijd, database queries en backend optimalisatie.