Time to First Byte (TTFB) Problemen Identificeren & Oplossen

Vind en Los Time to First Byte (TTFB) Problemen Op

Dit artikel is onderdeel van onze Time to First Byte (TTFB) gids. TTFB is een diagnostische metriek die de tijd meet tussen het opvragen van een pagina door een gebruiker en het ontvangen van de eerste byte van de response door de browser. Hoewel TTFB zelf geen Core Web Vitals is, heeft het direct invloed op zowel First Contentful Paint (FCP) als Largest Contentful Paint (LCP). Een goede TTFB is onder de 800 milliseconden in het 75e percentiel.

In ons vorige artikel spraken we over de Time to First Byte. Als u de basis wilt doorlezen, is dat een geweldig beginpunt.

In dit artikel zullen we ons richten op het identificeren van de verschillende Time to First Byte problemen en vervolgens uitleggen hoe u deze kunt oplossen.

TTFB TIP: meestal zal de TTFB veel slechter zijn voor nieuwe bezoekers omdat zij geen DNS-cache voor uw site hebben. Bij het tracken van de TTFB is het erg zinvol om onderscheid te maken tussen nieuwe en terugkerende bezoekers.

Stap 1: Controleer de TTFB in Search Console

"De eerste stap naar herstel is toegeven dat je een probleem hebt." Dus voordat we iets doen om de Time to First Byte te verhelpen, laten we er zeker van zijn dat we echt een probleem hebben met de TTFB.

Helaas wordt de Time to First Byte niet gerapporteerd in Google Search Console, dus we moeten terugvallen op pagespeed.web.dev om de CrUX-data van onze site op te vragen. Gelukkig zijn de stappen eenvoudig: navigeer naar pagespeed.web.dev, voer de URL van uw pagina in en zorg ervoor dat de knop "origin" is aangevinkt (aangezien we site-brede data nodig hebben en niet alleen homepage-data). Schakel nu tussen Mobiel en Desktop en controleer de Time to First Byte voor beide apparaattypen.

In het onderstaande voorbeeld ziet u een site die niet aan de Core Web Vitals voldoet vanwege een hoge TTFB.

Stap 1b: Gebruik de Server-Timing Header voor Dieper Inzicht

De Server-Timing HTTP response header stelt uw server in staat om backend performance-metrieken direct naar de browser te communiceren. Dit maakt het mogelijk om precies aan te wijzen welk deel van de serververwerking traag is, zonder dat u toegang tot serverlogs nodig heeft.

Een typische Server-Timing header ziet er als volgt uit:

Server-Timing: db;dur=53, app;dur=120, cache;desc="miss"

In dit voorbeeld rapporteert de server drie timingwaarden:

• db;dur=53: de database query duurde 53 milliseconden.
• app;dur=120: de applicatielogica (template rendering, API calls, etc.) duurde 120 milliseconden.
• cache;desc="miss": de servercache is niet gebruikt voor dit verzoek (een cache miss).

U kunt deze waarden aflezen in Chrome DevTools door het Network tabblad te openen, het documentverzoek te selecteren en naar de "Server Timing" sectie in het Timing tabblad te scrollen. De waarden zijn ook toegankelijk via de PerformanceServerTiming API in JavaScript:

const [navigation] = performance.getEntriesByType('navigation');
if (navigation.serverTiming) {
  navigation.serverTiming.forEach(entry => {
    console.log(`${entry.name}: ${entry.duration}ms (${entry.description})`);
  });
}

Als uw server nog geen Server-Timing headers verstuurt, overweeg dan om deze toe te voegen. De meeste webframeworks maken dit eenvoudig. In PHP kunt u de header toevoegen vóór enige output:

header('Server-Timing: db;dur=' . $dbTime . ', app;dur=' . $appTime);

In Node.js met Express:

res.setHeader('Server-Timing', `db;dur=${dbTime}, app;dur=${appTime}`);

De Server-Timing header is bijzonder nuttig in combinatie met Real User Monitoring, omdat u hiermee server side performance kunt correleren met de TTFB die echte gebruikers ervaren. Leer meer over hoe 103 Early Hints de waargenomen TTFB verder kan verlagen door resource hints te sturen voordat de volledige response klaar is.

Stap 2: Stel RUM Tracking in

