Waarom je site traag begint, voor er iets staat

Je opent een pagina en er gebeurt lang niets. Geen tekst, geen logo, alleen een leeg tabblad dat wacht. Dat komt meestal niet door de foto’s of de scripts, want die beginnen pas te laden als de eerste byte binnen is. Het eerste stuk van die wachttijd heet TTFB, time to first byte. Dit stuk laat zien wat we over dat getal meten, wat je er zelf mee kunt en waar de meting ophoudt.

Wat TTFB precies meet

TTFB is de tijd tussen het moment dat de browser een verzoek stuurt en het moment dat de eerste byte van het antwoord binnenkomt. Daarin zitten de redirects, het opzoeken van het adres, de versleutelde verbinding en het werk dat de server doet voordat hij iets terugstuurt. TTFB is geen Core Web Vital, maar web.dev noemt 0,8 seconde of minder goed en meer dan 1,8 seconde slecht (geraadpleegd 4 oktober 2026).

Waarom het eerste moment telt? Een bezoeker die niets ziet, weet niet of de pagina komt. Hij wacht of hij klikt weg. Zolang er nog niets op het scherm staat, heb je hem nog niets overtuigd. Daarom is het zinvol om dit getal apart te bekijken, ook als de rest van de pagina er goed uitziet.

Wat we gemeten hebben

Tussen 31 juli 2026 en 3 oktober 2026 hebben we 344 TTFB-metingen gedaan op 22 sites die FWRD host. De metingen komen uit de browsers van echte bezoekers, op dezelfde manier als de Core Web Vitals worden gemeten. Het 75e percentiel ligt op 435,5 ms. Dat betekent dat driekwart van de bezoeken de eerste byte binnen 435,5 ms kreeg, ruim onder de 0,8 seconde die web.dev als goed noemt (geraadpleegd 4 oktober 2026).

Twee grenzen bij dit getal. Het gaat om een kleine groep sites, dus het zegt iets over die sites en niet over het hele web. En de meting zit in de browser van de bezoeker, dus de afstand tussen die bezoeker en de server telt mee. Dezelfde site geeft voor een bezoeker in de buurt een ander getal dan voor iemand ver weg.

Wat deze meting niet zegt: hoe lang het duurt tot de pagina er volledig uitziet, en of een bezoeker het formulier invult. Dat zijn andere vragen. Deze meting beantwoordt er één: komt de eerste byte snel genoeg binnen om de rest van het bezoek niet te blokkeren? Voor driekwart van de bezoeken op deze sites is het antwoord ja.

Waar een hoge wachttijd vandaan komt

Een hoge TTFB heeft meestal een van drie oorzaken. De server is traag of overbelast. De pagina wordt elke keer opnieuw opgebouwd, terwijl hij ook klaar uit een cache had kunnen komen. Of de browser moet eerst een paar redirects volgen, en elke redirect is een extra heen-en-weer. Welke oorzaak het is, zie je niet aan de pagina zelf. Dat zie je alleen als je het meet.

Zo meet je het zelf

Open je site in Chrome en druk op Ctrl+Shift+I om de ontwikkelaarstools te openen. Kies het tabblad Network en vink Disable cache aan. Laad de pagina opnieuw en klik op het eerste verzoek, dat is het adres van je eigen site. Open daarin het tabblad Timing. De regel Waiting (TTFB) is het getal dat je zoekt. Doe dat een paar keer, want één meting zegt weinig: een server kan net op dat moment druk zijn. Staat de wachttijd ruim boven de 0,8 seconde die web.dev als goed noemt (geraadpleegd 4 oktober 2026), kijk dan eerst naar de hosting en de redirects in dezelfde lijst. Aan je foto’s ligt het meestal niet, want die komen pas na die eerste byte.

Meet ook opnieuw na elke grote wijziging, zoals een andere hostingpartij of een nieuwe redirect. Dan weet je welke wijziging het getal heeft verschoven, in plaats van dat je moet raden.

Wat dit niet oplost

Een korte wachttijd maakt de rest van de pagina niet vanzelf snel. Een grote foto of een zwaar script bepaalt wanneer de pagina er echt uitziet, en dat is een ander meetpunt. Daar ging het stuk over snelheid die je niet eenmalig regelt. Hosting bepaalt een deel van die wachttijd op het eerste moment, en wat wij daarvoor doen staat op de productpagina voor hosting en domein.

Wil je dit voor je eigen site laten meten? Dat kan via de diagnose.