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. 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.

What follows walks that request in order for teams who need to reduce TTFB before another theme rewrite. We stay on the network and delivery layers. For WordPress cases where code on the stack beats a bigger hosting plan, see Why Your WordPress Site Is Slow (It Is Not Always Hosting). For LCP levers once first byte is under control, see A Quick Way to Fix LCP: Four Changes That Cut Time to Paint.

What TTFB includes when you measure first byte in lab tools

Time to First Byte (TTFB) measures how long the browser waits from the start of the navigation request until the first byte of the response arrives. In PageSpeed Insights and Lighthouse, it appears as a diagnostic timing. In WebPageTest and similar waterfall tools, you can split the same wait into DNS, TCP connect, TLS, and waiting (server or edge processing). That split is what makes network work actionable for delivery teams.

TTFB is not a Core Web Vital, but it feeds Largest Contentful Paint and overall load feel. A page that spends 800 ms waiting for first byte has already used a large share of a mobile LCP budget before the hero image or heading can paint. Field data from Chrome UX Report may show Time to First Byte as a supporting metric. Lab tools remain the fastest way to prove a DNS or CDN change after a release, because you control the URL, location, and cache state of the run.

When you read TTFB in a report, ask which hop dominated. Resolver delay looks different from a cold TLS handshake. A cache miss at the CDN looks different from an origin that regenerates HTML on every request. The sections below map each hop to what you change and what you re-test on the same priority URL.

How DNS lookup performance affects first byte

Before any TLS or HTTP work starts, the client must resolve the hostname. DNS lookup performance is the time from query to answer. On a cold visit with an empty cache, that cost sits at the front of TTFB. On a warm visit with a cached answer inside TTL, the lookup may be near zero and the problem moves downstream to connect, TLS, or waiting.

Common DNS causes of slow first byte:

Cause	What you see	Practical fix
Slow or distant resolver path	High DNS ms in WebPageTest before connect	Prefer resolvers and authoritative DNS with low latency for your audience regions
Long CNAME chains	Extra lookups before the final A/AAAA	Flatten CNAMEs where the CDN or DNS vendor allows it
Very short TTL with frequent expiry	Repeated lookups on every cold session	Raise TTL for stable records once cutovers are rare
Geo DNS mis-routing	Fast DNS, wrong PoP or origin later	Align geo policies with real user regions, not office Wi-Fi

Do not treat “add a CDN” as a DNS fix by itself. The CDN hostname still needs clean resolution. After any nameserver, record, or CNAME change, run lab tests from more than one region on the same priority URL. A London-only pass can hide resolver pain for users in another continent. Document the DNS owner per client (registrar, Cloudflare, Route 53, hosting DNS), because ownership confusion often delays the one change that would cut cold-start TTFB more than another plugin audit.

How TLS handshake timing shows up in web TTFB

After TCP connect, the TLS handshake establishes a secure session. TLS handshake cost on the web includes certificate validation, key exchange, and optional stapled OCSP data. TLS 1.3 shortens the handshake compared with older versions. Session resumption and TLS tickets reduce work on repeat connections to the same host.

When TLS shows up as a TTFB problem:

• The certificate chain is incomplete or forces extra round trips to fetch intermediates.
• The edge or origin still offers TLS 1.2 only, or a weak cipher suite set that clients negotiate poorly.
• OCSP stapling is missing and clients block while checking revocation.
• Every asset subdomain forces a fresh handshake because connection reuse and HTTP/2 multiplexing never kick in.

Fixes are usually platform configuration, not theme code: enable TLS 1.3 at the edge, staple OCSP, serve a complete chain, and consolidate hosts so the browser can reuse connections. After certificate renewals or CDN SSL mode changes (flexible versus full), re-run lab tests. A misconfigured SSL mode can add redirects that look like “slow TTFB” in a single waterfall row.

Keep handshake tuning separate from application latency. A perfect TLS setup still waits on an origin that takes 1.5 seconds to build HTML. Use the waterfall: if TLS is 40 ms and Waiting is 900 ms, move to CDN and cache rules next instead of chasing another certificate setting.

How HTTP/2, HTTP/3, and connection setup affect TTFB

