De eerste 100 milliseconden: TTFB en AI-crawlers
Wat TTFB is en waarom het zo veel uitmaakt
Time to First Byte. De tijd tussen het moment dat een client een HTTP-verzoek stuurt en het moment dat de eerste byte van het antwoord binnenkomt. Klinkt technisch. Is het ook. Maar de implicatie is simpel: het is de maat voor hoe snel je server reageert.
En het is de metric die ik in twintig jaar het vaakst heb zien negeren terwijl hij de meeste impact heeft.
Ik geef het eerlijk toe: ik ben er een beetje geobsedeerd door. Mijn collega's bij Kobalt noemen het soms de "Reinier-metric". Ik draag die titel met trots.
Maar waarom is TTFB zo belangrijk voor AI? Simpel. AI-crawlers crawlen duizenden pagina's per dag met een intern time-budget per domein. Als elke pagina van jouw domein 1,5 seconde wacht op de eerste byte terwijl een concurrent 150 milliseconden nodig heeft, kan die concurrent in dezelfde tijd tien keer zoveel pagina's laten indexeren.
Dat is geen theoretisch nadeel. Dat is een concrete achterstand.
Google zegt: TTFB onder 200 ms is goed, 200-500 ms acceptabel, boven 500 ms moet beter. Maar AI-crawlers gebruiken geen browser-caching en halen elke pagina vers op. De grens is strenger. Bij Kobalt hanteren we een doel van onder de 300 ms voor alle pagina's die je wilt laten indexeren.
De drie componenten van TTFB
TTFB is geen enkele meting. Het bestaat uit drie delen die elk hun eigen oplossing vragen.
Netwerklatency: de reistijd
Voordat je server ook maar kan beginnen met verwerken, moet het verzoek er eerst naartoe reizen. Crawler in Virginia, server in Amsterdam? Minimaal 80 milliseconden round-trip, puur door de snelheid van licht door glasvezel. Daar doe je niet veel aan.
Wat je wel kunt doen: een CDN met edge-locaties dicht bij de crawler. Het verzoek gaat dan naar een node in de buurt die het gecachte antwoord lokaal ophaalt.
Serververwerking: hier zit het echte probleem
Dit is het deel dat het meest onder jouw controle staat. En het meest wordt verwaarloosd. Alles wat je server doet nadat het verzoek binnenkomt: database-queries, PHP verwerken, templates renderen, caching-lagen raadplegen.
Op een slecht geconfigureerde WordPress-installatie zonder caching? 800 milliseconden tot 2 seconden. Voor een simpele blogpost. Ik word er een beetje moedeloos van als ik dat tegenkom. En ik kom het regelmatig tegen.
# Typische TTFB-breakdown zonder caching (WordPress):
Netwerklatency: 80ms
PHP-bootstrapping: 120ms
WordPress-init: 180ms
Databasequeries (34x): 420ms
Template rendering: 160ms
Output buffering: 40ms
-------------------------
Totale TTFB: 1000ms
# Met Redis object caching:
Totale TTFB: 588ms
# Met full-page caching (Nginx FastCGI cache):
Totale TTFB: 100ms
# Dat verschil is niet subtiel.TLS-handshake: het beveiligingstarief
Voor HTTPS-verbindingen voegt de TLS-handshake een extra component toe. Eenmalig per TCP-verbinding. TLS 1.3 heeft dit teruggebracht tot één round-trip, wat de impact ten opzichte van TLS 1.2 halveert. Check of je server TLS 1.3 ondersteunt. In 2026 zou dat standaard moeten zijn.
TTFB verbeteren: wat ik doe bij Kobalt
Goed, genoeg theorie. Wat kun je concreet doen?
- Full-page caching implementeren. Nginx FastCGI cache, Varnish of WP Rocket met pagina-caching. Dit is verreweg de grootste verbetering die je kunt maken.
- Object caching via Redis of Memcached. Elimineert herhaalde database-queries voor menu's, opties en widgets.
- Database-queries optimaliseren. Query Monitor in WordPress laat zien welke queries traag zijn.
- PHP 8.2 of hoger. Tot 30% sneller dan PHP 7.4 voor typische WordPress-workloads. Gratis snelheidswinst.
- HTTP/2 of HTTP/3 inschakelen. Meerdere verzoeken over één verbinding, minder overhead.
- TLS 1.3 gebruiken. Snellere handshake, betere security.
- CDN inzetten. Voor gecachte content daalt de TTFB naar 50-100 ms voor internationale crawlers.
Meten, monitoren, bijsturen
Verbeteren wat je niet meet is gokken. En ik ben geen gokker (behalve die ene keer op de paardenraces, maar dat is een ander verhaal).
- WebPageTest.org: de meest gedetailleerde TTFB-analyse, met waterfall en component-breakdown. Test vanuit meerdere locaties.
- Google Search Console: toont Core Web Vitals inclusief TTFB-gerelateerde data op basis van echte gebruikers.
- curl: snel, scriptbaar, ideaal voor geautomatiseerde checks.
- UptimeRobot of Better Uptime: continue monitoring met alerts bij overschrijdingen.
- Lighthouse: performance-score en breakdown, inclusief server response time.
Test je TTFB altijd vanuit meerdere locaties. Een TTFB van 150 ms vanuit Amsterdam kan 800 ms zijn vanuit San Francisco, waar veel AI-crawlers hun verzoeken vandaan sturen. WebPageTest.org biedt gratis tests vanuit tientallen locaties.
Veelgestelde vragen
Wat is een realistische TTFB voor een WordPress-site?
Met goede caching en een fatsoenlijke VPS: 100-300 milliseconden. Haalbaar voor de meeste WordPress-sites. Zonder caching op shared hosting: 800-2000 ms. Het verschil zit vrijwel volledig in caching-configuratie en hostingkwaliteit. Geen magie. Gewoon goed werk.
Heeft TTFB invloed op mijn Google-ranking?
Ja. Google heeft bevestigd dat server response time een factor is in het crawl-budget dat Googlebot toekent. Hoge TTFB betekent minder pagina's per sessie gecrawld. Plus: hoge TTFB draagt bij aan slechte LCP, wat een directe rankingfactor is. Dubbel positief effect als je het verbetert.
Mijn site heeft een CDN. Waarom is mijn TTFB nog steeds hoog?
Een CDN helpt alleen voor gecachte content. Dynamische pagina's die niet worden gecached gaan alsnog naar je origin-server. Oplossing: configureer je CDN om meer te cachen (met de juiste cache-headers) of implementeer full-page caching op je origin-server. Check ook of je CDN edge-locaties heeft dicht bij de crawlers.
De eerste 100 milliseconden zijn de auditie voor je website. Als je die verknalt, kom je de rest van het gesprek niet in. Een AI-crawler heeft geen tweede kans nodig om te beslissen of jouw server de moeite waard is.
Hoe scoort jouw website op AI-gereedheid?
Krijg binnen 30 seconden je AEO-score en ontdek wat je kunt verbeteren.
