Time to First Byte (TTFB): wat het is en hoe je het verlaagt

Is TTFB een Core Web Vital?

Nee. TTFB is niet een van de drie Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) en Cumulative Layout Shift (CLS). Google noemt TTFB als metric om een trage LCP te diagnosticeren, en Search Console heeft geen TTFB-rapport. Volgens de State of Web Vitals slaagt 70,8% van de sites op telefoons voor alle drie, maar slechts 47,7% met een goede TTFB. Om te slagen heb je dus geen goede TTFB nodig. Voor rankings telt TTFB alleen mee als eerste deel van LCP.

De 0,8 seconden van Google voor een goede TTFB is een richtlijn. Een server-rendered pagina kan een hogere TTFB hebben en toch een snellere LCP dan een pagina die JavaScript in de browser opbouwt, omdat de HTML de content al bevat (web.dev).

Waarom is TTFB belangrijk?

Op een pagina kan niets beginnen voordat de eerste byte van de HTML binnen is: tot die tijd kijkt de bezoeker naar de vorige pagina of een wit scherm. Met een trage TTFB is een goede LCP vrijwel onmogelijk.

Volgens de State of Web Vitals is TTFB op telefoons het grootste van de vier onderdelen van LCP voor 67,6% van de sites met een afbeelding als LCP-element en alle vier de onderdelen in CrUX. Bij de 149 sites die met CoreDash meten, ging in de 28 dagen tot 7 november 2026 bij page loads op telefoons met een afbeelding-LCP van 2,5 seconden of meer op het 75e percentiel 1,8 seconden op aan TTFB alleen, tegenover 0,47 seconden bij een afbeelding-LCP onder 2,5 seconden.

Volgt First Contentful Paint (FCP), de eerste tekst of afbeelding op het scherm, snel op een late TTFB, dan is de server het trage onderdeel; een groot gat tussen die twee wijst naar de stylesheets en scripts in de head.

Wat is een goede TTFB-score?

Een goede TTFB is 0,8 seconden of minder op het 75e percentiel van page loads. Van 0,8 tot 1,8 seconden moet worden verbeterd, en meer dan 1,8 seconden is slecht. PageSpeed Insights toont mobiel en desktop apart.

Onder 0,8 seconden is lager nog steeds beter: elke milliseconde die de server bespaart, laat meer over van de 2,5 seconden van LCP voor de pagina zelf. Volgens de State of Web Vitals heeft 59,0% van de sites een goede TTFB op telefoons, tegenover 81,8% met een goede LCP. 32,0% van de WordPress-sites heeft een goede TTFB, tegenover 95,7% van de Shopify-winkels. Shopify stuurt 103 Early Hints, wat Chrome meetelt als de eerste byte. Dat cijfer meet dus deels de hint, niet de HTML.

Waarom is mijn TTFB traag?

Op de meeste sites bouwt de server de pagina voor elke bezoeker opnieuw op: er is geen page cache, of een cookie of query string zorgt dat bezoekers die overslaan. Daarna komen afstand zonder CDN, en redirects.

Wat zijn de onderdelen van TTFB, van request tot response?

TTFB bestaat uit vijf opeenvolgende onderdelen: waiting (vooral redirects), cache (de HTTP-cache van de browser en een service worker), DNS, connection (TCP en TLS) en request (het werk van de server plus de reis over het netwerk heen en terug). In CoreDash is waiting Waiting + Redirect en is cache Worker & Cache.

Eén eerste bezoek aan een WordPress-pagina die niet in de cache zat, gemeten in Chrome. Van de 875 ms TTFB kostte het request 657 ms en de redirect ervoor 174 ms.

Is TTFB hetzelfde als server response time?

Nee. Server response time is alleen het wachten tussen het versturen van het request en het ontvangen van de eerste byte: het werk van de server plus één reis over het netwerk. TTFB telt de redirects, de cachecontrole, DNS en de verbinding vooraf erbij op. Een server die in 100 ms antwoordt, kan een bezoeker op een ander continent alsnog een TTFB van bijna een seconde bezorgen, omdat elk van die stappen op een roundtrip wacht.

Chrome DevTools noemt server response time "Waiting for server response" in het Timing-tabblad van het Network-paneel (oudere versies: "Waiting (TTFB)"); Lighthouse noemt het server response time. Beide meten alleen dat laatste onderdeel, de request duration; de TTFB in je field data bestaat uit alle vijf de onderdelen. Het waiting-onderdeel in web-vitals is iets anders: de tijd vóór het request, vooral redirects.

Hoe meet je TTFB?

PageSpeed Insights toont de TTFB van je echte bezoekers, de field data, op het mobiele tabblad: het 75e percentiel van de afgelopen 28 dagen, voor de URL en de hele origin, naast FCP. Een RUM-tool zoals CoreDash splitst TTFB per pagina, land en onderdeel.

CoreDash TTFB Breakdown: de vijf onderdelen op één regel, elk met de tijd en beoordeling.

