Diagnosing Latency: A Systematic Method for "Why is Google Slow?"

Identifying the Problem

In network engineering, user complaints are often subjective, nuanced, and hazy. A report of "Google is slow" presents a classic diagnostic challenge. The perceived latency could be rooted in multiple layers of the network stack: local DNS caching, ISP routing, backbone congestion, or server-side application delays.

This article documents my first-ever diagnostic procedure performed in response to such a complaint. The goal is to provide a blueprint for systematically isolating the source of network latency, using only standard command-line tools available on most endpoints. We will proceed from the network layer up to the application layer, eliminating potential causes one by one.

The Diagnostic Toolkit

The investigation employed four core utilities:

1. dig (Domain Information Groper): Used for interrogating DNS nameservers to assess resolution latency at different levels of the DNS hierarchy.

2. ping: To measure baseline Round-Trip Time (RTT) and assess packet loss to a specific IP address. The -l flag on Windows was used to test with larger payloads.

3. tracert (Windows) or traceroute (UNIX): Used to map the network path from the source to the destination, identifying each hop and measuring latency to each intermediate router.

4. curl: Used with specific timing flags to break down the HTTP/S request process into distinct stages (DNS, TCP, TLS) and measure the latency of each.

Phase 1: DNS Resolution Analysis

The first step in any web request is Domain Name System (DNS) resolution. Delays here would manifest as a long wait before any connection is attempted.

Step 1.1: Testing Cached Resolution Latency

The first test checks the latency of a DNS query that is likely cached by the local OS or stub resolver.

Command: dig google.com

Methodology: The query time was recorded over ten (10) consecutive attempts to establish an average.

Result: Query times (in ms): 46, 15, 0, 31, 15, 15, 40, 15, 0, 0.

Finding: The average latency for a cached query was 17.7ms. This is considered excellent performance and effectively rules out the local DNS cache as the source of significant delay.

Step 1.2: Testing “Uncached” Resolution with a Public Resolver

This test bypasses the local cache by directly querying a public recursive resolver, Google's 8.8.8.8.

Command: dig google.com @8.8.8.8

Result: Query times (in ms): 78, 62, 70, 46, 43, 62, 60, 46, 67, 46.

Finding: The average latency was 58.0ms. This is a reasonable latency for a recursive query and is unlikely to be the sole cause of a user-perceived "slow" experience.

Step 1.3: Testing Resolution from an Authoritative Source

To understand the full DNS chain, I queried one of the domain's authoritative nameservers directly. This is not a normal user operation but is informative.

Command: dig google.com @ns1.google.com

Result: Query times (in ms): 159, 159, 190, 155, 154, 155, 176, 188, 165, 174.

Finding: The average latency was 167.4ms. This is slower, as expected, because authoritative nameservers are not optimised for direct end-user queries. The more important finding was the discrepancy between this and the @8.8.8.8 query, suggesting the public resolver had a warm cache.

Step 1.4: Measuring Resolver Internal Processing Time

To see the true "uncached" performance of the resolvers themselves, I used the +stats flag to see the resolution time reported by the resolver.

Command (Google DNS): dig @8.8.8.8 +stats

Result: Resolver query times (in ms): 145, 132, 137, 130, 158, 172, 167, 144, 147, 139.

Finding: Average internal resolution time for @8.8.8.8 was 147.1ms.

Command (Cloudflare DNS): dig @1.1.1.1 +stats

Result: Resolver query times (in ms): 175, 256, 217, 227, 168, 291, 171, 239, 201, 174.

Finding: Average internal resolution time for @1.1.1.1 was 221.9ms.

Phase 1 Conclusion

DNS resolution shows expected latencies. The cached time is fast (<20ms), and even full recursive resolution times (~150-220ms) are insufficient to explain a severely "slow" feeling on their own. The investigation must move higher up the stack.

Phase 2: Network Latency and Path Analysis

With the IP address resolved (216.58.223.206), I measured the raw network latency to the host.

Step 2.1: ICMP Echo (Ping) to Target IP

Command: ping -n 10 216.58.223.206

Result: Average RTT over 10 pings: ~53ms.

Command (with payload): ping -n 10 -l 1000 216.58.223.206

Result: Average RTT with 1000-byte payload: ~57ms.

Finding: The base network latency is moderate and stable. The negligible increase with a larger payload suggests the path is not suffering from major congestion or fragmentation issues. This is not low enough to explain a severe slowdown.

Step 2.2: Traceroute to Target IP

Command: tracert 216.58.223.206

Result: The path was consistent across multiple runs. Key hops from a representative run:

• Hop 1: 172.20.10.1 (Local Gateway) - <1ms

• Hop 2: 10.18.0.252 (ISP First Hop) - Variance: 53ms to 258ms

• Hop 3: 10.169.131.249 (ISP Core) - Variance: 33ms to 154ms

• Hop 11: 108.170.238.151 (Google Network) - Variance: 45ms to 230ms

• Hops 12-13: 172.253.76.173 -> 216.58.223.206 - Stable at ~42-66ms

Finding: The traceroute revealed significant jitter (latency variation) at early ISP hops (2 and 3) and within Google's network (Hop 11). This indicates intermittent congestion or traffic shaping, which would contribute to an inconsistent user experience. However, the final latency to the destination remained in the 50-60ms range.

Phase 3: Application Layer Timing

The final and most crucial test measures the entire process of establishing a secure HTTP connection, which is what a browser does.

Step 3.1: HTTP/S Timing Breakdown

Command: 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://google.com

Result:

DNS Lookup: 0.088364 s (88.4 ms)

TCP Connect: 0.293722 s (293.7 ms)

TLS Handshake: 0.516852 s (516.9 ms)

Time to First Byte (TTFB): 0.782226 s (782.2 ms)

Total Time: 0.783087 s (783.1 ms)

Finding: This output is definitive. The DNS lookup was fast (88.4ms). The overwhelming majority of the delay (~800ms) was consumed by the TCP connection (TCP three-way handshake) and the TLS handshake before any application data could be requested or received.

Synthesis and Conclusion

The evidence leads to a clear and specific diagnosis:

DNS Resolution: Ruled out as the primary cause. Performance was within expected parameters.

Raw Network Latency: Ruled out as the sole cause. While moderate (~53ms), it does not account for the multi-second perceived delay.

Network Path Jitter: Identified as a contributing factor. Significant latency variation at early ISP hops (10.18.0.252, 10.169.131.249) explains inconsistent performance but is not the root cause.

TCP/TLS Handshake Latency: Identified as the root cause. The combined ~810ms delay in establishing a connection indicates the client is being routed to a geographically distant or congested Google edge server. The TLS handshake, involving multiple round trips, is highly sensitive to high latency.

Recommendations

For the End User: The issue is likely related to ISP routing policies. Using a VPN could force a connection through a different path to a more optimal Google Point of Presence (PoP), potentially reducing handshake latency.

For the ISP: The jitter at hops 2 and 3 should be investigated, as it degrades network quality. Furthermore, BGP peering relationships with Google's network should be reviewed to ensure local traffic is routed to the nearest edge location.

This case study demonstrates that subjective user experience can be deconstructed into objective data. A methodical, layer-by-layer approach is indispensable for transforming a vague complaint into a precise and actionable network diagnosis.