Wat TTFB is en waarom WordPress-sites er vaak een hoge hebben

Time to First Byte (TTFB) is de tijd tussen het moment dat een browser een navigatie start en het moment dat de eerste byte van het antwoord terugkomt. De web.dev definitie van Google omschrijft het precies zo. Bij een WordPress-site is dit het eerste wat je überhaupt kunt meten aan een verzoek, en zolang TTFB hoog blijft kan de rest van de pagina niet beginnen met laden.

Wat TTFB eigenlijk meet

TTFB is geen enkele fase. Het is de optelsom van alles wat gebeurt voordat het antwoord begint te stromen: redirects, DNS-lookup, de TCP-verbinding, de TLS-handshake, het verzoek verzenden, de server die het verwerkt en de eerste byte die terugkomt. Bij WordPress is die serververwerking PHP-FPM die het verzoek oppakt, WordPress die boot, plugins die laden, databasequeries die draaien en de HTML die wordt opgebouwd.

Die bundeling is wel belangrijk. Twee sites op identieke hardware kunnen heel verschillende cijfers laten zien: de ene doet misschien een 301-redirect met een koude DNS-cache, de andere komt direct binnen op een warme edge node. In Chrome DevTools heet de serverkant in het Timing-tabblad "Waiting (TTFB)" en de omliggende fases krijgen aparte regels. "Waiting (TTFB)" in DevTools is specifiek het wachten op de server, terwijl de TTFB-waarde die veldtools rapporteren ook de connectiefases meeneemt.

Wat is een hoge TTFB?

De huidige drempels van web.dev zijn concreet:

• Goed: 800 ms of minder
• Verbeteren: tussen 800 ms en 1.800 ms
• Slecht: meer dan 1.800 ms

Deze drempels zijn doelen voor het 75e percentiel van echte gebruikersmetingen, niet voor één losse test. Een site die lokaal 300 ms haalt maar voor een bezoeker drie tijdzones verderop opspringt naar 1.200 ms, zit voor de meeste regio's nog in "goed" en voor de andere tegelijk in "verbeteren". TTFB is een verdeling, geen getal.

TTFB is ook geen Core Web Vital. Het is een upstream-input voor Largest Contentful Paint en First Contentful Paint. Is je LCP goed, dan is een TTFB in de middenband op zichzelf geen probleem. Is je LCP slecht, dan is TTFB meestal de eerste plek waar je gaat kijken.

Waar de tijd in een WordPress-TTFB heen gaat

Bij een ongecachete aanvraag is bijna heel TTFB serververwerking. Netwerk- en handshake-fases voegen vanaf hetzelfde continent meestal 50 tot 150 ms toe. Alles daarboven is WordPress die de pagina opbouwt.

• PHP boot en het laden van opcodes. Elk verzoek heeft WordPress core, alle actieve plugins en het thema in geheugen nodig. De opcache-extensie van PHP bewaart de gecompileerde bytecode in shared memory, zodat die kosten één keer per worker worden betaald. Een opcache die uitstaat, te klein is of te vaak wordt gevalideerd, voegt honderden milliseconden aan elke TTFB toe. OPcache goed configureren voor WordPress loopt door de directieven die ertoe doen, een productie-klaar profiel en de cache-reset discipline die je in je deploy nodig hebt.
• Databasequeries. Een WordPress-paginabuild doet tientallen queries op wp_options, wp_posts, wp_postmeta en de term-tabellen. Eén trage query, een ontbrekende index of een N+1-patroon uit een plugin slaat door naar TTFB. Zie het artikel over de trage database in WordPress.
• Synchrone externe calls. Plugins die tijdens de paginabuild een externe API aanroepen (licentiechecks, analytics, verzendkosten) blokkeren PHP totdat de andere kant antwoordt. Eén trage API telt zijn hele latency op bij TTFB.
• Wachttijd in de PHP-FPM pool. Als alle workers bezet zijn, wacht het volgende verzoek in een kernel socket queue voordat er überhaupt een worker mee aan de slag gaat. Die wachttijd is voor WordPress onzichtbaar maar komt rauw terug in TTFB. Het artikel over PHP workers legt het mechanisme uit.

Bij een volledig gecachete aanvraag (Varnish, nginx fastcgi_cache, LSCache of een CDN-edge) draait WordPress niet en stort TTFB in tot de netwerkfases plus de cache-lookup, meestal ruim onder de 200 ms.

