Verminder de cacheduur sub-onderdeel van de Time to First Byte

De cacheduur bestaat uit cache en worker lookups. Begrijp het sub-onderdeel van de TTFB om de totale time to first byte te verminderen

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-08

Verminder de cacheduur van de Time to First Byte

De Time to First Byte (TTFB) kan worden opgesplitst in de volgende subonderdelen:

  • Waiting + Redirect (of wachttijd)
  • Worker + Cache (of cacheduur)
  • DNS (of DNS-duur)
  • Connectie  (of connectieduur)
  • Request (of requestduur)

Wil je de Time to First Byte optimaliseren? Dit artikel biedt een diepgaande analyse van het wachttijdgedeelte van de Time to First Byte. Als je de time to first byte wilt begrijpen of oplossen en niet weet wat de wachttijd betekent, lees dan alsjeblieft wat is de time to first byte en time to first byte problemen vinden en oplossen voordat je aan dit artikel begint

Opmerking: meestal is het Cacheduur-gedeelte van de Time to Fist Byte geen knelpunt. Dus lees verder als a) je een service worker gebruikt, b) je een pagespeed-enthousiasteling bent zoals ik!

Het cacheDuration gedeelte van de time to first byte is de tijd tussen de wachttijd en de DNS lookup. Gedurende deze tijd zoekt de browser naar een match in de browsercache of de service worker cache. Wanneer Real User Monitoring (RUM) data een hoge cacheDuration laat zien,  kun je er vrij zeker van zijn dat de schuldige de opstarttijd en opzoektijd van de service worker is.

Meestal is het cacheduur-subonderdeel van de time to first byte geen knelpunt en vindt het plaats 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 een positieve en een negatieve impact hebben op de Time to First Byte (TTFB), maar alleen voor websites die Service Workers gebruiken. 

Hier is hoe service workers de TTFB mogelijk beïnvloeden:

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

Versnel de TTFB door caching: Door een cachingstrategie zoals stale-while-revalidate te gebruiken, kan een service worker content direct uit de cache serveren indien beschikbaar. Dit leidt tot een vrijwel directe TTFB voor veelbezochte resources, omdat de browser niet hoeft te wachten op een serverreactie. Deze strategie werkt alleen voor content die niet vaak wordt bijgewerkt, en niet voor dynamisch gegenereerde content die up-to-date informatie vereist.

Versnel de TTFB met app-shell: Voor client-gerenderde applicaties, het app-shell model, waarbij een service worker een basispaginastructuur uit de cache levert en later dynamisch content laadt, wordt de TTFB voor die basis bijna tot nul gereduceerd.

Vertraag de TTFB met niet-geoptimaliseerde code: Gecompliceerde en inefficiënte service workers kunnen het cache-opzoekproces vertragen en daardoor ook de TTFB vertragen.

Zijn service workers slecht voor pagespeed? Nee (meestal) zijn ze helemaal niet slecht! Hoewel Service Workers aanvankelijk 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.

Hoe meet je Cacheduur subonderdeel van de Time to First Byte

Je kunt het cacheduur-subonderdeel van de time to first byte meten met dit kleine fragment:

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

  // haal de relevante tijstempels op
  const activationStart = navigationEntry.activationStart || 0;
  const waitEnd = Math.max(
    (navigationEntry.workerStart || navigationEntry.fetchStart) -
    activationStart,
    0,
  );
  const dnsStart = Math.max(
    navigationEntry.domainLookupStart - activationStart,
    0,
  );

  // bereken de cacheduur
  const cacheDuration = dnsStart - waitEnd;

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

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

Hoe TTFB problemen veroorzaakt door een hoge cacheduur te vinden

Om de impact te vinden die echte gebruikers ervaren door cacheduur, zul je een RUM-tool zoals CoreDash moeten gebruiken. Real user monitoring laat je de Core Web Vitals tot in detail volgen.

In CoreDash navigeer je eenvoudig naar 'Time to First Byte' en bekijk je de breakdown details. Dit toont je de TTFB breakdown in al zijn subonderdelen en vertelt je precies hoe lang de cacheDuration duurt voor het 75e percentiel

ttfb coredash cacheduration breakdown/p>

Hoe minimaliseer je service worker cachetijd impact

Om TTFB te optimaliseren bij gebruik van Service Workers:

  • Minimaliseer de complexiteit van Service Worker scripts om de opstarttijd te verminderen.
  • Implementeer efficiënte cachingstrategieën binnen de Service Worker.
  • 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.

Door zorgvuldig de implementatie van de Service Worker te beheren en de impact op de TTFB te begrijpen, kunnen ontwikkelaars de initiële overhead balanceren met de voordelen op lange termijn die Service Workers bieden.

CrUX data is 28 days late.

Google provides data 28 days late. CoreDash provides data in real-time. Debug faster.

Get Real-Time Data >>

  • Real-Time Insights
  • Faster Debugging
  • Instant Feedback
Verminder de cacheduur sub-onderdeel van de Time to First ByteCore Web Vitals Verminder de cacheduur sub-onderdeel van de Time to First Byte