Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules

A PageSpeed Insights run flags a high Time to First Byte. The ticket lands on the theme backlog. Hosting gets upgraded. A CDN is added. The next lab run still shows a slow first byte on the same priority URL. In our experience the miss is often earlier in the path: DNS, TLS, HTTP version, connection reuse, edge routing, or cache policy.

TTFB is not a Core Web Vital, but it feeds Largest Contentful Paint. A page that spends 800 ms waiting for first byte has already used a large share of a mobile LCP budget before the hero can paint. WebPageTest and similar waterfalls split that wait into DNS, TCP connect, TLS, and waiting. That split is what makes network work actionable.

Theme and plugin work still matter, but they sit after the network and delivery stack has done its job. If first byte is already late, paint and interactivity inherit that delay. Walk the request in order before another theme rewrite.

Checklist when you try to reduce TTFB:

• DNS: flatten long CNAME chains, raise TTL once cutovers are rare, test from more than one region

• TLS: enable TLS 1.3, staple OCSP, serve a complete chain, consolidate hosts for reuse

• HTTP and connections: confirm HTTP/2 or HTTP/3 at the edge; avoid spraying cold handshakes across origins

• CDN routing: separate CDN configured from HTML cacheable; inspect Age and cache-status headers

• Cache rules: short TTL or SWR for anonymous HTML; long TTL for hashed assets; purge by URL or tag, not blanket storms

If TLS is 40 ms and Waiting is 900 ms, move to CDN and cache rules instead of chasing another certificate setting. Prove each change with scheduled lab runs on the same priority URL.

Read more: Network Performance for Web Teams: DNS, TLS, HTTP, CDN, and Cache Rules