Make Uxify one of your go-to sources on Google
Add Uxify on Google
What is a TCP Handshake?
A TCP handshake is the quick back-and-forth a browser and a server go through to open a connection before they send any real data. It’s also called the three-way handshake, because it takes three messages. The browser sends a SYN (“can we talk?”), the server answers with a SYN-ACK (“yes, go ahead”) and the browser confirms with an ACK. Only then can it ask for your HTML.
It comes right after the DNS lookup and right before the TLS handshake that HTTPS adds on top. All of it counts toward Time to First Byte, the wait before your server’s response starts arriving.
The messages themselves are tiny. Distance is what costs you. Each one has to physically travel between the shopper’s device and your server, so someone in Sydney visiting a store hosted in Virginia waits on a full trip across the Pacific and back before the browser can even request the page. Say that round trip takes 200 ms: that’s 200 ms with nothing on screen, and the encryption step usually stacks at least one more trip on top.
What this means for revenue
Every new connection pays this toll.
That includes the first visit from a Google Shopping ad, and every third-party domain your page pulls from too: the Trustpilot widget, the chat tool, the font service, the Klaviyo signup popup. Each one opens its own connection with its own handshake. On office Wi-Fi you’d never notice. On an iPhone with patchy 4G, round trips get slower and less predictable, and the handshakes pile up into a blank screen that lasts just long enough for a first-time visitor to hit back. Those are the visitors you paid the most to get.
Most fixes are cheap. A CDN puts servers closer to shoppers, so each trip is shorter. Reusing open connections means the browser shakes hands once and then sends request after request down the same line, and preconnect hints let it open connections to the third-party domains you care about before they’re needed.
How Uxify helps
Reality measures every real pageview, and its TTFB breakdown splits Time to First Byte into its parts, connection setup included, so you can tell whether the handshake or your server is the slow bit. Filter by country or network speed and the distance problem usually jumps out. Ask Uxi can analyze those values and suggest what to change. And for every click after the first page, Navigation AI loads the next page in the background before the visitor taps, so the connection work is already done when they get there.
TCP Handshake FAQs
How long does a TCP handshake take?
About one round trip between the visitor and your server, which means it depends almost entirely on distance and network quality. A shopper near a CDN edge server will barely feel it. There’s no universal “good” number, so your own connection times, split by country and device, are the real benchmark.
What’s the difference between a TCP handshake and a TLS handshake?
TCP opens the connection. TLS runs straight after it on HTTPS sites and sets up the encryption behind the padlock in the address bar. Both cost round trips before the first byte arrives, which is why a slow connection phase in your data is often a mix of the two.
Does HTTP/3 get rid of the TCP handshake?
Yes. HTTP/3 runs on QUIC, which skips TCP entirely and handles connection setup and encryption in one combined exchange, and returning visitors can sometimes start sending data with no handshake wait at all. If your CDN supports it, switching it on is often a setting rather than a project. Our guide on how to optimize website performance covers the other server-side wins.