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.