De Time to First Byte is een lastige metriek. We kunnen niet simpelweg vertrouwen op synthetische tests om de TTFB te meten, omdat in het echte leven andere factoren zullen bijdragen aan fluctuaties in de TTFB. Om antwoorden te krijgen op alle bovenstaande vragen, moeten we de data in de praktijk meten en eventuele problemen loggen die zich kunnen voordoen met de Time to First Byte. Dit wordt Real User Monitoring genoemd, en er zijn verschillende manieren om RUM tracking in te schakelen. Wij hebben CoreDash speciaal voor deze use cases ontwikkeld. CoreDash is een voordelige, snelle en effectieve RUM tool die de klus klaart. Natuurlijk zijn er veel RUM oplossingen op de markt en die zullen ook de klus klaren (hoewel tegen een hogere prijs).

Hoe u over TTFB moet denken: Stel u voor dat een webserver de keuken van een restaurant is, en een gebruiker die een webpagina opvraagt een hongerige klant is die een bestelling plaatst. Time to First Byte (TTFB) is de tijdspanne tussen het plaatsen van de bestelling door de klant en het moment dat de keuken begint met het bereiden van het eten.
Dus de TTFB gaat NIET over hoe snel de hele maaltijd wordt gekookt (First Contentful Paint) en geserveerd (Largest Contentful Paint), maar eerder over hoe responsief de keuken is op het initiële verzoek.
RUM Tracking is vergelijkbaar met het ondervragen van de klanten om hun eetervaring te begrijpen. U komt er misschien achter dat klanten die verder van de keuken zitten minder aandacht krijgen van de ober en later bediend worden, of dat terugkerende klanten een voorkeursbehandeling krijgen terwijl nieuwe bezoekers langer op een tafel moeten wachten.

Stap 2b: Bepaal een Performance Baseline

Voordat u wijzigingen aanbrengt, bepaalt u een baseline voor uw TTFB. Noteer de TTFB van het 75e percentiel over de volgende dimensies, aangezien dit u zal helpen de effectiviteit van uw optimalisaties later te meten:

1. Algehele TTFB (mobiel en desktop afzonderlijk): leg het 75e percentiel vast voor elk apparaattype.
2. Top 10 pagina's op basis van verkeer: noteer de TTFB voor uw best bezochte pagina's afzonderlijk.
3. Nieuwe bezoekers vs. terugkerende bezoekers: nieuwe bezoekers hebben doorgaans een hogere TTFB vanwege DNS- en connection overhead.
4. Top 5 landen op basis van verkeer: geografische afstand tot uw server beïnvloedt de TTFB aanzienlijk.
5. TTFB sub-part breakdown: noteer het 75e percentiel voor elke sub-part (waiting, cache, DNS, connection, request).

Documenteer deze cijfers in een spreadsheet. Wacht na het implementeren van elke optimalisatie ten minste 7 dagen om genoeg RUM data te verzamelen voordat u de resultaten vergelijkt. Een goede aanpak is om één TTFB sub-part tegelijk aan te pakken, te meten en dan door te gaan naar de volgende.

Stap 3: Identificeer Time to First Byte Problemen

Hoewel Google's Chrome User Experience Report (CrUX) waardevolle velddata biedt, levert het geen specifieke details over de oorzaken van een hoge TTFB. Om de TTFB effectief te verbeteren, moeten we exact weten wat er op een meer gedetailleerd niveau aan de hand is. Op dit punt is het zinvol om onderscheid te maken tussen een algeheel falende TTFB en een TTFB die onder specifieke omstandigheden faalt (hoewel er in de realiteit altijd sprake zal zijn van een mix).

3.1 TTFB Faalt in het Algemeen

1. Controleer op over het algemeen slechte "request times": Slechte request times betekent dat het "probleem" ligt bij de tijd die de server nodig heeft om de pagina te genereren. Dit is de meest voorkomende oorzaak van slechte TTFB scores.
2. Controleer op andere slechte TTFB sub-parts: De TTFB is niet zomaar één enkele metriek, maar kan worden opgesplitst in meerdere delen die elk hun eigen optimalisatiepotentieel hebben. Als de waiting duration, cache duration, DNS lookup duration, of de connection duration traag zijn, zult u waarschijnlijk uw serverinstellingen moeten afstemmen of op zoek moeten gaan naar hosting van betere kwaliteit.

3.2 TTFB Faalt Onder Specifieke Omstandigheden

1. Landsegmentatie: Inzicht in de geografische distributie van een hoge TTFB is belangrijk, vooral voor websites met een wereldwijd publiek. Als u uw pagina's vanaf één server in slechts één land serveert (zonder CDN edge caching), zal de fysieke afstand tussen de locatie van de gebruiker en de server die de website host allerlei vertragingen veroorzaken en de TTFB beïnvloeden. Overweeg Cloudflare te configureren of een ander CDN om uw content dichter bij gebruikers wereldwijd te brengen.
   