Waarom TTFB alles vóór de eerste byte meeneemt

TTFB lijkt de eerste keer dat je het ziet een rare maatstaf. Waarom DNS en TLS op één hoop met serververwerking? Omdat dat vanuit de browser precies de wachttijd is voordat er iets kan gebeuren. De browser kan geen HTML parsen, geen scripts draaien en niks tekenen voordat die eerste byte binnen is. Pre-TTFB tijd is dode tijd, of de vertraging nu zit in een trage DNS-resolver of in een trage database.

Daarom gaat het bij WordPress-performance ook altijd over caching. Een full-page cache maakt WordPress niet sneller. Het slaat WordPress gewoon over. TTFB daalt omdat de server minder hoeft te doen, niet omdat hij sneller is geworden.

Wat dit betekent voor een WordPress-site in de praktijk

De verdeling van TTFB over je site vertelt je waar je moet kijken. Een paar patronen herken ik meteen:

• Hoog op ongecachete pagina's, laag op gecachete. De cache doet zijn werk en het knelpunt zit in het PHP-pad. Hier loont het om plugins, database-indexen en de worker pool te tunen.
• Hoog op pagina's voor ingelogde bezoekers, laag voor uitgelogde. De WordPress-admin omzeilt de meeste caches. Werkt jouw team in wp-admin en is de voorkant snel? Dan is dit te verwachten, totdat de admin zo traag wordt dat het echt werk gaat blokkeren.
• Hoog alleen onder druk. De server is op zichzelf snel maar houdt het niet vol bij gelijktijdigheid. Meestal wachttijd in de PHP worker queue of contention op de database. Vergelijk dit met het artikel over hoog CPU-gebruik om CPU-saturatie uit te sluiten.
• Overal en altijd hetzelfde. Vaak een synchrone externe API-call in de paginabuild, of een kapotte opcache waardoor elk verzoek opnieuw PHP moet compileren.

Wat TTFB NIET is

De meeste verwarring rond een "hoge TTFB" komt doordat mensen het ding zien als iets wat het niet is.

• Geen paginalaadtijd. TTFB stopt op het moment dat de eerste byte binnen is. HTML parsen, CSS, JavaScript, afbeeldingen en fonts moeten daarna nog gebeuren. Een site met 100 ms TTFB en 4 seconden LCP heeft een front-end probleem. Een site met 1.500 ms TTFB en 2 seconden LCP heeft juist een serverprobleem.
• Geen enkel getal. TTFB varieert per route, per cache-status, per locatie van de bezoeker en per belasting. Eén meetpunt uit één synthetische test zegt bijna niks. Velddata van echte gebruikers, opgesplitst per percentiel en regio, is het eerlijke beeld.
• Geen doel op zich. TTFB is een diagnose. web.dev framet het zelf zo: zolang LCP en de andere Core Web Vitals goed zijn, hoef je een TTFB in de middenband niet koste wat kost omlaag te jagen. De reden om TTFB te volgen is dat een hoge waarde de andere metrics moeilijker haalbaar maakt.
• Geen probleem dat een CDN automatisch oplost. Een CDN duwt TTFB omlaag voor assets die het aan de edge kan cachen. Voor dynamische WordPress-responses die de edge-cache omzeilen (ingelogde gebruikers, winkelwagens, checkouts, REST API-calls) voegt het CDN vooral een hop toe. Het verzoek moet nog steeds naar de origin reizen, door PHP-FPM heen en weer terug. De aanname dat een CDN een trage WordPress-origin op dynamische pagina's wel even fixt, is de meest voorkomende misvatting over wat een CDN doet.
• Geen pure server response time. De meting omvat ook DNS, TLS en redirects. Een site die twee redirects achter elkaar doet voordat de echte pagina laadt, draagt de volle kosten in TTFB, ook al is de server zelf instant.

Waar je verder kunt kijken

Komt de hoge TTFB vooral in de admin terug? Dan legt het artikel over de trage WordPress-admin uit waarom admin-requests als eerste de resources opslokken. Voelt de hele site traag aan en weet je nog niet waar de vertraging zit? Dan loopt het algemene artikel "WordPress site is traag" door hoe je de juiste laag isoleert. Zit het probleem in queueing onder druk in plaats van in losse trage requests? Dan beschrijft het artikel over PHP workers het worker-poolmodel waaruit die TTFB-pieken ontstaan, en legt de PHP-FPM tuninggids uit hoe je de pool correct dimensioneert en configureert.