Voor één load open je het Timing-tabblad van het HTML-document in het Network-paneel van Chrome DevTools: de TTFB van dat request eindigt met "Waiting for server response". Lighthouse toont het HTML-request in de melding Document request latency: "Your first network request is the most important. Reduce its latency by avoiding redirects, ensuring a fast server response, and enabling text compression." De limiet voor de server response is 600 ms.

Lighthouse en DevTools laden je pagina één keer, vanaf één locatie, meestal de uiteindelijke URL. De TTFB in je field data is het 75e percentiel over 28 dagen aan echte bezoeken, inclusief de redirects vanaf advertentielinks, de afstand en de pagina's die nog niet in de cache zaten. Het getal uit de field data, meestal het hogere, is wat je bezoekers krijgen. Lab data en field data legt uit welk getal waarvoor dient.

In je eigen code geeft de Navigation Timing API de TTFB als responseStart: de eerste byte, in milliseconden vanaf de start van de navigatie. De web-vitals library berekent TTFB en rapporteert de vijf onderdelen:

import { onTTFB } from 'web-vitals/attribution';

onTTFB(({ value, attribution }) => {
  console.log('TTFB', Math.round(value), 'ms');
  console.table({
    waiting: attribution.waitingDuration,
    cache: attribution.cacheDuration,
    dns: attribution.dnsDuration,
    connection: attribution.connectionDuration,
    request: attribution.requestDuration,
  });
});

Een trage TTFB controleren en fixen gaat stap voor stap van een traag getal naar de oorzaak.

Server-Timing: welk deel van de server is traag?

Via een Server-Timing-header stuurt de server zijn eigen timings mee met de HTML, zoals de database, het template en een cache hit of miss:

Server-Timing: wp;dur=27.8;desc="WordPress and query", tpl;dur=27.1;desc="Template"

DevTools toont de regels in het Timing-tabblad van het HTML-request, en een RUM-tool kan ze verzamelen uit echte bezoeken. Voordat iemand overstapt naar een andere host, wil ik dat RUM en Server-Timing laten zien welk deel van de TTFB traag is.

Eén load op een lokale WordPress-testinstallatie: WordPress met zijn databasequery kostte 27,8 ms en het template 27,1 ms, van de 59 ms die de browser op de server wachtte.

Maken 103 Early Hints TTFB sneller?

103 Early Hints verlagen de TTFB die je meet, omdat Chrome de 103 als eerste byte telt, terwijl de HTML zelf niet eerder binnen is. Voor de bezoeker begint de browser al met het laden van stylesheets, fonts en de LCP-afbeelding terwijl de server de pagina nog opbouwt, waardoor FCP en LCP eerder volgen.

Zet op Cloudflare Early Hints aan onder Speed > Settings > Content Optimization. Cloudflare slaat de preload- en preconnect-Link-headers op die je server voor een pagina meestuurt, en stuurt die vanaf het volgende request als een 103 via HTTP/2 en HTTP/3. Shopify verstuurt 103 Early Hints al. Op je eigen server heeft Apache H2EarlyHints on, en nginx 1.29 en nieuwer geeft een 103 vanuit je applicatie door met de early_hints-directive. Verwijs naar bestanden op je eigen domein, en gebruik een preconnect alleen voor een kritiek bestand dat daar niet naartoe kan:

HTTP/2 103
link: </css/style.css>; rel=preload; as=style
link: </img/hero.webp>; rel=preload; as=image

HTTP/2 200
content-type: text/html
...

Een host of CDN die een 103 stuurt, lijkt snel in TTFB-vergelijkingen op basis van Chrome-data, zelfs als de server traag is; Server-Timing toont de echte servertijd. In 103 Early Hints staat de setup per server.

Kunnen Speculation Rules TTFB nul maken?

Speculation Rules laden de volgende pagina vooraf: een geprerenderde pagina staat op het scherm zodra de bezoeker klikt, en de web-vitals library rapporteert de TTFB als 0; een geprefetchte pagina slaat het wachten op de HTML over. De field data van Chrome (CrUX) meet TTFB alleen bij volledige page loads, dus bij een geprerenderde pagina zie je de winst terug in de LCP.

WordPress 6.8 en hoger voegen uit zichzelf een prefetch-regel toe; WP Core Web Vitals kan een agressievere regel instellen als de page cache aanstaat. In code prerendert deze regel een menulink zodra de bezoeker intentie toont: op desktop een hover of klik, op telefoons een link in beeld zodra het scrollen stopt:

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

Elke gespeculeerde link is een request naar je server, dus zonder page cache levert prerendering extra load op. Alleen Chromium-browsers zoals Chrome en Edge gebruiken Speculation Rules. De Speculation Rules-generator schrijft de regels voor je site; Speculation Rules gaat hier dieper op in.

Hoe verlaag je een trage TTFB?

Begin bij het onderdeel van de TTFB dat het grootst is. Het request was op het 75e percentiel het grootste deel van de TTFB bij 82 van de 86 CoreDash-sites met minstens 1.000 page loads op telefoons in de 28 dagen tot 9 november 2026. Het omvat het opbouwen van de pagina door de server plus de reis over het netwerk. Begin dus met een page cache, cache vervolgens de HTML op een CDN en schrap overbodige redirects.

