Wat is de Time To First Byte (TTFB) en hoe verbeter je deze

Time to First Byte (TTFB) meet de tijd in milliseconden tussen het moment dat de browser een pagina opvraagt en het ontvangen van de eerste byte van het antwoord van de server. Een goede TTFB is 800 milliseconden of minder op het 75e percentiel. TTFB is geen Core Web Vital, maar het is een cruciale diagnostische metric omdat het direct invloed heeft op zowel Largest Contentful Paint (LCP) als First Contentful Paint (FCP).

Wat is de Time to First Byte

De Time to First Byte (TTFB) geeft aan hoeveel tijd er in milliseconden is verstreken tussen het starten van het verzoek en het ontvangen van het eerste antwoord (byte) van een webpagina. De TTFB wordt daarom ook wel de wachttijd genoemd. De TTFB is een manier om de responsiviteit van een webserver en het netwerkpad tussen de gebruiker en die server te meten. De TTFB is een fundamentele metric; dit betekent dat tijd die aan de TTFB wordt toegevoegd ook wordt toegevoegd aan de Largest Contentful Paint en de First Contentful Paint. Elke milliseconde die op TTFB wordt bespaard, is een milliseconde bespaard op beide paint-metrics.

TTFB is geen Core Web Vital

Het is belangrijk om dit duidelijk te stellen: TTFB is niet een van de drie Core Web Vitals. De Core Web Vitals bestaan uit Largest Contentful Paint (LCP), Interaction to Next Paint (INP) en Cumulative Layout Shift (CLS). Google gebruikt TTFB niet direct in zijn page experience-rankingsignalen.

TTFB wordt echter geclassificeerd als een diagnostische metric. Het helpt je te begrijpen waarom je LCP of FCP traag kan zijn. Volgens de 2025 Web Almanac besteden sites met slechte LCP gemiddeld 2,27 seconden aan TTFB alleen, wat bijna de volledige LCP-drempel van 2,5 seconden uitput voordat de browser zelfs maar begint met het renderen van de pagina. Het verbeteren van TTFB is daarom een van de meest impactvolle dingen die je kunt doen voor je algehele Core Web Vitals-scores.

Waarom is Time to First Byte belangrijk

De Time to First Byte is geen Core Web Vital en het is zeer goed mogelijk om de Core Web Vitals te halen terwijl je de TTFB-metric niet haalt. Dat betekent niet dat de TTFB niet belangrijk is. De TTFB is een uiterst belangrijke metric om te optimaliseren en het verbeteren van de TTFB zal de paginasnelheid en de paginabeleving aanzienlijk verbeteren.

De impact van TTFB voor bezoekers

De Time to First Byte gaat vooraf aan alle andere paint-metrics. Terwijl de browser wacht op de Time to First Byte kan deze niets doen en toont alleen een leeg scherm. Dit betekent dat elke toename in Time to First Byte resulteert in extra "leeg scherm"-tijd en elke afname in de Time to First Byte zich vertaalt in minder "leeg scherm"-tijd.

Om dat gevoel van instant ladende pagina's te krijgen, moet de Time to First Byte zo snel mogelijk zijn.

Waarom is de TTFB geen Core Web Vital? TTFB houdt geen rekening met rendering: een lage TTFB betekent niet noodzakelijk een goede gebruikerservaring omdat het geen rekening houdt met de tijd die de browser nodig heeft om de webpagina te renderen. Zelfs als alle bytes snel zijn gedownload, kan de webpagina nog lang duren om weer te geven als de browser veel JavaScript moet verwerken of complexe layouts moet renderen.

Wat is een goede TTFB-score?

Het wordt aanbevolen dat je server snel genoeg reageert op navigatieverzoeken zodat het 75e percentiel van gebruikers een FCP binnen de "goed"-drempel ervaart. Als vuistregel geldt dat de meeste sites moeten streven naar een TTFB van 0,8 seconden of minder.

• Een TTFB onder 800 milliseconden wordt als goed beschouwd.
• Een TTFB tussen 800 en 1800 milliseconden heeft verbetering nodig.
• Een TTFB boven 1800 milliseconden wordt als slecht beschouwd en moet onmiddellijk verbeterd worden.

Impact in de praktijk: de T-Mobile casestudy

