DEV Community

Cover image for Why Your Website Can Be "Up" And Still Broken: A Deep Dive Into Latency Phases
Adarsh Shukla
Adarsh Shukla

Posted on

Why Your Website Can Be "Up" And Still Broken: A Deep Dive Into Latency Phases

Why Your Website Can Be "Up" And Still Broken

Most uptime monitors tell you one thing: is the server responding? But that binary answer misses the full picture of what your users actually experience.

The 4 Phases of Every HTTP Request

Every time a browser loads your website, it goes through 4 distinct phases:

1. DNS Lookup (dns_ms)

Your browser needs to convert yoursite.com into an IP address. This involves querying DNS servers. A healthy DNS lookup takes < 50ms. If you're seeing > 200ms, your DNS provider may be slow or your TTL is set too low.

What breaks it: DNS propagation issues, expired records, DDoS on DNS provider (happened to Cloudflare, Dyn).

2. TCP Connect (tcp_ms)

Once the IP is known, the browser opens a TCP connection to your server. This is basically the round-trip time between your user and your server. Expect < 100ms for same-continent users.

What breaks it: Server is too far from users, DDoS, port blocked by firewall.

3. TLS Handshake (tls_ms)

For HTTPS sites, client and server negotiate encryption keys. This adds 20-150ms typically. If you're seeing > 500ms, your TLS configuration needs tuning (consider enabling TLS session resumption).

What breaks it: Expired certificates (site shows scary red warning), misconfigured cipher suites, revoked certificates.

4. Time to First Byte — TTFB (ttfb_ms)

This is the time from "request sent" to "first byte of response received." It's the most important metric for perceived performance. Target < 200ms. Above 800ms, users start bouncing.

What breaks it: Slow database queries, no caching, memory leaks, cold-start serverless functions.

Why This Matters More Than Simple Uptime

A server can return HTTP 200 while:

  • Taking 4 seconds to respond (TTFB issue)
  • Having a broken TLS configuration
  • Serving from a CDN that's cached a broken page
  • Running out of memory (but still technically responding)

Setting Up Phase-Level Monitoring

Tools like WhistleBlower break down each phase independently, so when your monitoring fires an alert, you already know which part of the request chain failed — not just "something is wrong."

DNS: 12ms  ✅
TCP: 45ms  ✅  
TLS: 89ms  ✅
TTFB: 2400ms ❌ ← your database is choking
Enter fullscreen mode Exit fullscreen mode

This cuts mean-time-to-resolution dramatically. Instead of "the site is slow, dig into everything," you know exactly where to look.

Quick Fixes by Phase

Phase Slow? Try This
DNS > 100ms Switch to Cloudflare DNS, increase TTL
TCP > 200ms Use a CDN, move server closer to users
TLS > 300ms Enable TLS session resumption, use HTTP/2
TTFB > 500ms Add Redis cache, optimize slow DB queries

WhistleBlower monitors all 4 phases on every check and tracks trends over time. Try it free.

Top comments (0)