Wat is TTFB (Time to First Byte)?
TTFB staat voor Time to First Byte, oftewel de “tijd tot de eerste byte”. Het is de tijd die verstrijkt tussen het moment dat je browser een verzoek naar je website verstuurt en het moment dat de allereerste byte aan data van de server terugkomt. Met andere woorden: hoe snel reageert de webserver op een binnenkomend verzoek.
TTFB bestaat uit een paar onderdelen:
- Verzoek verzending: de tijd die nodig is om je HTTP-verzoek vanaf de browser naar de server te sturen. Dit hangt af van zaken als de netwerksnelheid van de gebruiker, de afstand tot de server en bijvoorbeeld de tijd voor een DNS-lookup.
- Serververwerking: de tijd die de server nodig heeft om het verzoek te verwerken en een reactie (pagina) te genereren. Hierbij horen stappen als het opstarten van PHP-processen, uitvoeren van databasequeries en het laden van benodigde data.
- Eerste byte terugzenden: de tijd die het kost om de eerste byte van de serverreactie naar de browser te sturen. Dit is vaak vrij kort, maar kan vertraagd worden door netwerkomstandigheden of server-upload snelheid.
In gewone taal kun je TTFB zien als de wachttijd voordat je site begint te laden. Het is dus niet de volledige laadtijd van de pagina, maar een indicator van de serverreactiesnelheid. Hoe korter de TTFB, hoe sneller de eerste hap informatie binnen is en hoe sneller de rest van de pagina kan volgen.
Hoe kun je TTFB meten?
Je hoeft gelukkig niet zelf met een stopwatch je server te timen – er zijn verschillende tools die de TTFB voor je meten. Zo geeft Google PageSpeed Insights een indicatie van de serverresponstijd (waar TTFB een onderdeel van is) en zul je bij een trage TTFB daar een melding krijgen zoals “Reduce initial server response time”. In de meeste performance tools (bijvoorbeeld GTmetrix, Pingdom of WebPageTest) zie je de TTFB terug in de watervaldiagram, vaak aangeduid als “Wait” of “TTFB” naast de eerste HTTP-aanvraag. Ook in de browser zelf kun je dit checken via de ontwikkelaarstools (Netwerk-tab in Chrome of Firefox) door te kijken naar de tijd bij de eerste response.
Belangrijk om te beseffen: de TTFB kan per meting verschillen, afhankelijk van waar en hoe er gemeten wordt. Een test vanaf een server in Amerika zal bijvoorbeeld een hogere TTFB geven voor een site die in Nederland gehost is (simpelweg door de fysieke afstand), terwijl een lokale test vanuit Nederland een lagere waarde laat zien. Daarom is het nuttig om TTFB niet als een enkel getal te zien, maar om trends en gemiddelde ervaringen van je gebruikers te bekijken.
Wat is een ‘hoge’ TTFB?
Wanneer is een TTFB te hoog? Er is geen vaststaande grens, maar wel richtlijnen en vuistregels. Een paar indicatieve waardes:
- Uitstekend (< ~200 ms): Dit betekent dat de server heel snel reageert. Google adviseert om idealiter onder ongeveer 200 milliseconden te blijven voor de beste ervaring.
- Gemiddeld (±300–500 ms): Veel WordPress-sites vallen in deze categorie. Het is niet razendsnel, maar ook niet uitzonderlijk traag. Voor een dynamische site is dit vaak een prima uitgangspunt.
- Langzaam (> ~600 ms): Zit je TTFB boven de halve seconde, dan begint het traag te worden. Bij ~600 ms of meer zal een tool als PageSpeed Insights een waarschuwing geven dat de serverrespons moet worden verbeterd. Een TTFB die richting 1 seconde of hoger gaat, is duidelijk een knelpunt dat aandacht vereist.
Let op dat dit algemene richtlijnen zijn. Een grote WooCommerce-webshop of site met veel dynamische content kan wat hogere TTFB-tijden hebben simpelweg doordat de server meer werk moet doen bij elke pagina-opvraag. Omgekeerd kan een eenvoudige statische website of een goed gecachte pagina een extreem lage TTFB halen. Beschouw de TTFB daarom altijd in de context van je site: zie het als een signaal om te onderzoeken of er vertraging in de serverreactie zit die je bezoekers mogelijk merken.
Waardoor kan een TTFB hoog zijn?
Als je TTFB aan de hoge kant is, wat zou daar dan achter kunnen zitten? Enkele veelvoorkomende oorzaken in de praktijk:
- Je hosting en serverkracht: De kwaliteit en inrichting van je hosting hebben grote invloed. Op shared hosting (gedeelde servers) waar veel websites om dezelfde resources vechten, zie je vaak hogere TTFB-waarden. Een kleine server die overbelast is of draait op verouderde software (bijvoorbeeld een oude PHP-versie) reageert nu eenmaal trager. Een VPS of managed hosting kan betere prestaties geven, maar ook daar geldt dat als de server niet goed is geoptimaliseerd of als hij vol draait, de TTFB zal stijgen.
- Geen caching (dynamische pagina’s): WordPress genereert pagina’s dynamisch via PHP en database-vragen. Als elke bezoeker de pagina telkens live moet laten genereren, kost dat tijd bij elke load. Zonder caching (zoals een page cache plugin of server-side caching) moet de server voor iedere bezoeker opnieuw alle berekeningen doen, wat de TTFB flink verhoogt. Met caching kan WordPress juist een statische versie van de pagina teruggeven, waardoor de server veel minder werk heeft en de eerste byte sneller bij de bezoeker is.
- Zware plugins of thema’s: Niet alle WordPress-sites zijn gelijk. Gebruik je bijvoorbeeld een uitgebreide WooCommerce-webshop, een page builder als Elementor of Divi, of veel plugins die complexe functies uitvoeren, dan moet de server per pageload meer doen. Zo’n webshop doet bijvoorbeeld databasevragen voor producten, winkelwageninhoud, etc. Een page builder-thema kan enorm veel content en code moeten opbouwen. Dit vertaalt zich in een langere serververwerkingstijd en dus een hogere TTFB, zeker zonder optimalisaties.
- Drukte en verkeerspieken: Als je site het ineens erg druk heeft (bijvoorbeeld tijdens een marketingactie of seizoenspiek) kan de server onder de load trager reageren. Veel gelijktijdige verzoeken zorgen ervoor dat elk verzoek langer moet wachten. Hetzelfde geldt als er zware achtergrondprocessen draaien (bijvoorbeeld backups of imports) – de server is dan even minder responsief voor normale bezoekers.
- Netwerk en afstand: Soms ligt het niet aan WordPress of de server zelf, maar aan de afstand tussen de gebruiker en de server. Als jouw websitehosting in Europa staat en een bezoeker bekijkt de site vanuit Azië of Amerika, duurt het fysiek langer voordat data die kant op en terug is. Die netwerklatentie verhoogt de gemeten TTFB. Ook DNS-resolutie of eventuele omleidingen (redirects) kunnen een kleine vertraging toevoegen vóór de eerste byte. Dit is op te vangen met bijvoorbeeld een CDN (Content Delivery Network) om content dichter bij de gebruiker te brengen, maar het is goed om te beseffen dat niet elke “hoge TTFB” direct betekent dat je server slecht is – soms speelt afstand een rol.
TTFB en Core Web Vitals (LCP en andere metrics)
Je hebt misschien gehoord van Core Web Vitals, de metrics die Google gebruikt om de gebruikerservaring van websites te beoordelen (waaronder bijvoorbeeld Largest Contentful Paint (LCP), First Input Delay (FID) en Cumulative Layout Shift (CLS)). Opvallend genoeg hoort TTFB niet bij deze officiële kernmetrics. Toch heeft TTFB wel degelijk invloed op die andere statistieken.
Denk aan Largest Contentful Paint (LCP): dit meet hoe lang het duurt voordat het grootste contentelement van een pagina zichtbaar is. Als je server er bijvoorbeeld 800 milliseconden over doet om de eerste byte te leveren, kan de LCP nooit lager zijn dan die ~0,8 seconde plus de extra tijd om de content te laden. Met andere woorden, een trage TTFB duwt alle daaropvolgende tijden naar boven. Ook First Contentful Paint (FCP) – het moment waarop de eerste content verschijnt – wordt direct vertraagd door een hoge TTFB, omdat de browser pas iets kán tonen nadat die eerste byte binnen is.
Google’s Page Experience update gebruikt LCP als een rankingfactor in zoekresultaten. Indirect betekent dit dat een hoge TTFB (die je LCP verslechtert) ook je SEO kan schaden. Google adviseert websites om de serverresponstijd onder de ~0,6 s te houden om een goede FCP/LCP te faciliteren. In PageSpeed Insights zie je daarom de aanbeveling om de “Initial server response time” te verbeteren als je TTFB te traag is.
TTFB als diagnostisch signaal
Ik raad mijn klanten altijd aan om TTFB te zien als een diagnostisch signaal en niet als een op zichzelf staand doel om koste wat kost te verbeteren. Wat betekent dat? Kort gezegd: een lage TTFB is mooi, maar uiteindelijk gaat het erom hoe snel de gebruiker daadwerkelijk iets nuttigs op het scherm ziet en kan doen.
Stel, je hebt je front-end goed geoptimaliseerd (afbeeldingen gecomprimeerd, CSS/JS verkleind, etc.) maar je site voelt nog steeds traag aan. Kijk dan eens naar de TTFB: is deze erg hoog, dan wijst dat op vertraging aan de serverkant (bijvoorbeeld trage databasequeries of onvoldoende servercapaciteit). In dat geval is het zinvol om server-optimalisaties te doen of je hostingconfiguratie te verbeteren. Aan de andere kant, als je TTFB lekker laag is (zeg rond 200 ms) maar de pagina laadt alsnog pas na 3 seconden volledig door enorme afbeeldingen of zware scripts, dan ligt het knelpunt niet bij de serverreactie. Dan heeft het weinig zin om te proberen die TTFB nóg verder omlaag te brengen; je aandacht kun je beter richten op wat na die eerste byte komt.
Met andere woorden: gebruik TTFB als een aanwijzing. Een hoge TTFB betekent meestal dat er aan de “achter de schermen”-kant van je WordPress-site iets aandacht nodig heeft (hosting, queries, caching). Een lage TTFB betekent dat de basis goed is, maar garandeert nog geen supersnelle site – daarvoor moeten ook de daaropvolgende elementen snel laden. Uiteindelijk is TTFB één van de vele onderdelen van website-prestaties. Het is belangrijk om het in balans te zien met andere factoren voor een volledig beeld.
Samenvatting
Kort samengevat: Time to First Byte (TTFB) is de meetwaarde voor hoe snel jouw server de eerste byte naar de browser stuurt. Een hoge TTFB duidt op een trage serverreactie, wat de laadtijd van je pagina’s negatief beïnvloedt en doorwerkt in metrics als LCP. Factoren zoals je hostingkeuze, (gebrek aan) caching, plugin-zwaarte en verkeer kunnen de TTFB aanzienlijk beïnvloeden. Zie TTFB vooral als een nuttige aanwijzing: als het hoog is, geeft het aan dat er aan de server- of backendkant optimalisatie mogelijk is. Uiteindelijk wil je een snelle totaalervaring voor de gebruiker – een lage TTFB helpt daarbij, maar het is één onderdeel van het geheel.