T-Mobile investeerde flink in het verlagen van hun Time to First Byte als onderdeel van een breder prestatie-optimalisatie-initiatief. De resultaten waren opvallend: een toename van 60% in bezoek-naar-bestelling-conversies. Door over te stappen naar edge-gerenderde pagina's en agressieve server-side caching, verkleinde T-Mobile drastisch de tijd die gebruikers moesten wachten op de eerste byte, wat doorwerkte in snellere LCP, snellere FCP en een meetbaar betere gebruikerservaring. Deze casestudy laat zien dat TTFB-optimalisatie niet slechts een technische oefening is; het heeft direct invloed op bedrijfsresultaten.

De TTFB van verzoek tot antwoord

Van browser naar server: het verzoek

De browserverzoekvijd is de tijd die is verstreken vanaf het moment dat de browser van een gebruiker een HTTP-verzoek verstuurt tot dat verzoek de server bereikt die de website host. De TTFB van dit deel valt grotendeels buiten de directe controle van de website en hangt sterk af van:

• De internetsnelheid van de gebruiker.
• De kwaliteit van hun netwerkinfrastructuur.
• De fysieke afstand tussen de gebruiker en de server.

Binnen deze fase nemen DNS-lookup, opstartijd van de browser, cache-lookups in de browser en het opzetten van de verbinding met de server (TCP en TLS) allemaal wat tijd in beslag.

Op de server: verwerking en voorbereiding van het antwoord

Zodra de server het verzoek ontvangt, tikt de klok terwijl deze een antwoord genereert. Deze fase is waar de meeste ontwikkelaars zich op richten en waar optimalisatie-inspanningen de meeste impact kunnen hebben. Factoren om rekening mee te houden zijn:

• Servercapaciteit: Krachtige hardware (CPU, RAM), efficiënte software (webserver, database) en geoptimaliseerde configuraties zijn allemaal van belang.
• Databaseduur: Als het verzoek gegevens uit een database moet ophalen, kunnen trage query's een groot knelpunt zijn.
• Code-optimalisatie: Slecht geschreven server-side code (bijv. inefficiënte scripts) kan leiden tot lange verwerkingstijden.
• Cachingstrategieën: Effectieve caching (zoals server-side caching of het gebruik van een Content Delivery Network) kan de verwerkingslast voor herhaalde verzoeken drastisch verminderen.

Terug naar de browser: de eerste byte afleveren

Na verwerking stuurt de server het antwoord, beginnend met de eerste byte, terug naar de browser van de gebruiker.

• Net als in de eerste fase spelen netwerkcondities en afstand hier ook een rol.
• CDN's zijn in deze fase bijzonder nuttig omdat ze content dichter bij gebruikers cachen, waardoor de reistijd wordt geminimaliseerd.
• Redirects worden op dit punt afgehandeld, waardoor het proces zichzelf herhaalt met een extra vertraging.

Technische fasen van de Time To First Byte

Vergelijkbaar met het "verzoek-naar-antwoord-pad" in je browser, kan de Time To First Byte van navigatieverzoeken worden gemeten met de Navigation Timing API en worden opgedeeld in 5 subdelen.

1. Redirecttijd: wanneer een resource is verplaatst naar een nieuwe locatie wordt de redirecttijd toegevoegd aan de TTFB van de resource.
2. Worker- en cachetijd: voordat een resource van het internet wordt opgehaald, zal een browser deze eerst proberen op te zoeken in zijn eigen cache of via een worker (als een worker is ingesteld).
3. DNS-lookuptijd: Vervolgens moet een browser mogelijk een DNS-lookup uitvoeren om de domeinnaam (www.example.com) te vertalen naar een IP-adres.
4. TCP-verbindingstijd: Daarna maakt de browser verbinding met de server en voert enkele controles uit.
5. SSL-handshake: Vervolgens versleutelen de browser en de server hun communicatie.
6. Serverantwoord: Ten slotte moet de server de HTML verzenden. Mogelijk moet de HTML eerst worden gegenereerd.

Hoe de Time To First Byte (TTFB) te meten

PageSpeed TIP: elke resource heeft zijn eigen Time to First Byte. In deze context hebben we het echter over de Time to First Byte van de hoofdpagina.

De Time to First Byte kan sterk fluctueren tussen verschillende gebruikers met verschillende apparaten en vanaf verschillende locaties. Daarom is het zelf meten van de Time to First Byte vanaf je desktopcomputer waarschijnlijk geen goed idee. Het gebruik van tools zoals Pingdom of GTMetrix is om dezelfde reden niet betrouwbaar.

