TTFB verlagen: zo verkort je de Time to First Byte

TTFB verlagen betekent: de tijd verkorten tussen het moment dat een browser een pagina opvraagt en het moment dat de eerste byte van het antwoord binnenkomt. In de praktijk komt dat neer op drie dingen: laat server en applicatie de HTML sneller genereren, lever gecachete HTML zodat de meeste verzoeken dat werk helemaal overslaan, en breng het antwoord dichter bij je bezoekers. Deze gids laat zien hoe je uitzoekt welke van de drie jouw bottleneck is en wat je aan elk ervan doet.

Wat TTFB meet

Time to First Byte is niet één ding. Het is de som van meerdere fasen die plaatsvinden voordat er ook maar iets van de inhoud binnenkomt:

1. Redirects, als de opgevraagde URL eerst naar een ander adres doorverwijst.
2. DNS-lookup, het omzetten van je domeinnaam naar een IP-adres.
3. Verbinding opzetten, de TCP-handshake plus de TLS-onderhandeling voor HTTPS.
4. Verzoek en serververwerking, de tijd die je server nodig heeft om het antwoord op te bouwen (PHP uitvoeren, de database bevragen, templates renderen).
5. De eerste byte die terugreist naar de browser.

Daarom kunnen twee sites op identieke servers een heel verschillende TTFB hebben: de ene staat misschien dicht bij de bezoekers en levert gecachete pagina's, de andere staat op een ander continent en rendert elk verzoek opnieuw.

TTFB is geen van de drie Core Web Vitals, maar het ligt onder alle drie. Er kan niets gerenderd worden voordat de eerste byte binnen is, dus een trage TTFB schuift de Largest Contentful Paint direct naar achteren. Is je LCP slecht, dan is de TTFB een van de eerste dingen om te controleren. De gids over Core Web Vitals laat zien hoe de meetwaarden samenhangen.

Wat is een goede TTFB?

De richtlijn van web.dev over TTFB (Engelstalig) raadt de meeste sites aan om te streven naar een TTFB van 0,8 seconden of minder, gemeten op het 75e percentiel van echte laadbeurten. Waarden boven 1,8 seconden gelden als slecht.

Houd hierbij twee dingen in gedachten. Ten eerste beschrijven deze cijfers echte gebruikers op echte netwerken, inclusief trage mobiele verbindingen ver van je server. Een test vanaf je kantoor naast het datacenter ziet er veel beter uit dan wat een bezoeker op een ander continent ervaart. Ten tweede is 0,8 s een vuistregel, geen harde grens. Sites die volledig aan de clientkant renderen, kunnen iets meer hebben; server-gerenderde sites, en daar vallen de meeste WordPress- en webshopopstellingen onder, hebben er baat bij om er ruim onder te zitten.

Meet en vind de trage fase

Meet eerst waar de tijd blijft voordat je iets verandert. Een snelle controle vanaf de commandline:

curl -o /dev/null -s -w "dns:      %{time_namelookup}\nconnect:  %{time_connect}\ntls:      %{time_appconnect}\nttfb:     %{time_starttransfer}\ntotal:    %{time_total}\n" https://example.com/

Elke waarde is cumulatief, in seconden. Trek ze van elkaar af om de fasen te krijgen:

• connect - dns is de netwerk-round-trip naar de server.
• tls - connect is de HTTPS-handshake.
• ttfb - tls is ongeveer de verwerkingstijd op de server plus één round trip.

Voer het meerdere keren uit, want het eerste verzoek betaalt vaak de prijs voor een koude cache of een verse DNS-lookup. Blijft ttfb - tls hoog (zeg enkele honderden milliseconden of meer) terwijl de netwerkfasen klein zijn, dan is je server de bottleneck. Zijn de netwerkfasen groot, dan zitten afstand en verbindingsoverhead in de weg.

Voor cijfers van echte gebruikers test je de pagina op corewebvitals.page en kijk je naar de velddata van Chrome-gebruikers, die beschikbaar is als je site genoeg verkeer heeft. In Chrome DevTools toont het tabblad Netwerk voor elk verzoek een uitsplitsing van de timing: "Waiting for server response" is het serverdeel van de TTFB. De gids over websitesnelheid meten legt uit hoe je deze bronnen combineert zonder jezelf voor de gek te houden.

