Trace a Slow Network Request One Phase at a Time

A user reports that a page took three seconds to open. A ping to the server takes 20 milliseconds. Those observations measure different work. Split the request into phases before deciding whether to call the network team or the application team.

Record cumulative timestamps

For a single HTTPS request over TCP, curl can report time to name lookup, connect, TLS completion, first response byte and total completion. On a POSIX shell, start with:

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

These values are elapsed seconds from the beginning, not independent durations. For a fresh direct connection, subtract lookup from connect to approximate the TCP phase, and connect from appconnect for the TLS phase. Redirects, proxies, protocol differences and connection reuse change the interpretation. Record the actual status and redirect chain before comparing runs.

Interpret a gap without guessing its cause

Imagine lookup at 0.010 s, connect at 0.035 s, TLS at 0.070 s and first byte at 1.400 s. The large gap occurs after TLS setup. It might include proxy queueing, network delay, application execution or a slow upstream. It does not by itself prove the database is slow. Compare the same path with edge and origin timing or a correlated request trace.

A long interval between first byte and completion instead suggests a different investigation: response size, throughput, flow control or slow streaming generation.

Repeat under useful conditions

Measure the same hostname, location and path several times. Record warm and cold behavior separately. A fast cached landing page is a poor control for a slow personalized endpoint. Finish by reproducing the initial symptom from the original user path and showing which phase actually improved.

Further reading

curl: write-out

Related guide: Follow a Web Request from DNS to Database.