TTFB measures how long you wait before anything comes back. Through a proxy it includes everything up to the first response byte: reaching the proxy, the CONNECT exchange, the TLS handshake with the site through the tunnel, the site's own processing time and the trip back. It is the most useful single number for comparing proxies on the same target, because it excludes download time, which depends on page size.
Measure it
curl reports it as time_starttransfer. One request is noise, so take the median of several:
for i in $(seq 1 21); do
curl -s -o /dev/null -x http://USERNAME:PASSWORD@HOST:PORT \
-w '%{time_starttransfer}\n' https://example.com/
done | sort -n | sed -n '11p'
That prints the median of 21 runs. Run the same loop without -x to see your direct baseline; the difference is what the proxy route adds.
Split it
time_appconnect marks the end of the TLS handshake. Subtract it from time_starttransfer and you are left with roughly one round trip plus the server's thinking time. A large gap there points at the site, not the proxy. A large time_appconnect points at the route: a distant proxy, a slow exit, or a long chain.
Common confusion
TTFB is not latency in the narrow sense of one network round trip; it stacks several round trips and the server's work. It also varies by target: a proxy with a quick TTFB to an echo service near it can be slow to a site on another continent. Measure against the sites you will scrape, from where your scraper will run. How to test a proxy provider builds this into a repeatable benchmark.