Maak server en applicatie sneller

Neemt de verwerkingstijd het grootste deel in, dan ligt de oplossing op de origin. Werk deze punten op volgorde af, van goedkoop naar bewerkelijk:

Werk de runtime bij

Nieuwere versies van PHP, Node.js of Python zijn voor hetzelfde werk vaak merkbaar sneller. Kijk welke versie je host draait en of je CMS en plug-ins een nieuwere ondersteunen.

Voeg een object cache toe

WordPress, WooCommerce, Shopware, Magento en Drupal draaien allemaal veel herhaalde databasequery's. Een persistente object cache zoals Redis of Memcached houdt die resultaten tussen verzoeken in het geheugen. Veel managed hosts bieden dat aan als schakelaar.

Vind trage query's en plug-ins

Eén plug-in die bij elke laadbeurt een dure query draait, kan de TTFB volledig domineren. Gebruik een profiler of query monitor op een stagingkopie, schakel verdachte plug-ins één voor één uit en meet opnieuw. In webshops zijn gefacetteerde filters, widgets voor gerelateerde producten en live voorraadcontroles bekende boosdoeners.

Controleer de serverresources

Is de TTFB 's nachts prima en op piekmomenten slecht, dan raken CPU, geheugen of PHP-workers op. Meer resources of een beter hostingpakket kunnen hier de juiste keuze zijn, en geen enkele front-endoptimalisatie lost dit op.

Cache volledige HTML-pagina's

De meeste verzoeken naar een doorsnee website gaan over pagina's die er voor elke anonieme bezoeker hetzelfde uitzien. Die telkens opnieuw genereren is verspild werk. Een full-page cache bewaart de kant-en-klare HTML en geeft die terug zonder PHP of de database aan te raken, en dat heeft meestal het grootste afzonderlijke effect op de TTFB.

Je kunt op verschillende lagen cachen:

• In de applicatie, met een cachingplug-in of een ingebouwde HTTP-cache (Shopware en Drupal hebben er een). De WordPress-documentatie over caching (Engelstalig) geeft een goed overzicht van de mogelijkheden.
• Op de server, met een reverse proxy zoals Varnish of een Nginx-cache.
• Aan de edge, op een CDN of edge-netwerk, zodat gecachete pagina's worden geleverd vanaf een locatie dicht bij de bezoeker.

Welke laag je ook kiest, wees streng in wat niet gecachet mag worden: winkelwagens, checkout, accountpagina's, ingelogde sessies en alles wat gepersonaliseerd is. Die verzoeken moeten de cache omzeilen en elke keer naar de origin gaan. Sturen je pagina's zinnige Cache-Control-headers mee, dan kan elke laag die volgen.

Controleer aan de response-headers of een pagina echt uit de cache kwam:

curl -sI https://example.com/ | grep -i -E "cache|age"

Een cache die bestaat maar zelden raak is, doet weinig. Lage hitrates komen meestal door cookies of querystrings die elk verzoek uniek laten lijken, of door te korte cacheduur.

Verklein de afstand tot je bezoekers

Elke round trip tussen browser en server kost tijd, en een nieuwe HTTPS-verbinding heeft er meerdere nodig voordat de eerste byte kan stromen. Staat je server in Frankfurt en zit een bezoeker in Sydney, dan voegt de natuurkunde alleen al een merkbare vertraging toe aan elk van die round trips, hoe snel de server ook is.

Er zijn twee manieren om die afstand te verkleinen:

• Host dicht bij je publiek. Zitten bijna al je bezoekers in één land, dan is een server in of vlak bij dat land de eenvoudigste winst.
• Lever vanaf een edge-netwerk. Een CDN handelt verbindingen af op een locatie dicht bij de bezoeker en antwoordt, als de pagina daar gecachet is, zonder je origin te benaderen. De gids Wat is een CDN legt uit wat dat wel en niet oplost.

Een edge-netwerk helpt ook ongecachete verzoeken een beetje, omdat de TLS-handshake dichtbij plaatsvindt en de edge een warme verbinding met de origin kan hergebruiken. De grote winst komt echter van cache hits.

