Browser and frontend
From URL to first byte: DNS, TCP and TLS
The time spent before the server runs a single line of code, and how to shorten it.
Understand the concept
The name you type is first translated into an IP address. DNS resolution is instant if cached, otherwise it takes a few round trips. Then a TCP connection opens and a TLS handshake follows: the server presents its certificate, the browser verifies it and both sides agree on a shared encryption key. TLS 1.3 does this in one round trip.
These steps are independent of server code but part of what the user waits for. The time until the first byte arrives is called TTFB (Time to First Byte) and sums connection setup, server processing and network latency.
Connections are expensive, so they are reused. HTTP/2 and HTTP/3 carry many requests concurrently over one connection, which is why spreading a page’s assets over many domains now usually hurts rather than helps. For HTTP and TLS details, see the HTTP & HTTPS learning centre.
Speeding up server code does not compensate for slow connection setup.
Measuring only server processing time when investigating a slow page.
One topic. Three levels of depth.
nslookup ataberksahin.net
→ Address: 203.0.113.10The domain resolves to an IP address.
This page connects to no real server or database. Code samples are illustrative for .NET 8, Next.js and SQL Server; timings are example values in the simulation, not measurements. Try samples only in your own development environment; never share real connection strings, tokens or passwords.
Try it yourself first.
curl shows ‘dns:0.004 tcp:0.090 tls:0.250 ttfb:0.270’. Roughly how long did the server itself take, and where is the real problem?
Show the solution and explanation
Sunucu işlemi ≈ 0.270 − 0.250 = 20 ms
Asıl maliyet bağlantı kurulumunda: TCP ~86 ms, TLS ~160 ms
→ uzak sunucu/yüksek gecikme; CDN, bağlantı yeniden kullanımı, TLS 1.3The values are cumulative; the differences give each phase. Network distance dominates here, not server code.