Measure first, and it takes one command
curl will break a request into its phases. This is the most useful command in this course:
curl -o /dev/null -s -w '\
dns %{time_namelookup}s
tcp %{time_connect}s
tls %{time_appconnect}s
ttfb %{time_starttransfer}s
total %{time_total}s
' https://addaly.com/Each number is cumulative from the start, not a duration, which trips people up. Subtract to get the phases. A realistic result from a phone-speed connection in Mumbai hitting a server in Virginia:
dns 0.028s
tcp 0.211s
tls 0.402s
ttfb 0.638s
total 0.661sRead that as: DNS took 28ms, the TCP handshake took 183ms, the TLS handshake took another 191ms, your server took 236ms to produce the first byte, and the body took 23ms.
Now notice what you just learned. Your code is responsible for 236ms of a 661ms request. Doubling the size of the server improves the number that is not the problem.
The part that is physics
Light in fibre travels at roughly 200,000 km per second, and real routes are not straight. Mumbai to northern Virginia is about 13,000 km, so one way is about 65ms and a round trip about 130ms at the theoretical floor. In practice you see 180 to 220ms.
Now count the round trips before your code runs:
- DNS: one round trip, if it is not cached.
- TCP handshake: one round trip.
- TLS handshake: one round trip on TLS 1.3, two on TLS 1.2.
So a cold connection from India to a US server spends about 400ms doing nothing but agreeing to talk. No amount of optimisation touches that, because it is distance. This is the entire argument for a CDN: not bandwidth, but shortening the round trip. “The server is fast” and “the site is fast” are different claims, and the gap between them is measured in kilometres.
Two consolations. TLS session resumption skips a round trip on repeat visits. And keep-alive means the second request on the same connection skips both handshakes, which is why your first page load feels slow and everything after it feels fine.
The DNS number is lying to you
The first measurement includes a cold resolver lookup. Run it again and DNS will read close to zero, because your machine cached it. Both numbers are true: the first is what a new visitor gets, the second is what a returning one gets. Report which you measured.
Cold starts, and why your monitoring disagrees with your users
Two flavours, both worth knowing:
- Serverless functions that have been idle boot on demand: usually 100ms to 1 second, longer for a big dependency tree or a JVM.
- Free-tier containers that scale to zero (the default on several free plans) sleep after about 15 minutes of no traffic and take 5 to 30 seconds to wake. The first visitor of the day gets a page that appears broken.
Here is the trap. An uptime monitor pinging every five minutes keeps the container permanently warm. Your dashboard shows a fast, healthy site. Your users, arriving one at a time to a service nobody else is using, see the cold start every time. The monitoring is not wrong; it is participating.
One page is not one request
The HTML is request one. Then come the stylesheets, the fonts, the JavaScript, the images, the analytics tag and the chat widget. A modest page makes 40 to 80 requests, and requests to a new hostname pay their own DNS, TCP and TLS costs, which is why one third-party script can cost more than your entire backend.
Open the network tab, sort by time, and look at what is on the critical path. A render-blocking stylesheet on a third-party domain is a classic: 400ms of blank screen that has nothing to do with your server.
Fix in this order
- Shorten the distance. Static assets on a CDN. If your framework allows it, HTML from the edge too. This is usually the largest single win and it is often free.
- Remove round trips. Keep-alive, HTTP/2 or HTTP/3, fewer distinct origins, no redirect chains: each redirect is a whole extra request including handshakes.
- Then make your code faster.
Almost everyone starts at three, because it is the part they wrote and the part they can see.
Every lesson here is open. Your progress is recorded once you pass the Agents and Automation exam.
Check your understanding
Your server-side timing shows a median response time of 40ms, and your five-minute uptime monitor agrees the site is fast. Users in another country report that the site takes several seconds to load, especially the first visit of the day. Which explanation fits all three observations?
Pick the one you would defend. Your answer stays private.
Stuck on something?Ask Tri, your AI tutor