Schrap redirects en verbindingsoverhead

Kleine dingen tellen op, vooral op mobiele netwerken:

• Vermijd redirectketens. http://example.com naar https://example.com naar https://www.example.com naar https://www.example.com/en/ zijn drie extra round trips voordat er iets nuttigs gebeurt. Link direct naar de uiteindelijke URL en houd het bij hooguit één redirect.
• Gebruik HTTP/2 of HTTP/3 en TLS 1.3. Die beperken het aantal round trips voor het opzetten van de verbinding en laten de browser veel resources over één verbinding ophalen.
• Gebruik een snelle DNS-provider. Voor nieuwe bezoekers is DNS onderdeel van de TTFB. Providers met anycast of GeoDNS antwoorden vanaf locaties in de buurt.
• Zet compressie aan. Brotli of gzip voor HTML verandert weinig aan de eerste byte, maar verkort de rest van de download die daarop volgt.

Zo helpt fast.site je

fast.site zit vóór je bestaande hosting en richt zich op het netwerk- en cachedeel van de TTFB. Je houdt je host; je laat de nameservers van je domein naar fast.site wijzen, en na verificatie loopt je verkeer via het edge-netwerk.

De Fast Edge Cache™ bewaart cachebare pagina's aan de edge. Bij een cache HIT komt het antwoord rechtstreeks van de edge, zonder je origin te benaderen; bij een MISS wordt de pagina één keer opgehaald en opgeslagen. De vervaltijd volgt de Cache-Control-headers van je origin of je eigen regels, en een cache warmer houdt belangrijke pagina's warm. Winkelwagens, checkout en ingelogde sessies omzeilen de cache, wat de header fs-cache als BYPASS meldt. Je kunt elke URL controleren zoals beschreven in de cache controleren, en de cachingdocumentatie legt de regels uit.

GeoDNS stuurt bezoekers naar de dichtstbijzijnde gezonde edge, met regio's in Noord-Amerika, Europa, Azië-Pacific en Zuid-Amerika, afhankelijk van je abonnement (zie regio's). Certificaten worden automatisch uitgegeven en verlengd.

Een trage databasequery maakt fast.site niet sneller, dus verbeteringen op de origin blijven belangrijk voor ongecachete pagina's. De analytics in het dashboard tonen TTFB en cache hit ratio, zodat je het effect op je eigen site kunt meten. Dat kan bijvoorbeeld tijdens een gratis proefperiode van 7 dagen.

Veelgestelde vragen

Heeft TTFB invloed op SEO?

TTFB is geen van de Core Web Vitals die Google als signaal voor paginagebruik gebruikt. Het vertraagt wel de Largest Contentful Paint, en die hoort er wel bij. Een betere TTFB draait dus vooral om een betere LCP en een site die sneller aanvoelt, niet om een directe boost in de rankings.

Waarom is mijn TTFB alleen bij het eerste bezoek hoog?

Het eerste verzoek bevat vaak een DNS-lookup, een nieuwe TLS-handshake en een koude cache op de server of de edge. Latere verzoeken hergebruiken verbindingen en treffen een warme cache. Is de TTFB bij een eerste bezoek belangrijk voor je (en dat is het voor de meeste landingspagina's), kijk dan naar DNS-snelheid, redirects en cache warming.

Waarom is de TTFB in mijn test prima, maar slecht voor echte gebruikers?

Je eigen test draait meestal op een snelle verbinding dicht bij de server, met een warme cache. Velddata, zoals op corewebvitals.page of in Search Console, komt van echte Chrome-gebruikers op allerlei netwerken en locaties, gemeten op het 75e percentiel. Het verschil wijst vaak op afstand of op pagina's die zelden gecachet worden.

Lost een CDN een trage TTFB op?

Het lost het deel op dat door afstand en herhaaldelijk genereren van pagina's ontstaat, zolang je pagina's echt gecachet kunnen worden. Het versnelt geen verzoeken die de origin moeten bereiken, zoals checkout of ingelogde pagina's. Daarvoor blijft tuning van server en applicatie nodig.