De beste manier om de Time To First Byte te meten is door Real User Metrics (RUM)-data van je bezoekers te verzamelen. Je kunt dit zelf doen met onderstaande code of een RUM-tool gebruiken zoals CoreDash.

TTFB meten met synthetische tools

TTFB meten met RUM-tracking

TTFB meten met CrUX-data

CrUX (Chrome User Experience Report) is een openbaar beschikbare dataset van Google die prestatie-data van echte gebruikers voor websites bevat. Google gebruikt de CrUX-dataset om te bepalen of je al dan niet de Core Web Vitals haalt.

De CrUX-dataset is toegankelijk via tools zoals PageSpeed Insights, de CrUX API, Looker Studio of Google BigQuery. Gebruik een van deze tools om de TTFB voor je site te bekijken.

TTFB meten met JavaScript

Om de Time to First Byte (TTFB) te meten met JavaScript, kun je de Navigation Timing API gebruiken. Je kunt een PerformanceObserver aanmaken die luistert naar een navigation entry en de responseStart-eigenschap naar de console logt. De responseStart-eigenschap vertegenwoordigt het tijdstempel waarop de eerste byte van het antwoord werd ontvangen. De web-vitals JavaScript-bibliotheek biedt een beknoptere manier om TTFB in de browser te meten met de onTTFB-functie.

De onderstaande code kan worden gebruikt om de Time To First Byte (TTFB) te meten:

const formatTime = (time) => {

//round by 2 decimals, use Math.round() for integer
return Math.round(time * 100) / 100;
};

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

// timing start times are relative
const activationStart = pageNav.activationStart || 0;
const workerStart = Math.max(pageNav.workerStart - activationStart, activationStart);
const dnsStart = Math.max(pageNav.domainLookupStart - activationStart, workerStart);
const tcpStart = Math.max(pageNav.connectStart - activationStart, dnsStart);
const sslStart = Math.max(pageNav.secureConnectionStart - activationStart, tcpStart);
const requestStart = Math.max(pageNav.requestStart - activationStart, sslStart);
const responseStart = Math.max(pageNav.responseStart - activationStart, requestStart);

// attribution based on https://www.w3.org/TR/navigation-timing-2/#processing-model
// use associative array to log the results more readable
let attributionArray = [];
attributionArray['Redirect Time'] = { 'time in ms': formatTime(workerStart - activationStart) };
attributionArray['Worker and Cache Time'] = { 'time in ms': formatTime(dnsStart - workerStart) };
attributionArray['DNS Time'] = { 'time in ms': formatTime(tcpStart - dnsStart) };
attributionArray['TCP Time'] = { 'time in ms': formatTime(sslStart - tcpStart) };
attributionArray['SSL Time'] = { 'time in ms': formatTime(requestStart - sslStart) };
attributionArray['Request Time'] = { 'time in ms': formatTime(responseStart - requestStart) };
attributionArray['Total TTFB'] = { 'time in ms': formatTime(responseStart - activationStart) };

// log the results
console.log('%cTime to First Byte (' + formatTime(responseStart - activationStart) + 'ms)', 'color: blue; font-weight: bold;');
console.table(attributionArray);

console.log('%cOrigininal navigation entry', 'color: blue; font-weight: bold;');
console.log(pageNav);

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

Knelpunten vinden met de Server-Timing API

De Server-Timing API biedt een gestandaardiseerde manier om backend-serverprestatietijden naar de browser te sturen. Door Server-Timing headers te gebruiken, kunnen ontwikkelaars effectief de server-side componenten meten en analyseren die bijdragen aan de TTFB, waardoor optimalisatiegebieden worden geïdentificeerd en de algehele websiteprestaties worden verbeterd.

De Server-Timing-header kan tijden voor meerdere metrics bevatten, gescheiden door komma's. Elke vermelding bestaat uit:

• Een korte naam voor de metric (zoals database en processing)
• Een duur in milliseconden (uitgedrukt als dur=123)
• Een optionele beschrijving (uitgedrukt als desc="My Description")

Server-Timing: database;dur=123;desc="DB Query", processing;dur=234;desc="Template Render", cache;dur=0;desc="Cache HIT"

Server-Timing lezen in Chrome DevTools

Chrome DevTools toont Server-Timing-vermeldingen direct in het Network-paneel. Open DevTools, selecteer het documentverzoek in het Network-tabblad, scroll naar de sectie "Server Timing" in het Timing-tabblad. Elke metric die je via de Server-Timing-header verstuurt, verschijnt met naam, beschrijving en duur. Dit maakt het eenvoudig om te identificeren of je database, template-rendering of cachinglaag het knelpunt is.

