Performance: Which Phase Is Actually Slow?
Using browser DevTools and curl's timing output to isolate whether DNS, connection, TLS, or the server itself is the bottleneck.
Tools required: browser DevTools, curl
Overview
"The site is slow" could mean five completely different things happening under the hood. Breaking a page load into its phases (DNS, TCP connect, TLS handshake, waiting for the server, downloading content) tells you exactly where the time actually goes.
Step-by-Step Manual Check
Break the request into timed phases with curl
curl can report the exact duration of each phase of a request instead of just the total time, which is the key to isolating where the delay actually happens.
curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://example.comOn Windows, replace /dev/null with NUL, or run this inside Git Bash/WSL.
Healthy result
dns: 0.02s connect: 0.05s tls: 0.12s ttfb: 0.25s total: 0.31s (each phase is a small fraction of a second, and ttfb/total are close together)
Problem result
dns: 0.02s connect: 0.05s tls: 0.12s ttfb: 3.8s total: 3.9s (a large gap opens at one specific phase)
What it means
Whichever phase has the largest jump is the bottleneck. A slow ttfb (time to first byte) with fast dns/connect/tls means the server itself is slow to generate the response - a backend/database problem, not a network problem. A slow dns phase points back to the DNS Resolution guide instead.
If unresolved, escalate to: Level 2 — Intermediate
Confirm visually with the browser's Network waterfall
The waterfall view shows the same phases curl measured, but for every resource on the page (images, scripts, stylesheets), not just the main document.
F12 > Network tab > reload the page > click the main document request > Timing tabHealthy result
Waiting for server response (TTFB) is a small proportion of the total bar length; most resources load in parallel and finish quickly.
Problem result
One or two requests show a very long green/Waiting bar, or many requests appear to queue up one after another instead of loading in parallel.
What it means
A single long-Waiting request matches curl's slow-ttfb finding and confirms a backend issue. Many requests queuing serially instead of in parallel points to a different problem entirely - too many render-blocking resources or a connection-limit issue, not raw server slowness.
If unresolved, escalate to: Level 2 — Intermediate
Repeat from a second network/location to rule out the visitor's own path
Distinguishes "the site is slow for everyone" from "the site is slow for this one user/location", which points troubleshooting in very different directions.
Run the same curl -w timing command from a different network (mobile hotspot, a different office, a cloud VM) and compare.Healthy result
Similar timings from both locations.
Problem result
Fast from one location, consistently slow from another.
What it means
If it's only slow from one location, the bottleneck is in that specific network path (ISP routing, a local proxy, a slow VPN) - see the Ping & Packet Loss guide next, rather than a server-side problem.
If unresolved, escalate to: Level 2 — Intermediate
Interpreting the Results
Always separate 'slow to start responding' (server/backend problem) from 'slow to finish downloading' (content size/CDN problem) from 'slow only from here' (network path problem) - these three have completely different fixes, and the phase-timing breakdown in Step 1 is what tells them apart.
Common Causes
| Symptom | Likely Cause | Fix |
|---|---|---|
| High ttfb, everything else fast | Backend/database query slowness, or the server is under heavy load | Investigate server-side performance/logs - this is not a network issue. |
| Fast ttfb but slow total time | Large uncompressed assets or too many render-blocking resources | Optimize images, enable compression, defer non-critical scripts. |
| Slow only from one specific location/network | Local network path issue (ISP routing, VPN, proxy) | See the Ping & Packet Loss guide to localize where on the path the delay is introduced. |
Automated by
Diagnostic Suite - Site Latency Diagnostic (Option 2)
Automatically times every phase of the request and produces a PDF report showing exactly where time is spent.