TTFB vs responstijd vs latency: wat elk meet

Wat elke term betekent

Netwerklatency, vaak gerapporteerd als round-trip time, is de tijd die een pakket doorbrengt op weg naar de server en terug, zonder applicatiewerk ertussenin. Ze wordt bepaald door de fysieke afstand, het aantal hops en de kwaliteit van de route. Niets wat u in uw code doet, verandert ze.

Time to first byte (TTFB) wordt gemeten vanaf het moment dat de client het verzoek start tot de eerste byte van het antwoord bij hem aankomt. Dat interval bevat de DNS-opzoeking, de TCP-verbinding, de TLS-handshake, de tijd die het verzoek onderweg doorbrengt, wat de server ook doet om een antwoord te produceren, en de terugreis. TTFB is daarom altijd groter dan één round trip, meestal een veelvoud.

Responstijd is de losste term van de drie. De meeste monitoringtools gebruiken hem voor de totale tijd om het verzoek af te ronden, van het eerste pakket tot de laatste byte van de body. Sommige tools gebruiken hem als synoniem voor TTFB. Voordat u twee getallen vergelijkt die "responstijd" heten, controleert u waarop elke tool de klok stopzette.

Hoe elk wordt gemeten

Latency komt van een ICMP-echo, wat ping verstuurt, of van het timen van de TCP-handshake wanneer ICMP is geblokkeerd. TTFB en totale tijd komen van de HTTP-client zelf. Eén curl-aanroep drukt alle grenzen af:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Elke waarde is cumulatief vanaf het begin van het verzoek, dus u leest ze als grenswaarden en niet als duren. Trek de vorige waarde ervan af om de lengte van een fase te krijgen.

Welk getal uw tool u toont

Elke tool rapporteert een andere schijf van hetzelfde verzoek, wat meestal de reden is waarom twee metingen van één site niet overeenkomen:

• ping rapporteert alleen round-trip latency, zonder enig serverwerk erbij
• curl -w rapporteert elke hierboven genoemde grens, wat het de referentie maakt wanneer getallen niet overeenkomen
• Browserontwikkelaarstools tonen TTFB als de wachtfase van een verzoek, gescheiden van de downloadfase eronder
• Lighthouse en PageSpeed rapporteren serverresponstijd, wat TTFB is voor het documentverzoek
• Uptimemonitors rapporteren een responstijd waarvan de definitie per product verschilt, en die de verbindingsopbouw meerekent vanaf waar de check ook draaide
• Real user monitoring rapporteert veld-TTFB, samengevoegd over echte bezoekers op echte netwerken

Hoe een goed getal eruitziet

Latency wordt begrensd door geografie. Onder de 30 ms is normaal binnen één stedelijk gebied, 50 tot 100 ms over een continent, en 150 tot 250 ms tussen continenten. Een route die ver boven de afstand meet, wijst eerder op een slecht pad dan op een trage server.

Voor TTFB behandelt web.dev 800 ms of minder als goed en alles boven 1,8 seconden als slecht, terwijl de audit voor serverresponstijd van Lighthouse boven de 600 ms begint te falen. Streef naar onder de 600 ms voor het documentverzoek en behandel 200 ms als het doel voor alles dat gecachet of statisch wordt geserveerd.

De totale responstijd hangt af van de grootte van wat u verstuurt, dus er is geen universeel cijfer. Meet uw eigen basislijn op een normale dag en behandel de afwijking daarvan als het signaal, niet het absolute getal.

De verschillen lezen

De losse getallen doen er minder toe dan de afstand ertussen, omdat elk verschil naar een ander subsysteem wijst:

• TTFB min round-trip latency is ruwweg hoe lang de server aan het nadenken was. Als dat het grootste deel is, ligt het probleem bij applicatiecode, een trage query of een koude cache
• Connect min DNS-opzoeking is één round trip voor de TCP-handshake. Is dat veel groter dan uw gemeten latency, dan is het netwerkpad overbelast of verkeerd gerouteerd
• TLS min connect is de kosten van de handshake, doorgaans één of twee extra round trips, en een grote waarde wijst op problemen met de certificaatketen of sessieherstel
• Totaal min TTFB is transfertijd. Domineert dat, dan is het antwoord te groot of de verbinding te traag, en helpt geen servertuning
• DNS-opzoeking op zich zou eenmaal gecachet slechts enkele milliseconden moeten zijn. Een consequent trage opzoeking is een resolver- of autoritatief-nameserverprobleem, geen webserverprobleem

Dezelfde lezing werkt omgekeerd wanneer alleen één locatie traag is. Overal gelijke denktijd van de server, met het verschil volledig in latency en transfer, betekent dat de server in orde is en de route niet. Voer de check vanaf meerdere plekken uit voordat u aan de applicatie sleutelt.

Het op één plek meten

Om deze getallen voor een pagina te zien zonder ze handmatig samen te stellen, voert u de pagesnelheidstest uit, die de pagina vanaf een externe locatie laadt en de belasting opsplitst in fasen. De handleiding serverresponstijd behandelt dezelfde meting vanaf de commandoregel. Eén meting vertelt u alleen iets over dat moment, dus als het getal ertoe doet, zet er een geplande check op: HostTracker meet de responstijd bij elke check vanaf 300+ meetpunten in 158 steden, en dat is wat één meting omzet in een basislijn waartegen u een terugval kunt herkennen. Meer definities staan in het onderdeel monitoringconcepten.