2. Cache segmentatie: Caching kan de TTFB verlagen door de server side generatie van de HTML over te slaan. Helaas komt het vaak voor dat caching om verschillende redenen is uitgeschakeld of wordt overgeslagen. Caching kan bijvoorbeeld worden uitgeschakeld voor ingelogde gebruikers, winkelwagenpagina's, pagina's met query strings (bijv. van Google Ads), zoekresultaatpagina's en afrekenpagina's. Als uw website (edge) caching gebruikt, gebruik dan RUM tracking om de cache hit ratio te controleren.
   
3. Pagina (cluster) segmentatie: Het verschil in Time to First Byte performance (of het gebrek aan verschil) tussen pagina's of paginatypes is iets anders dat we moeten vaststellen. Weten welke pagina's falen op de TTFB metriek geeft waardevolle inzichten in hoe de Time to First Byte verbeterd kan worden.
   
4. Redirect segmentatie: Redirect time wordt direct aan de TTFB toegevoegd. Elke redirect voegt extra tijd toe voordat de webserver kan beginnen met het laden van de pagina. Het meten en elimineren van onnodige redirects kan helpen om de TTFB te verbeteren. Voor een diepgaandere blik op redirect optimalisatie, bekijk onze gids over de waiting duration sub-part van de TTFB.
   
5. Andere segmentatie: Hoewel segmenteren op de bovenstaande variabelen de gebruikelijke verdachten dekt, is elke site uniek en heeft deze zijn eigen uitdagingen. Gelukkig is RUM tracking ontworpen om segmentatie mogelijk te maken op veel meer variabelen zoals Device RAM, Netwerksnelheid, Apparaattype, Besturingssysteem, custom variabelen en nog veel meer.

Stap 4: Zoom in op Problemen en Los ze Op

De sub-parts van de Time to First Byte (TTFB) zijn:

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

Stap 5: Quick Fix Checklist voor Veelvoorkomende TTFB Problemen

Gebaseerd op de sub-part die het meest bijdraagt aan uw TTFB, is hier een snelle referentie voor de meest voorkomende oplossingen:

TTFB Meten met JavaScript

U kunt de volledige TTFB en zijn sub-parts direct in de browser meten met behulp van de Navigation Timing API. De volgende snippet berekent de TTFB en logt elke sub-part:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const activationStart = nav.activationStart || 0;

  const ttfb = nav.responseStart - activationStart;
  const waitingDuration = (nav.workerStart || nav.fetchStart) - activationStart;
  const cacheDuration = nav.domainLookupStart - (nav.workerStart || nav.fetchStart);
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;
  const connectionDuration = nav.connectEnd - nav.connectStart;
  const requestDuration = nav.responseStart - nav.requestStart;

  console.log('TTFB:', ttfb.toFixed(0), 'ms');
  console.log('  Waiting:', waitingDuration.toFixed(0), 'ms');
  console.log('  Cache:', cacheDuration.toFixed(0), 'ms');
  console.log('  DNS:', dnsDuration.toFixed(0), 'ms');
  console.log('  Connection:', connectionDuration.toFixed(0), 'ms');
  console.log('  Request:', requestDuration.toFixed(0), 'ms');
}).observe({
  type: 'navigation',
  buffered: true
});

Deze code biedt dezelfde breakdown die tools zoals CoreDash weergeven in het TTFB attributiepaneel. Het draaien van deze snippet in de browserconsole geeft u een directe meting voor één enkele page load, terwijl RUM tools deze data verzamelen over duizenden echte gebruikers om betrouwbare 75e percentiel waarden te produceren.

Verder Lezen: Optimalisatie Gidsen

Gerelateerde gidsen:

• 103 Early Hints: stuur resource hints voordat de volledige response klaar is, zodat de browser kan beginnen met het laden van kritieke resources terwijl de server nog aan het verwerken is.
• Configureer Cloudflare voor Performance: stel Cloudflare's CDN, caching en edge-functies in om de TTFB te verlagen voor een wereldwijd publiek.

TTFB Sub-parts: Complete Gidsen

Elke sub-part van de Time to First Byte heeft zijn eigen optimalisatiestrategieën. Begin met de sub-part die uw RUM data identificeert als de bottleneck:

• Waiting Duration: redirects, browser queuing en HSTS optimalisatie.
• Cache Duration: service worker performance, browsercache en bfcache.
• 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.