Master TTFB optimization by implementing resource hints like preconnect and dns-prefetch. Learn to warm up connections to slash latency before it happens.
Last month, I spent three days chasing a frustrating latency issue on a client’s e-commerce dashboard. Despite having a highly optimized CDN, our TTFB remained stubbornly high on mobile devices—often hovering around 600ms on 4G networks. It turned out we were losing massive amounts of time on the initial TLS handshake for a critical third-party API.
When you're dealing with TTFB optimization, you have to stop thinking about your server’s response time alone. You have to think about the "cost of connection."
Every time your browser needs to fetch a resource from a new origin, it performs a DNS lookup, a TCP handshake, and a TLS negotiation. On a high-latency mobile connection, this dance can easily add 300ms to 500ms before a single byte of application data is even requested. If that origin hosts your fonts, your analytics, or your primary data API, your page is effectively stalled.
We initially tried to move the API to our main domain to avoid the cross-origin handshake. It sounded like a clean fix, but it broke our caching layer and required a massive refactor of our proxy configuration. That’s when we pivoted to using standard browser resource hints to solve the problem at the connection layer instead.
Resource hints are declarative instructions you give the browser to perform specific network tasks before they are strictly needed. The primary tools in your arsenal are dns-prefetch, preconnect, and prefetch.
The dns-prefetch hint is the lightest touch. It tells the browser to resolve the IP address of a domain in the background.
HTMLstyle="color:#808080"><style="color:#4EC9B0">link rel="dns-prefetch" href="https://api.example.com">
Use this for domains that you might need later but aren't critical for the immediate LCP. It’s low risk and low overhead.
This is your heavy hitter. preconnect performs the DNS lookup, the TCP handshake, and the TLS negotiation. It’s more aggressive and consumes more battery and radio resources, so don't go overboard.
HTMLstyle="color:#808080"><style="color:#4EC9B0">link rel="preconnect" href="https://api.example.com" crossorigin>
The crossorigin attribute is mandatory if you’re fetching assets like fonts, even if they aren't technically CORS-restricted. If you omit it, the browser will perform the connection, but it will essentially "throw it away" when it realizes it needs the credentials to actually fetch the file.
Think of connection warming as a "warm-up lap" for your network stack. By the time your application code actually triggers the fetch() call, the browser has already established a secure pipe to the server. Your request skips the handshake latency entirely.
When I applied preconnect to our primary API and our font provider, our TTFB dropped from that consistent 600ms to roughly 350ms. It was a simple change that yielded massive gains. If you want to see how this fits into a broader strategy, I previously covered Browser Resource Prioritization: Controlling Network Scheduling to help you manage how these requests compete for bandwidth.
It’s tempting to add a preconnect tag for every single third-party script you use. Don't. If you open too many connections, you’ll actually create network congestion.
preconnect for scripts that aren't actually critical, you're stealing bandwidth from your main document. You might want to look into Resource Prioritization: Using Fetch Priority for LCP Optimization to ensure you aren't fighting yourself.You can’t improve what you don't track. I use the Server-Timing header to keep an eye on backend processing versus network latency. It’s a lifesaver when you need to distinguish between a slow database query and a slow network handshake. For those interested in the backend side of this, I’ve written about the Server-Timing API for INP Optimization: Debugging Backend Latency which helps correlate these metrics.
If I were starting this optimization pass over again, I’d be more surgical with my DNS-prefetching. We initially added preconnects to five different third-party scripts, and after running a Lighthouse audit, we realized two of them were barely used. We were wasting browser resources on connections that never materialized into meaningful traffic.
TTFB optimization isn't about one magic header; it's about being intentional with your browser's network lifecycle. Start small, measure the handshake times, and only add hints where they provide a measurable reduction in latency.
Master browser resource prioritization using Fetch Metadata and Document Policy. Stop network congestion and improve your LCP by controlling request scheduling.
Read moreMaster main thread optimization by implementing backpressure-aware UI patterns. Learn to use adaptive throttling and request prioritization to keep UIs smooth.