U klikt op een link, en er gebeurt even niets. Geen tekst, geen afbeelding, alleen een draaiend icoontje in het tabblad. Daarna verschijnt de pagina in één keer. Die stille periode aan het begin heeft een naam: Time To First Byte, afgekort TTFB. Het is de tijd tussen het moment dat de browser om de pagina vraagt en het moment dat het eerste stukje antwoord binnenkomt.

Wie zijn TTFB wil verbeteren, moet eerst begrijpen wat er in die wachttijd gebeurt. Want anders dan bij trage afbeeldingen of zware scripts, ziet u in die periode niets. De browser kan nog niets tekenen, want hij heeft nog geen enkele letter HTML ontvangen. Alles wat daarna komt, schuift dus op. In dit artikel leggen wij uit wat er in die stilte gebeurt, wat normale waarden zijn en waar u kunt ingrijpen.

Wat er gebeurt in die eerste honderden milliseconden

Tussen klik en eerste byte doorloopt het verzoek een reeks stappen. Ze zijn allemaal kort, maar ze tellen op:

  1. DNS-opzoeking. De browser zoekt uit welk IP-adres bij uw domeinnaam hoort. Meestal 10 tot 50 milliseconden, soms meer als de DNS-provider traag is.
  2. Verbinding opzetten. De browser maakt contact met de server en onderhandelt een beveiligde verbinding (TLS). Vanuit Nederland naar een Nederlandse server: 20 tot 60 milliseconden. Naar een server in de Verenigde Staten: het drievoudige.
  3. Wachten op de server. Dit is het grote blok. De server ontvangt het verzoek, start PHP op, laadt WordPress, laadt het thema en alle plugins, bevraagt de database tientallen keren, bouwt de HTML op en begint met versturen. Op een goede server met een lichte site: 50 tot 150 milliseconden. Op een overvolle server met een zware site: één tot drie seconden.

De derde stap is bijna altijd de oorzaak van een hoge TTFB. En binnen die stap zijn er weer twee hoofdverdachten: de server zelf (te weinig kracht, te veel buren) en de site (te veel werk per pagina).

Welke waarden normaal zijn

Google hanteert als richtlijn dat een TTFB onder de 800 milliseconden “goed” is, maar dat is een ruime grens die rekening houdt met bezoekers aan de andere kant van de wereld. Voor een Nederlandse site met Nederlandse hosting en Nederlandse bezoekers ligt de lat in onze ervaring een stuk lager:

  • Onder 200 ms: uitstekend. Dit haalt u met een goede server en paginacaching.
  • 200 tot 500 ms: acceptabel voor pagina’s die niet gecachet kunnen worden, zoals een winkelwagen. Voor een gewone homepage is het aan de hoge kant.
  • 500 tot 1.000 ms: hier zit een probleem. Ofwel de cache werkt niet, ofwel de server is traag, ofwel de site doet te veel.
  • Boven 1.000 ms: dit merkt elke bezoeker. Aanpakken.

Meet altijd meerdere keren en op meerdere pagina’s. De eerste meting na een cache-leging is altijd traag; de tweede zegt meer over wat bezoekers ervaren.

Waarom TTFB de andere meetwaarden meesleept

Alles wat de browser doet, begint pas na de eerste byte. Een hoge TTFB vertraagt dus rechtstreeks de Largest Contentful Paint, want de grootste afbeelding kan pas worden opgehaald als de HTML binnen is die ernaar verwijst. Een site met een TTFB van 1,2 seconden haalt de LCP-grens van 2,5 seconden bijna nooit, hoe klein de afbeeldingen ook zijn.

Daarom is TTFB in de praktijk vaak het eerste waar wij naar kijken bij een trage site. Het is de basis waar alles op rust. Hoe de andere meetwaarden in elkaar zitten, leest u in onze uitleg over de Core Web Vitals in gewone taal.

De oorzaken, van meest naar minst voorkomend

Geen of niet-werkende paginacaching. Zonder cache bouwt WordPress elke pagina opnieuw op voor elke bezoeker. Met cache levert de server een kant-en-klaar bestand uit en zakt de TTFB vaak van 800 naar 100 milliseconden. Dit is verreweg de grootste winst die u kunt boeken, en verrassend vaak staat de cache wel geïnstalleerd maar niet aan, of wordt hij door een andere plugin omzeild.

Overvolle gedeelde hosting. Als honderd sites één processor delen, wacht uw verzoek in de rij. Dit herkent u aan een TTFB die over de dag sterk schommelt.

Trage databaseverzoeken. Een plugin die bij elke pagina een zware query doet, een database met honderdduizenden overbodige rijen in de optietabel, of een ontbrekende index. Elk verzoek dat honderd milliseconden duurt, telt direct op bij de TTFB.

Externe aanroepen tijdens het opbouwen. Sommige plugins halen bij elk bezoek gegevens op bij een externe dienst: een weerwidget, een koersnotering, licentiecontrole, een Instagram-feed. Als die dienst 700 milliseconden nodig heeft, wacht uw hele pagina daarop.

Oude PHP-versie. PHP 8.x is aanzienlijk sneller dan PHP 7.4 in het uitvoeren van dezelfde code. Een upgrade scheelt in onze ervaring al gauw tien tot dertig procent op de serverkant.

Redirects. Als uw site eerst van http naar https en dan van zonder-www naar met-www doorverwijst, zijn dat twee extra rondreizen vóór het echte verzoek begint. Meettools rekenen die mee.

Afstand. Hosting buiten Europa voegt honderden milliseconden toe, puur door de fysieke afstand. Dit is de enige oorzaak die een CDN daadwerkelijk oplost.

Wat u zelf kunt controleren

  • Meet de TTFB in het netwerktabblad van uw browser (F12 → Netwerk → eerste regel → Timing → “Waiting for server response”).
  • Controleer of uw cacheplugin daadwerkelijk werkt: in de broncode van de pagina staat vaak onderaan een regel als “Cached by WP Rocket” of een header als x-litespeed-cache: hit.
  • Controleer uw PHP-versie in Site Health (Hulpmiddelen → Sitegezondheid → Info → Server).
  • Kijk of uw site in één keer op de juiste URL uitkomt zonder omleidingen.

Wilt u verder uitzoeken of de server of de site de vertraging veroorzaakt? Dan is ons stappenplan om te meten of uw hosting de bottleneck is de logische volgende stap.

Een praktijkvoorbeeld

Een fictief maar realistisch geval: een adviesbureau in Amersfoort had een TTFB van gemiddeld 1,4 seconden, terwijl er een cacheplugin actief was. Bij nader onderzoek bleek een plugin voor een koersticker bij elk bezoek een externe API aan te roepen, vóórdat de cache werd geraadpleegd. De externe dienst reageerde traag. Na het uitschakelen van die plugin zakte de TTFB naar 90 milliseconden. Eén plugin, meer dan een seconde verschil. Dit soort speurwerk is precies waar een gerichte gerichte snelheidsoptimalisatie om draait: niet alles tegelijk aanpassen, maar de echte oorzaak vinden.

Conclusie

TTFB is de stille wachttijd waar uw bezoeker niets van ziet, behalve dat er niets gebeurt. Streef voor een Nederlandse site naar minder dan 200 milliseconden op gecachte pagina’s en minder dan 500 op dynamische pagina’s. Begin bij de cache, kijk daarna naar de PHP-versie en externe aanroepen, en pas als dat allemaal in orde is naar de hosting zelf. In die volgorde verspilt u de minste tijd.