Server response time: de eerste indruk op AI-bots
Waarom server response time ertoe doet voor AI-bots
Ik heb een ongezonde obsessie met Time to First Byte. Ik geef het toe. Als ik een website open, check ik automatisch de TTFB in DevTools. Op feestjes. Op verjaardagen. Mijn gezin heeft het opgegeven er iets van te zeggen.
Maar die obsessie is niet voor niets. TTFB is het eerste wat een AI-crawler ervaart van jouw website. Het is de handdruk. De eerste indruk. En net als bij mensen: als die eerste indruk tegenvalt, is er vaak geen tweede kans.
AI-crawlers hanteren time-outs. GPTBot wacht niet eindeloos. Als jouw server te lang doet over een antwoord, wordt de verbinding verbroken. Je pagina wordt niet geindexeerd. Erger: bij herhaaldelijk trage responses kan een crawler besluiten om je domein minder vaak te bezoeken. Je wordt letterlijk genegeerd.
Google hanteert 200ms als streefwaarde voor TTFB. Alles boven 500ms is problematisch. Boven 800ms? Dan heb je een serieus probleem dat directe aandacht vereist. En ja, ik spreek uit ervaring.
De drie grootste boosdoeners
Na twintig jaar hosting en webdevelopment kan ik de oorzaken van een hoge TTFB dromen. Het zijn bijna altijd dezelfde drie.
1. Trage databasequeries
De nummer een boosdoener. Een WordPress-pagina kan bij het laden tientallen queries uitvoeren. Als die niet geoptimaliseerd zijn, of als er geen index op de juiste kolommen staat, loopt de responstijd snel op.
Mijn aanpak: installeer een query-monitor (WordPress: Query Monitor plugin, Laravel: Debugbar of Telescope) en identificeer de trage queries. Voeg indexen toe waar ze ontbreken, fix N+1 patronen en sla berekende waarden op in de database in plaats van ze bij elke request opnieuw uit te rekenen.
2. Onvoldoende caching
Een dynamische website die bij elk verzoek de database bevraagt, de template rendert en de output samenstelt: dat is inherent traag. PHP en MySQL zijn snel, maar niet "bestand-van-schijf-lezen" snel of "waarde-uit-Redis-halen" snel.
Bij Kobalt configureren we standaard meerdere caching-lagen: object caching via Redis, full-page caching voor anonieme bezoekers, CDN-caching voor statische assets. Die combinatie brengt TTFB bij de meeste sites terug naar onder de 100ms. Dat is niet magie, dat is gewoon degelijke infrastructuur.
3. Onderdimensioneerde hosting
Dit is een gevoelig punt, want niemand wil horen dat zijn hosting te goedkoop is. Maar ik ga het toch zeggen.
Shared hosting van vijf euro per maand is prima voor een hobbysite met honderd bezoekers per dag. Voor een zakelijke website die AI-bots wil bedienen? Onvoldoende. Gedeelde CPU, gedeeld geheugen, gedeelde I/O met tientallen andere sites. De stap naar een VPS of managed platform zoals Laravel Cloud kost meer, maar de TTFB halveert typisch meteen.
Stappenplan: van traag naar snel
- Meet eerst. Google PageSpeed Insights, WebPageTest of GTmetrix. Doe het vanaf meerdere locaties. Een meting is geen meting.
- Identificeer de bottleneck. Server zelf (hoge CPU)? Database (trage queries)? Applicatie (inefficiente code)? Je kunt pas fixen wat je begrijpt.
- Implementeer Redis object caching als je dat nog niet hebt. De snelste manier om databaselast te verlagen bij dynamische sites.
- Schakel full-page caching in voor anonieme bezoekers. WordPress: WP Rocket of W3 Total Cache. Laravel: response caching middleware.
- Check je PHP-versie. PHP 8.3 is significant sneller dan 7.x. Dit is een gratis performance-upgrade. Gratis! Waarom draai je nog op 7.4?
- Overweeg een CDN. Cloudflare's gratis plan verlaagt de TTFB al aanzienlijk door responses aan de edge te cachen.
Bij een e-commerce klant met een TTFB van 1,2 seconden (!) identificeerden we drie N+1 query-patronen en twee ontbrekende database-indexen. Na het oplossen, gecombineerd met Redis object caching, daalde de TTFB naar 180ms. Geen nieuwe server nodig. Alleen slim kijken naar bestaande code.
TTFB en AI-crawl frequentie
Er is nog een indirect verband dat ik wil noemen. AI-crawlers houden bij hoe snel een website reageert en passen hun crawl-gedrag daarop aan. Een consistent lage TTFB geeft het signaal: deze server is stabiel en betrouwbaar. Dat vergroot de kans dat je vaker wordt gecrawld en sneller wordt bijgewerkt in de kennisbasis van AI-modellen.
Het is een beetje als vogelgedrag. (Ja, ik ga daar een vergelijking van maken.) Vogels komen terug naar plekken waar ze betrouwbaar voedsel vinden. AI-crawlers komen terug naar servers die betrouwbaar snel reageren. Consistentie wint.
Serverperformance is geen luxe. Het is de fundering waarop alles rust: je Google-rankings, je conversieratio, je AI-zichtbaarheid. Investeer er vroeg in, want achteraf fixen is altijd duurder. Benieuwd hoe jouw server scoort? Check het met onze gratis AEO-scan.
Veelgestelde vragen
Wat is een goede TTFB voor mijn website?
Onder de 200ms voor je HTML-document. Met een CDN is onder de 100ms voor gecachte pagina's haalbaar. Statische assets (CSS, JS) mogen sneller zijn omdat browsers die cachen. Maar het HTML-document is je eerste indruk.
Heeft mijn hosting-locatie invloed op de TTFB voor AI-bots?
Ja. AI-crawlers verbinden doorgaans vanuit datacenters in de VS. Server in Europa? Dan voegt de geografische afstand latentie toe. Een CDN met edge-locaties in de VS lost dat grotendeels op. Overweeg ook of je hosting-locatie logisch is voor je doelgroep.
Kan ik TTFB meten per pagina of alleen voor de hele site?
Per pagina. Tools zoals WebPageTest en Chrome DevTools geven je de TTFB per individueel request. Nuttig om te zien welke pagina's achterblijven. Pagina's met complexe queries of veel dynamische content hebben doorgaans een hogere TTFB. Daar ligt je verbeterpotentieel.
Hoe scoort jouw website op AI-gereedheid?
Krijg binnen 30 seconden je AEO-score en ontdek wat je kunt verbeteren.
