LP

Computer & IT

Latency Performance Calculator

Build a request latency budget from DNS, protocol handshakes, network round trips, server processing, transfer time, jitter, and critical-path request count.

Critical-path latency budget

Build page-response time from connection rounds, server work, transfers, and sequential requests

The model separates the first connection from reused-connection requests and adds a transparent jitter allowance for a planning p95.
First response427 ms
Reused request199 ms
Critical path1,024 ms
Planning p951,096 ms
Connection share47.7%
Time to first byte391 ms

Protocol waterfall

Handshake, wait, and payload work on the sequential critical path

Each row advances from the previous request; only the first row pays DNS, TCP, and TLS setup.

Detailed calculation process

Count round trips explicitly instead of hiding them in one latency number

General symbolic formulas

L₁ = DNS + RTT(TCP + TLS + 1) + S + XLreuse = RTT + S + XLpath = L₁ + (N − 1)Lreuseσpath = J√NLp95 ≈ Lpath + 1.645σpathTTFB = L₁ − X

The extra first-response round is the request/response RTT after setup. Sequential requests are deliberately conservative; parallel resources require a dependency graph instead.

Symbols and units

DNS resolver time (ms)RTT network round trip (ms)TCP, TLS setup round countsS server processing (ms/request)X response transfer (ms)N sequential requestsJ request jitter SD (ms)L end-to-end latency (ms)

Worked substitution with current inputs

Request timing ledger

RequestConnectionServerTransferCumulative end

Use steps

  1. Measure median RTT from the target region.
  2. Use the negotiated TCP/TLS handshake pattern.
  3. Count only requests that block the outcome.

Examples

Persistent HTTP: later requests avoid connection setup.

Edge compute: lower RTT can outweigh modest server-time changes.

Limitations

This deterministic budget excludes packet loss, congestion control, HTTP multiplexing, cache hits, connection coalescing, DNS caching, browser scheduling, payload compression, and correlated tail latency.

Latency FAQ

Why add one RTT after setup?

The application request must still travel to the server and its response begin returning.

Is this a true p95?

No. It is a normal-approximation planning allowance; production percentiles should come from traces.

Should parallel requests be added?

No. For parallel branches, use the longest dependent branch rather than summing all requests.