HTTP version choice changes how requests share connections. HTTP/2 multiplexes many streams over one TLS connection and removes most head-of-line blocking at the HTTP layer. HTTP/3 runs over QUIC and can reduce connection setup cost on lossy mobile networks, with different trade-offs for middleboxes and debugging. Monitoring nuances for HTTP/2 and HTTP/3 belong in a later industry piece. The operational question here is simpler: is the edge speaking a modern protocol to real browsers, and are you wasting connections on cold handshakes?

Connection setup details that still matter for TTFB:

• Keep-alive and connection reuse: cold connects pay DNS, TCP, and TLS again; warm navigations on the same origin should reuse.
• Preconnect: use it for third-party or CDN hosts that must be ready before LCP work; do not spray preconnect across every tag manager domain.
• Connection limits: too many distinct origins fragment work and multiply handshakes.
• Origin versus edge: browsers talk to the CDN hostname; the CDN opens or reuses a connection to origin on miss. Origin shield and keep-alive between PoP and origin cut repeated cold connects on miss paths.

If lab tests from a single region look fine but mobile field users complain, check whether HTTP/3 is enabled at the edge and whether your synthetic tool’s protocol path matches what Chrome does for that audience. Protocol upgrades rarely fix a 2-second origin render. They do remove avoidable setup cost when you are chasing the last few hundred milliseconds of TTFB on an otherwise healthy document response.

How CDN routing and PoP selection change cache hit TTFB

CDN routing decides which point of presence answers the request and whether the response is served from cache or fetched from origin. Cache hit versus miss is often the largest swing in TTFB for cacheable HTML and static assets. A hit can return in tens of milliseconds from a nearby PoP. A miss pays PoP-to-origin latency plus origin compute, which is why “we turned on a CDN” does not guarantee a lower first byte on HTML documents.

Checklist for CDN-related TTFB work:

1. Confirm the URL under test is the public hostname users hit, not a bypass origin URL used only in staging.
2. Inspect Age, CF-Cache-Status, X-Cache, or vendor-equivalent headers on the HTML response and on the LCP asset.
3. Separate “CDN configured” from “HTML cacheable.” Many stacks cache CSS and images while every HTML document is private, no-store.
4. Enable origin shield or regional shielding when miss traffic repeatedly cold-starts the same origin from many PoPs.
5. Prefer stale-while-revalidate (or vendor equivalent) for pages that can tolerate brief staleness so users are not blocked on origin regeneration.

PoP selection mistakes show up as geography-specific TTFB spikes. A campaign aimed at Australia served primarily from a European PoP will look healthy in a default US or EU lab profile and poor for the real audience. Align synthetic locations with the client’s traffic share, then set performance budget thresholds on those same URLs so regressions after DNS or CDN edits are visible in the next scheduled run.

How CDN cache rules differ from browser cache

CDN cache rules decide what the edge may store and for how long. Browser cache rules decide what a returning visitor may reuse without another network hop. Mixing the two is a common source of tickets that say “we purged but TTFB did not move,” because the team purged the wrong layer or expected browser cache to fix cold document requests.

Layer	Typical policy intent	TTFB effect
Browser cache (static assets)	Long max-age / immutable hashed filenames	Helps repeat views; little effect on cold TTFB for HTML
CDN cache (static assets)	Long TTL at edge, purge on deploy of that asset set	Cuts miss cost for CSS, JS, images, fonts
CDN cache (HTML)	Short TTL, SWR, or selective caching for anonymous pages	Often the main lever to reduce TTFB on document requests
Origin	Correct Cache-Control / CDN-Cache-Control so the edge is allowed to store	Without this, CDN rules never engage

Purge discipline matters as much as TTL length. Blanket purges on every content edit can collapse hit ratio and return every visitor to origin cost. Prefer purge-by-URL or purge-by-tag for the templates you changed. After a purge storm, expect temporary TTFB regressions until the edge repopulates. Tell clients that pattern is expected, then prove recovery with scheduled lab runs rather than a single screenshot.

A deeper pass on Cache-Control header design belongs in a dedicated how-to later on the calendar. For day-to-day delivery, decide per content type whether the browser, the CDN, or only the origin may cache. Write that policy down. Verify headers on the live URL after each CDN or platform change.

How to diagnose network TTFB in PageSpeed Insights and WebPageTest