Je kunt de Server-Timing-header ook programmatisch lezen en deze tijden naar je favoriete RUM-tool zoals CoreDash sturen voor langetermijntracking en alerting.

TTFB versnellen met 103 Early Hints

103 Early Hints is een HTTP-statuscode waarmee de server voorlopige response headers naar de browser kan sturen voordat het definitieve antwoord klaar is. Terwijl de server nog bezig is met het verwerken van het verzoek (query's uitvoeren op de database, het template renderen), kan de browser alvast beginnen met het laden van kritieke resources zoals stylesheets, fonts en de LCP-afbeelding.

Hoe 103 Early Hints werkt

Bij een traditionele verzoekstroom zit de browser inactief te wachten gedurende de gehele serververwerkingstijd. Met 103 Early Hints stuurt de server onmiddellijk een gedeeltelijk antwoord na ontvangst van het verzoek. Dit gedeeltelijke antwoord bevat Link-headers die de browser vertellen welke resources moeten worden voorgeladen of waarmee een preconnect moet worden gemaakt. De browser handelt naar deze hints terwijl deze wacht op het volledige 200-antwoord.

Dit verandert in feite dode wachttijd in productieve laadtijd. Hoewel 103 Early Hints de TTFB van het document zelf niet verlaagt, vermindert het de waargenomen impact van TTFB op volgende metrics zoals LCP en FCP door de browser een voorsprong te geven bij het ontdekken van resources.

Serverconfiguratie-voorbeeld voor 103 Early Hints

Veel CDN's en webservers ondersteunen nu 103 Early Hints. Hier is een voorbeeld met Cloudflare, dat automatisch 103 Early Hints genereert op basis van Link-headers en preload/preconnect-tags die in je HTML worden gevonden:

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </static/img/hero.webp>; rel=preload; as=image
Link: <https://fonts.googleapis.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html
...

Voor Nginx kun je Early Hints configureren door Link-headers aan je response toe te voegen en HTTP/2 of HTTP/3 push in te schakelen. Apache ondersteunt 103 Early Hints via de H2EarlyHints-directive. Bekijk onze gedetailleerde gids over het implementeren van 103 Early Hints voor stapsgewijze instructies.

Elimineer TTFB met de Speculation Rules API

De Speculation Rules API is ontworpen om de prestaties voor toekomstige navigaties te verbeteren. Zodra een bezoeker op je pagina is geland, kun je Speculation Rules gebruiken om een browser te instrueren om pagina's op te halen (met de prefetch-directive) of zelfs volledig te renderen (met de prerender-directive) die de bezoeker waarschijnlijk als volgende zal bezoeken.

Hoe Speculation Rules TTFB elimineert

Wanneer een pagina wordt prerendered, laadt en rendert de browser deze volledig in een verborgen tabblad. Wanneer de gebruiker vervolgens op de link klikt, wordt de prerendered pagina direct ingewisseld. Het resultaat: een gemeten TTFB van 0 milliseconden. Dit is geen theoretisch getal. CoreDash RUM-data van corewebvitals.io bevestigt dat prerendered navigaties via Speculation Rules een p75 TTFB van 0ms laten zien.

Prefetching is een lichter alternatief. In plaats van de pagina volledig te renderen, haalt de browser alleen het HTML-document op en slaat het op in de cache. Dit elimineert het netwerkgedeelte van de TTFB, terwijl de browser het document nog steeds moet parsen en renderen bij navigatie.

Speculation Rules JSON-syntax

Speculation Rules worden gedefinieerd met een <script type="speculationrules">-blok dat JSON bevat. Hier is een voorbeeld dat alle navigatielinks in je menubalk prerendert met "moderate" eagerness (geactiveerd bij hover of pointer down):

<script type="speculationrules">
{"prerender":
[{
  "source": "document",
  "where": {"selector_matches": "nav a"},
  "eagerness": "moderate"
}]}
</script>

Je kunt ook een op lijsten gebaseerde aanpak gebruiken voor specifieke URL's:

<script type="speculationrules">
{"prefetch":
[{
  "source": "list",
  "urls": ["/core-web-vitals/", "/pagespeed/103-early-hints"]
}]}
</script>

Browserondersteuning voor Speculation Rules groeit. Chrome 121+ ondersteunt de volledige API inclusief document rules. Voor browsers die Speculation Rules nog niet ondersteunen, kun je een lichtgewicht script zoals quicklink als fallback gebruiken. Gebruik onze Speculation Rules Generator om de juiste configuratie voor je site te maken.

Hoe beïnvloedt hosting de Time to First Byte?

Hosting beïnvloedt de Time to First Byte op meerdere manieren. Door te investeren in betere hosting is het meestal mogelijk om de Time to First Byte onmiddellijk te verbeteren zonder iets anders te veranderen. Vooral bij de overstap van goedkope shared hosting naar correct geconfigureerde en beheerde virtuele servers kan de TTFB drastisch verbeteren.

Hosting TIP: betere hosting omvat snellere verwerking, betere netwerksnelheid en meer en sneller servergeheugen. Dure hosting staat niet altijd gelijk aan betere hosting. Veel upgrades op shared hosting-diensten geven je alleen meer opslag, geen extra CPU-kracht.

Ik raad niet aan om van hosting te wisselen zonder de onderliggende oorzaken van TTFB-problemen te kennen. Ik adviseer je om RUM-tracking op te zetten en Server-Timing headers toe te voegen.

Wanneer je je hosting upgradet, moet je over het algemeen zoeken naar ten minste een van deze drie verbeteringen:

• Meer resources (CPU + RAM): Vooral wanneer het de server te lang kost om de dynamische HTML te genereren.
• Snellere DNS: Veel goedkope hostingproviders staan berucht om hun slechte DNS-prestaties.
• Betere configuratie: Zoek naar snellere SSL-ciphers, HTTP/3, Brotli-compressie en toegang tot de webserverconfiguratie (om overbodige modules uit te schakelen) om er een paar te noemen.

Hoe de TTFB te verbeteren: de initiële verbinding versnellen

Een hoge Time to First Byte kan meerdere oorzaken hebben. DNS, TCP en SSL beïnvloeden echter alle Time to First Bytes. Laten we daar dus beginnen. Hoewel het optimaliseren van deze drie misschien niet de grootste resultaten oplevert, zal het optimaliseren hiervan elke TTFB verbeteren.

DNS versnellen

PageSpeed TIP: DNS, TCP en SSL zijn meestal een groter probleem wanneer je een goedkope host gebruikt of wanneer je een wereldwijd publiek bedient zonder een CDN te gebruiken. Gebruik RUM-tracking om je wereldwijde TTFB te bekijken en de TTFB op te splitsen in subdelen.

Gebruik een snelle DNS-provider. Niet alle DNS-providers zijn even snel. Sommige (gratis) DNS-providers zijn gewoon langzamer dan andere (gratis) DNS-providers. Cloudflare geeft je bijvoorbeeld een van de snelste DNS-providers ter wereld gratis.

Verhoog de DNS TTL. Een andere manier is om de Time to Live (TTL)-waarde te verhogen. TTL is een instelling die bepaalt hoe lang de lookup in de cache kan worden bewaard. Hoe hoger de TTL, hoe kleiner de kans dat de browser nog een DNS-lookup moet uitvoeren. Het is belangrijk om te weten dat ISP's ook DNS cachen.

TCP versnellen

Het "TCP-deel" van de TTFB is de initiële verbinding met de webserver. Bij het verbinden delen de browser en de server informatie over hoe gegevens worden uitgewisseld. Je kunt TCP versnellen door verbinding te maken met een server die geografisch dicht bij je locatie staat en door ervoor te zorgen dat de server voldoende vrije resources heeft. Soms kan het overstappen naar een lichtgewicht server zoals NGINX het TCP-deel van de TTFB versnellen. In veel gevallen zal het gebruik van een CDN de TCP-verbinding versnellen.

SSL/TLS versnellen

Zodra de TCP-verbinding is gemaakt, moeten de browser en de server de verbinding beveiligen door middel van versleuteling. Je kunt dit versnellen door snellere, nieuwere en lichtere protocollen (SSL-ciphers) te gebruiken en door geografisch dichter bij je webserver te zijn (aangezien de TLS-onderhandeling behoorlijk wat heen-en-weer round-trips vergt). Het gebruik van een CDN zal vaak de SSL-verbindingstijd verbeteren omdat CDN's vaak zeer goed geconfigureerd zijn en meerdere servers over de hele wereld hebben. TLS 1.3 is specifiek ontworpen om de TLS-onderhandeling zo kort mogelijk te houden.

Hoe de TTFB te verbeteren: de server-side versnellen

Pagina-caching

Veruit de meest efficiënte manier om de Time to First Byte te versnellen is het serveren van de HTML vanuit de servercache. Er zijn verschillende manieren om full page caching te implementeren. De meest effectieve manier is door dit rechtstreeks op het webserverniveau te doen met bijvoorbeeld de NGINX-cachingmodule of door Varnish als een reverse caching proxy te gebruiken.

Er zijn ook veel plugins voor verschillende CMS-systemen die volledige pagina's cachen en veel SPA-frameworks zoals Next.js hebben hun eigen implementatie van full page caching samen met verschillende invalidatiestrategieën.

Als je je eigen caching wilt implementeren, is het basisidee eenvoudig. Wanneer een client een pagina opvraagt, controleer dan of deze bestaat in de cachemap. Als deze niet bestaat, maak de pagina aan, schrijf deze naar de cache en toon de pagina zoals je normaal zou doen. Bij elk volgend verzoek aan de pagina bestaat het cachebestand en kun je de pagina direct vanuit de cache serveren.

Gedeeltelijke caching

Bij gedeeltelijke caching is het idee om veelgebruikte, trage of dure delen van de pagina of resources (zoals API-calls, databaseresultaten) te cachen voor snelle opvraging. Dit elimineert knelpunten bij het genereren van een pagina. Als je geïnteresseerd bent in dit soort optimalisaties, kun je deze concepten opzoeken: Memory Cache, Object Cache, Database Cache, Object-Relational Mapping (ORM) Cache, Content Fragment Cache en Opcode Cache.

De applicatiecode optimaliseren

Soms kan de pagina niet uit de (gedeeltelijke) cache worden geserveerd omdat het cachebestand niet bestaat, grote delen van de pagina's dynamisch zijn of omdat je tegen andere problemen aanloopt. Daarom moeten we de applicatiecode optimaliseren. Hoe dit wordt gedaan hangt volledig af van je applicatie. Het is gebaseerd op het herschrijven en optimaliseren van trage delen van je code.

Database-query's optimaliseren

Meestal zijn ineffectieve database-query's de hoofdoorzaak van een trage Time to First Byte. Begin met het loggen van "slow queries" en "queries not using indexes" naar schijf. Analyseer ze, voeg indexen toe of vraag een expert om database-tuning uit te voeren om deze problemen op te lossen. Zie MongoDB Performance Advisor en MySQL Slow Query Log voor meer details.

Interne netwerklatentie verminderen

Een slechte gewoonte die ik vaker tegenkom dan ik zou willen, is een vertraging in de Time to First Byte veroorzaakt door traagheid in de communicatie tussen de webapplicatie en de dataopslag. Dit gebeurt meestal alleen bij grote sites die hun dataopslag hebben uitbesteed aan cloud-API's.

Hoe de TTFB te verbeteren: de client-side versnellen

Client-side caching

Client-side caching houdt in dat de browser van de gebruiker resources opslaat die ze al eerder hebben bezocht, zoals afbeeldingen en scripts. Wanneer de gebruiker terugkeert naar je website, kan de browser de gecachte resources snel ophalen in plaats van ze opnieuw te moeten downloaden. Dit kan het aantal verzoeken aan de server aanzienlijk verminderen, wat op zijn beurt de TTFB kan verlagen.

Om client-side caching te implementeren, kun je de HTTP Cache-Control-header gebruiken. Met deze header kun je specificeren hoe lang de browser een bepaalde resource moet cachen.

Je kunt overwegen om de HTML van de pagina volledig aan de client-side te cachen. Dit zal de TTFB drastisch verlagen omdat er geen serververzoek nodig is. Het nadeel is dat zodra de pagina in de cache van de browser staat, eventuele updates op de live versie van de pagina niet door de gebruiker worden gezien totdat de paginacache verloopt.

Service Workers

Service workers zijn scripts die op de achtergrond in de browser van een gebruiker draaien en netwerkverzoeken kunnen onderscheppen die door de browser worden gedaan. Dit betekent dat service workers resources kunnen cachen zoals HTML, afbeeldingen, scripts en stylesheets, zodat wanneer de gebruiker terugkeert naar je website, hun browser de gecachte resources snel kan ophalen in plaats van ze opnieuw te moeten downloaden.

Pagina-prefetching

Als je de Speculation Rules API niet wilt gebruiken vanwege de beperkte browserondersteuning, kun je een klein script genaamd quicklink gebruiken. Dit zal alle links in de zichtbare viewport prefetchen en de Time To First Byte voor deze links vrijwel elimineren.

Het nadeel van quicklink is dat het meer browserbronnen vereist, maar voor nu zal het de Speculation Rules API overtreffen qua browserdekking.

Hoe de TTFB te verbeteren: gebruik een CDN

Een Content Delivery Network of CDN gebruikt een gedistribueerd netwerk van servers om resources aan gebruikers te leveren. Deze servers staan meestal geografisch dichter bij eindgebruikers en zijn sterk geoptimaliseerd voor snelheid. Als je Cloudflare gebruikt, bekijk dan onze gids over het configureren van Cloudflare voor optimale Core Web Vitals-prestaties.

Een CDN kan 5 van de 6 onderdelen van de Time to First Byte verbeteren:

• Redirecttijd: De meeste CDN's kunnen redirects op de edge cachen of edge workers gebruiken om redirects af te handelen zonder verbinding te hoeven maken met de origin server.
• DNS-lookuptijd: De meeste CDN's bieden extreem snelle DNS-servers die waarschijnlijk beter presteren dan je huidige DNS-servers.
• TCP-verbinding en SSL-handshaketijd: De meeste CDN's zijn extreem goed geconfigureerd en deze configuraties, samen met de nauwere nabijheid tot de eindgebruikers, zullen de verbindings- en handshake- tijd versnellen.
• Serverantwoord: CDN's kunnen de serverantwoordtijd op verschillende manieren versnellen. De eerste is door het serverantwoord op de edge te cachen (full page edge caching) maar ook door uitstekende compressie (Brotli) en de nieuwste (HTTP/3) protocollen aan te bieden.

Hoe de TTFB te verbeteren: vermijd redirects

Redirecttijd wordt toegevoegd aan de Time To First Byte. Vermijd daarom als algemene regel redirects zo veel mogelijk. Redirects kunnen optreden wanneer een resource niet langer beschikbaar is op één locatie maar is verplaatst naar een andere locatie. De server reageert met een redirect response header en de browser probeert die nieuwe locatie.

Same-origin redirects. Same-origin redirects komen voort uit links op je eigen website. Je zou volledige controle over deze links moeten hebben en je zou het repareren van deze links prioriteit moeten geven bij het werken aan de Time to First Byte. Er zijn veel tools die je je hele website laten controleren op redirects.

Cross-origin redirects. Cross-origin redirects komen voort uit links op andere websites. Je hebt zeer weinig controle over deze.

Meerdere redirects. Meerdere redirects of redirect chains treden op wanneer een enkele redirect niet doorverwijst naar de definitieve locatie van de resource. Dit soort redirects belasten de Time to First Byte extra en moeten koste wat het kost worden vermeden. Gebruik opnieuw een tool om dit soort redirects te vinden en ze te repareren.

HTTP-naar-HTTPS redirects. Een manier om dit te omzeilen is door de Strict-Transport-Security- header (HSTS) te gebruiken, die HTTPS afdwingt bij het eerste bezoek aan een origin en vervolgens de browser instrueert om de origin onmiddellijk via het HTTPS-schema te benaderen bij toekomstige bezoeken.

Wanneer een gebruiker een webpagina opvraagt, kan de server reageren met een redirect naar een andere pagina. Deze redirect kan extra tijd toevoegen aan de TTFB omdat de browser een extra verzoek naar de nieuwe pagina moet doen.

Er zijn verschillende manieren om redirects te vermijden of de impact van redirects te minimaliseren:

1. Werk je interne links bij. Wanneer je de locatie van een pagina wijzigt, werk je interne links naar die pagina bij zodat er geen verwijzingen naar de eerdere paginaplocatie overblijven.
2. Handel redirects af op serverniveau.
3. Gebruik relatieve URL's: Wanneer je linkt naar pagina's op je eigen website, gebruik dan relatieve URL's in plaats van absolute URL's. Dit helpt onnodige redirects te voorkomen.
4. Gebruik canonical URL's: Als je meerdere pagina's met vergelijkbare content hebt, gebruik dan een canonical URL om de voorkeursversie van de pagina aan te geven. Dit helpt dubbele content en onnodige redirects te voorkomen.
5. Gebruik 301-redirects: Als je een redirect moet gebruiken, gebruik dan een 301-redirect in plaats van een 302-redirect. Een 301- redirect is een permanente redirect, terwijl een 302-redirect een tijdelijke redirect is. Het gebruik van een 301-redirect helpt onnodige redirects te voorkomen.

Optimaliseer resource-prioritering naast TTFB

Het verlagen van TTFB is slechts een deel van het laadprestatieverhaal. Zodra de eerste byte aankomt, moet de browser weten welke resources prioriteit moeten krijgen. Lees onze gids voor resource-prioritering om te leren hoe fetchpriority, preload en preconnect hints samenwerken met een snelle TTFB om de snelst mogelijke paginaladingen te realiseren. Overweeg daarnaast om je Google Fonts zelf te hosten om third-party DNS-lookups en verbindingstijden te elimineren die bijdragen aan de waargenomen TTFB van je gebruikers.

Wat echte TTFB-data laat zien

De volgende data komt van CoreDash Real User Monitoring en de 2025 Web Almanac.

Geografische variatie is enorm

TTFB varieert dramatisch op basis van de fysieke afstand tussen de gebruiker en de server. CoreDash-data van corewebvitals.io (gehost in Europa) illustreert dit duidelijk:

Europese gebruikers dicht bij de server zien een TTFB onder de 170ms, terwijl gebruikers in India 3x hogere TTFB ervaren en gebruikers in China bijna 10x hogere TTFB zien (1.468ms) door de Great Firewall en de enorme fysieke afstand. Deze data laat zien waarom een CDN met wereldwijde edge-locaties essentieel is voor internationaal publiek.

Speculation Rules prerender levert 0ms TTFB

CoreDash navigatietype-data bevestigt dat pagina's die via Speculation Rules worden prerendered een p75 TTFB van 0 milliseconden bereiken. Standaard navigaties meten 131ms, reloads komen uit op 82ms (profiterend van warme verbindingen) en back-forward navigaties zijn het traagst met 244ms. Dit maakt Speculation Rules de meest effectieve techniek voor het elimineren van TTFB bij vervolgpaginaladingen.

Mobiele TTFB is 2,5x desktop

Op corewebvitals.io ervaren mobiele gebruikers een p75 TTFB van 316ms vergeleken met 124ms op desktop. Dit 2,5x-verschil wordt veroorzaakt door mobiele netwerklatentie, niet door serververschillen. Slechts 88,5% van de mobiele paginladingen behaalt een "goed" TTFB-score vergeleken met 96,1% op desktop. Wanneer je optimaliseert voor TTFB, test dan altijd op echte mobiele netwerken.

Nieuwe vs. terugkerende bezoekers zien vergelijkbare TTFB

Op deze site zien nieuwe bezoekers een p75 TTFB van 127ms terwijl terugkerende bezoekers 138ms zien. De gelijkenis suggereert dat consistente server-side caching (in plaats van voordelen van client-side cache) de primaire factor is in TTFB-prestaties. Op sites zonder server-side caching kan het verschil tussen nieuwe en terugkerende bezoekers veel groter zijn.

Wereldwijde TTFB stagneert al 5 jaar

Volgens de 2025 Web Almanac behaalt slechts 44% van de mobiele pagina's wereldwijd een "goede" TTFB-score. Dit getal is nauwelijks veranderd ten opzichte van 41% in 2021, waarmee TTFB de meest stagnerende prestatiemetric op het web is. Ondertussen verbeterde LCP van 44% naar 59% en INP van 55% naar 74% in dezelfde periode. Sites met slechte LCP besteden gemiddeld 2,27 seconden aan TTFB alleen, bijna de volledige LCP-drempel van 2,5 seconden.

Gerelateerde gidsen: TTFB-subdelen

Elk subdeel van de Time to First Byte heeft zijn eigen optimalisatiestrategieën:

• <b>TTFB-problemen oplossen en identificeren</b>: Een stapsgewijze diagnostische gids voor het vinden van de oorzaak van een trage TTFB met DevTools, Server-Timing en RUM-data.
• <b>De wachttijd verminderen</b>: Hoe je redirecttijd en serververwerkingsvertragingen die bijdragen aan je TTFB kunt minimaliseren.
• <b>De cacheduur verminderen</b>: Strategieën voor browsercaching, service workers en back/forward cache (bfcache) om TTFB te elimineren voor terugkerende bezoekers.
• <b>DNS-duur minimaliseren</b>: Hoe je DNS-resolutie kunt versnellen met snellere DNS-providers, verhoogde TTL-waarden en dns-prefetch resource hints.
• <b>Verbindingsduur optimaliseren (TCP + TLS)</b>: TCP- en TLS-handshaketijd verminderen met HTTP/3, TLS 1.3, session resumption en preconnect hints.