Server Response Time (TTFB), DNS Propagation and SSL Handshakes: The Infrastructure QA Guide

Time to First Byte is the floor under every other performance metric. Largest Contentful Paint cannot beat it, the browser cannot start parsing before it, and no amount of front-end optimisation recovers a second lost waiting for the server to answer. Under 200ms is excellent; above 800ms is where it starts distorting everything downstream.

The problem is that "TTFB is 1.4 seconds" is not a diagnosis. It is the sum of four independent phases, and the fix for each is completely different. Measure them separately before changing anything.

Break the number apart

curl -o /dev/null -s -w "\
DNS lookup:    %{time_namelookup}s\n\
TCP connect:   %{time_connect}s\n\
TLS handshake: %{time_appconnect}s\n\
Server think:  %{time_starttransfer}s\n\
Total:         %{time_total}s\n" \
  https://example.com/

The values are cumulative, so subtract to get each phase. A realistic healthy result from India to a Mumbai-region origin:

DNS: the phase nobody looks at

DNS resolution happens before any connection and is invisible in most performance tooling. A slow or poorly distributed DNS provider adds 100–300ms to every uncached first visit.

# How long does resolution take, and how many hops?
dig +noall +stats example.com | grep "Query time"
dig +short CNAME www.example.com

# Is the TTL sensible?
dig +noall +answer example.com

Three things to check:

• Provider quality. DNS bundled with cheap shared hosting is frequently slow and has few points of presence. A managed provider with anycast resolves in tens of milliseconds globally.
• CNAME chains. www → CDN → load balancer → origin is three lookups. Flatten where your provider supports it.
• TTL. 3600s is a reasonable default. Lower it to 300s a day *before* a planned migration, then raise it again after.

Also confirm both apex and www resolve. A site that works at www.example.com and fails at example.com will lose the share of visitors who type the short version — and, if you run ads, can produce a "Destination not working" disapproval on the version you did not test.

TLS: handshake cost is configuration, not physics

A slow handshake is almost always one of three fixable things.

• Incomplete certificate chain. If the intermediate is missing, the client must fetch it separately. Browsers often have it cached so it looks fine to you and is slow for a first-time visitor — and fails outright for automated crawlers.
• No session resumption. Without it, every connection pays the full handshake. Enable TLS 1.3 and session tickets.
• Old protocol versions. TLS 1.0 and 1.1 are deprecated, slower, and will get you flagged by security scanners. Serve 1.2 and 1.3 only.

# Does the chain verify on its own, without a cached intermediate?
openssl s_client -connect example.com:443 -servername example.com \
  -showcerts < /dev/null 2>/dev/null | grep -E "Verify return code|Protocol"

# Expect: Protocol : TLSv1.3   and   Verify return code: 0 (ok)

Certificate expiry deserves a standing alert rather than a calendar note. An expired certificate takes the entire site down, blocks ad traffic within hours, and is completely preventable. If you use Let's Encrypt, verify the renewal cron actually runs — a silently failing renewal is a 90-day fuse.

Server think time: where the seconds usually are

If time_starttransfer minus time_appconnect is several hundred milliseconds, the application is the bottleneck. In rough order of how often it is the cause:

1. No page cache. A CMS rebuilding every page from the database on every request. Full-page caching at the edge usually takes TTFB from 800ms to under 100ms and is the highest-leverage change available.
2. N+1 database queries. One query per item in a loop. Log slow queries and look for repeated identical statements.
3. Cold starts. Serverless functions and containers that scale to zero pay initialisation on the first request. Keep a minimum instance warm for pages that receive paid traffic.
4. Synchronous third-party calls. Fetching a currency rate or an inventory count from another API during page render couples your TTFB to theirs. Cache it, or move it client-side.
5. Shared hosting contention. Sometimes the honest answer is that the plan is the problem.

Redirect hops: TTFB multiplied

Every redirect repeats DNS, TCP and TLS. A chain of http://example.com → https://example.com → https://www.example.com pays that cost three times before the real page even starts.

curl -sIL http://example.com \
  -w "hops: %{num_redirects}  total: %{time_total}s\n" \
  -o /dev/null

Target one hop. Enforce the canonical host once, at the edge, and make sure the application is not also redirecting. Duplicated rules across .htaccess, the CDN and the framework are the standard cause of a three-hop chain nobody designed.

Zero-downtime domain cutover

The sequence that avoids the usual migration incidents:

1. T-48h — lower the TTL on the records you will change to 300s.
2. T-24h — issue and install the certificate for the new host. Verify the chain with openssl before any traffic moves.
3. T-24h — bring the new origin fully live on a temporary hostname and test every template against it.
4. T-1h — confirm the old origin will keep serving for at least 48 hours after the switch. Do not decommission it.
5. T-0 — change the records. Watch both origins' logs; traffic will arrive at both for a while, which is normal.
6. T+1h — verify resolution from several regions, and re-run the curl timing breakdown.
7. T+24h — confirm redirects, canonicals and the sitemap all reference the new host, then submit it in Search Console.
8. T+72h — restore the original TTL.

Step 7 is where migrations lose traffic rather than availability. The site is up, and every canonical still points at the old domain. The technical SEO checklist covers the canonical and redirect verification in detail.

Monitor rather than measure once

Infrastructure degrades gradually. A database grows, a cache configuration is lost in a deploy, a certificate approaches expiry. None of it announces itself, and by the time someone says the site feels slow the change happened weeks earlier.

Record the four-phase breakdown monthly against your key pages and keep the numbers. A trend line makes a regression obvious and, when you do need to ask for infrastructure budget, it is the only evidence that reliably works.