Use one cold lab run to see the full path, then one repeat view if your tool supports it. Cold runs expose DNS and TLS. Repeat views show whether connection reuse and cache headers behave as you expect.

PageSpeed Insights and Lighthouse

Read the TTFB-related diagnostic and the document request in the network breakdown when available. Treat a high TTFB with a green LCP as unstable: the next slower network or colder cache will expose the wait. Compare mobile and desktop profiles; connection and CPU throttling change how much TTFB dominates the timeline.

WebPageTest waterfalls

Expand the first document request: DNS, connect, TLS, Waiting. Note protocol (h2 / h3), CDN cache headers, and redirect count before the final document. Run the same URL from two locations that match the client’s audience so geography-specific PoP and DNS issues are not invisible.

Decision order we use in delivery

1. Redirects and wrong hostname (fix before tuning TLS).
2. DNS and TLS setup cost on cold load.
3. CDN miss versus hit on HTML and on the LCP asset.
4. Origin compute and application time (hand off to code or hosting diagnosis as in the WordPress guide linked above).
5. Protocol and connection reuse for the last stretch of budget.

Manual one-off checks catch the first regression. They do not prove the CDN change still holds next week. Pair diagnosis with scheduled PageSpeed monitoring on priority URLs. Keep PageSpeed Insights versus automated monitoring in mind when a stakeholder wants a single green screenshot as proof that the edge is healthy.

What to re-test after DNS, TLS, or CDN changes

Ship network changes with the same discipline you use for theme releases. After nameserver cuts, SSL mode edits, HTTP/3 toggles, cache rule updates, or purge policy changes, treat the edge the way you treat a theme deploy: prove the URL still meets budget before you close the ticket.

1. Lab-test the homepage and at least one high-intent template (product, pricing, or primary landing URL).
2. Capture cache status headers and TTFB from a location that matches traffic.
3. Compare against the budget you already set for that URL.
4. Watch the next few scheduled runs for hit-ratio recovery after purges.
5. Only then reopen theme or plugin tickets that assumed “hosting was fine.”

Apogee Watcher fits as the continuous layer on top of this checklist: multi-site schedules, device splits, and alerts when TTFB or LCP leave budget after an edge change. It layers onto your DNS and CDN vendors; it does not replace them. Network fixes stay verified without someone remembering to open PageSpeed Insights after every Cloudflare or Fastly edit.

FAQ

Does reducing TTFB always improve Core Web Vitals?Often for LCP, when first byte was a large share of the delay and the LCP element was waiting on the document or a late resource discovery. Not always for INP or CLS, which depend on main-thread work and layout stability. Treat TTFB as a supporting budget with its own threshold, then confirm LCP on the same URLs after the network change lands.

Should we cache HTML at the CDN for logged-in or personalised pages?Usually no for fully personalised HTML. Prefer caching anonymous shells or use edge strategies your platform supports without leaking private content. Wrong HTML caching creates security and correctness incidents that dwarf a TTFB win, so write the exception list into the cache policy before you enable document caching at the edge.

Is a CDN enough to fix DNS lookup performance?No. The CDN improves delivery after resolution. Flatten CNAME chains, set sensible TTLs, and confirm geo DNS still points users at a sensible PoP. Re-test cold loads from more than one region after DNS ownership or nameserver changes.

When is origin compute the real TTFB problem?When the waterfall Waiting phase dominates after DNS, connect, and TLS are small, and cache headers show misses or bypass. Then audit application time, database work, and cron load rather than another TLS tweak. That hand-off is where the WordPress hosting-versus-code diagnosis usually starts.

How soon should we re-run lab tests after a DNS cutover?As soon as TTL and resolver caches allow the new answers to appear, then again from a second region. Do not wait for a monthly report cycle to learn the cutover raised TTFB for half the audience. Put the same URLs on a short schedule for the first week after the cutover so hit-ratio and geo routing surprises show up while ownership is still clear.

Put priority URLs on a schedule after network changes

Pick one priority URL with a high lab TTFB. Export or screenshot the waterfall split for DNS, TLS, Waiting, and cache status. Fix the largest hop first, re-test from a relevant location, then put that URL on a schedule so the next DNS or CDN change cannot silently undo the gain. If you manage many client hostnames, use Watcher’s portfolio schedules and budgets so edge regressions surface the same way application regressions do.