Start with the timeline, not the symptom
Break every request into parts you can measure separately: DNS lookup, TCP connection, TLS handshake, time to first byte, and content transfer. Whichever component is slow tells you which layer owns the problem.
| Slow component | Usually means |
|---|---|
| DNS lookup | Resolver latency, or answers pointing at distant addresses |
| TCP connection | Round-trip time and path quality |
| TLS handshake | Extra round trips, or handshakes failing under loss |
| Time to first byte | Origin processing, origin-to-edge latency, or a cache miss that should have been a hit |
| Content transfer | Bandwidth limits, or a connection stalling on retransmission |
If the first three dominate while your application time looks fine, the problem is the network, and no amount of application tuning will fix it.
Measure from where the users are
- Origin-side monitoring sits at the origin and cannot see the cross-border hop, which is exactly where the problem is.
- Regional probes from several mainland cities give you a baseline, and separate a path-wide problem from a city-specific one.
- Real user monitoring captures what real sessions experienced, including failures that never reached your origin.
- Sample during the evening peak. A test at 10:00 can look perfect on a path that collapses at 21:00.
Read loss and jitter correctly
- Latency alone is often acceptable. Loss is what breaks connections, because TCP stalls until the missing packet is retransmitted.
- Jitter hurts sessions more than page loads. A call degrades on jitter; a web request degrades on loss and on losing its connection entirely.
- Intermittent loss produces the worst experience and the least useful reports: sometimes it just spins.
- Handshake failures are a loss symptom. When a reset lands mid-handshake the user gets an error page, not a slow one.
Things that are always worth checking
- Is the connection being reused? A fresh TLS handshake per request multiplies the cost of every round trip.
- What is the cache-hit ratio, and did it move? A drop in hit ratio looks exactly like a network problem.
- Is the same request failing repeatedly? Client retries can look like a traffic spike.
- Is the origin healthy from the edge's point of view? Origin-to-edge distance now matters more than user-to-origin distance.
- Did anything change? A certificate renewal, a DNS edit, or an origin move are all more common causes than gradual network decay.
What each finding implies
| Finding | Typical fix |
|---|---|
| Round trips dominate | Terminate closer to the user, and cut round trips with connection reuse and modern protocols |
| Most requests are cache misses | Fix cache keys and TTLs before buying anything |
| Loss appears in the evening peak | Serve from closer to the user so most requests stop crossing the border |
| Handshakes fail | Enable session resumption, and terminate TLS near the user |
| Time to first byte is high on cache misses | Investigate origin-to-edge latency rather than user-to-origin |
A short checklist
- Split the timeline before theorising.
- Measure from mainland cities, in the evening.
- Track errors and latency separately.
- Check the cache-hit ratio before blaming the network.
- Fix the path first, then tune the application.