methodology / Security / #98
TLS handshake latency
#98 · Recommended · Web Quality · weighted · Security · impl todo · source Wall-clock timing of the TLS handshake recorded by our Cloudflare-Container TLS prober. Worker-direct path isn't yet instrumented for this signal — only Container-path domains will show it.
Web Quality factor
This factor is part of Web Quality — the weighted 0..100 score that sits above Web Standards. Its weight depends on what kind of site is being measured. Web Standards items take priority; this factor only enters the score once Web Standards passes.
No matrix row defined yet — this factor falls back to a neutral weight of 1.0 across every site type until the methodology is tuned.
What this means for your business
Before a page can even start loading, the browser and server have a quick back-and-forth to set up the encrypted connection. When that takes too long, every first-time visitor feels the lag — and Google notices it too.
Plain title: Your site finishes its handshake quickly
Want the long version? Read the full explainer with examples →
What we measure
Wall-clock time from TCP open to TLS handshake complete. Slower handshakes hurt page-load LCP for first-time visitors and signal poor server tuning — typical culprits include no session resumption, slow OCSP responder, geographically far origin, or SSL processing on a constrained CPU. Browser users feel this on every cold connection. Background API clients eat the latency on every poll.
How to improve your score
Common quick wins: enable OCSP stapling (eliminates the OCSP fetch round-trip during the handshake — see WEBQ-91), enable HTTP/2 + ALPN (avoids round-trip in protocol negotiation), enable session resumption (TLS 1.3 makes this automatic via session tickets), use ECDSA certs instead of RSA (faster signature operation). Geographically: put a CDN in front of your origin so the TLS handshake terminates close to the user, not on your backend in us-east.
Facts
Implementation notes
pass=100: ≤ 500 ms (healthy edge / regional CDN territory). warn=60: ≤ 1500 ms (acceptable but room to improve). fail=0: > 1500 ms (page load takes the hit; users feel it).
Scoring
Scoring formulas are versioned with the methodology. The current method maps raw measurements to pass, warn, fail. Factor weights determine how much each contributes to the composite — see the methodology index for the full table.
Version history
| Version | Change | Date |
|---|---|---|
| v0.1 | Factor introduced. Status: proposed. Scoring impl: todo. | 2026-04-25 |