Een page cache

Zet de page cache aan in je caching-plugin of bij je host, zodat de server een opgeslagen kopie van de pagina verstuurt in plaats van hem opnieuw op te bouwen. Test dit uitgelogd, in een privévenster: ingelogde gebruikers, een winkelmand-cookie en query strings die de cache niet kent (gclid, utm_source uit advertenties en mail) omzeilen de cache. Een pagina die bij elke response een cookie zet, voor een sessie of een A/B-test, wordt vaak helemaal nooit gecachet. Voor developers: deze header laat een CDN of proxy de HTML tien minuten bewaren en nog één minuut serveren terwijl hij een verse kopie ophaalt, en laat de browser bij elk bezoek opnieuw navragen:

Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60

Pagina's die je niet kunt cachen

Ingelogde pagina's, de winkelmand en zoekresultaten worden voor elke bezoeker opnieuw opgebouwd, dus moet de server zelf sneller worden: een object cache zoals Redis voor herhaalde databaseresultaten, indexes voor trage queries. Een pagina die op een database of API in een ander datacenter wacht voordat hij antwoordt, telt die roundtrip op bij elke TTFB. Server-Timing laat zien wat hiervan traag is.

Bezoekers ver van je server

Een CDN brengt de verbinding dicht bij de bezoeker, en het cachen van de HTML aan de edge van het CDN neemt ook de reis naar je server weg. Een CDN dat alleen afbeeldingen cachet en elk HTML-request doorstuurt naar je server, laat het request-onderdeel vrijwel ongemoeid. Op Cloudflare heeft de HTML een Cache Rule nodig, of APO voor WordPress: in Cloudflare configureren voor de Core Web Vitals staan de instellingen.

Redirects

Elke redirect is een volledig extra request voordat het echte request start. Link overal naar de definitieve URL (https, met of zonder www en de trailing slash, zoals je site die gebruikt) en los redirect chains op. Een browser onthoudt een 301, dus een terugkerende bezoeker slaat die over; voor http naar https stuurt de Strict-Transport-Security-header (HSTS) de browser direct naar https. Links in advertenties en mail lopen vaak eerst via tracking-redirects: controleer of ze op je uiteindelijke URL uitkomen. Waiting duration bevat de details.

DNS en de verbinding

Gebruik een snelle DNS-provider en een host of CDN met TLS 1.3 en HTTP/3, die minder roundtrips nodig hebben om verbinding te maken. DNS duration en connection duration gaan hier dieper op in.

Hosting

Een nieuwe host helpt als gecachete pagina's snel zijn, niet-gecachete traag zijn en Server-Timing naar de server zelf wijst. Zoek dan naar meer CPU en geheugen: veel hosting-upgrades voegen alleen extra opslag toe.

JavaScript-frameworks

Een pagina die Next.js, Nuxt of SvelteKit voor elk request op de server rendert, heeft de TTFB van een niet-gecachete pagina. Render pagina's statisch of cache de gerenderde HTML waar de content dat toelaat, en stream de HTML zodat de head met de stylesheets al de deur uit is voordat de trage data klaar is.

WordPress

• Page cache: WP Rocket, LiteSpeed Cache of je host. Mijn plugin, WP Core Web Vitals, stuurt de gecachete pagina al voordat WordPress en de andere plugins laden.
• WooCommerce en ingelogde pagina's: een object cache (Redis), vaak een instelling bij je host.
• Een trage plugin: Query Monitor toont de trage databasequeries en de plugin waar ze vandaan komen.

Shopify

De server, de cache, het CDN en de 103 Early Hints zijn van Shopify. De redirects en de Liquid-code van je thema en apps zijn van jou: Shopify Theme Inspector for Chrome laat zien welk deel van het thema er lang over doet om op de server te renderen.

Heeft de fix je bezoekers bereikt?

Controleer eerst de cache: open de pagina uitgelogd, daarna met ?gclid= en een waarde die je niet eerder hebt gebruikt (elke advertentieklik levert een nieuwe op), en kijk in de response headers naar een cache hit (cf-cache-status: HIT op Cloudflare, een x-cache-header bij veel hosts). Leeg na een release ook de HTML op het CDN, anders blijft die mogelijk de pagina van vorige week serveren.

Een RUM-tool toont de verandering de volgende dag al. De field data van PageSpeed Insights beslaat de afgelopen 28 dagen, dus die beweegt traag, en Search Console toont TTFB alleen via LCP.

Sommige TTFB-problemen liggen buiten je instellingen: een host of backend waar je geen controle over hebt, of een cache die elke bezoeker overslaat om een reden die niemand meer weet. In een Core Web Vitals power hour kijken we naar je TTFB per pagina en land en naar de cache headers van je traagste pagina's, en bepalen we welk deel we eerst fixen en wie dat doet.