Real browser timing
Uses the Resource Timing API to read genuine DNS, TCP, TLS, TTFB and download phases for a URL you fetch.
Measure DNS, TCP, TLS, TTFB and download timings for a real URL, or drag sliders to simulate any timing profile — both render the same color-coded waterfall chart.
Enter any URL and press Measure. Same-origin URLs give the most detail.
All measuring and simulating happens locally in your browser.
Uses the Resource Timing API to read genuine DNS, TCP, TLS, TTFB and download phases for a URL you fetch.
When a cross-origin server hides timing detail, the tool says so instead of guessing at numbers it cannot see.
Drag five sliders to explore any timing profile, even when real measurement is restricted by the browser.
Pick whichever mode fits what you're trying to learn: real-world measurement or a controlled thought experiment.
Every network request moves through the same handful of stages before your data arrives. Seeing them broken out, instead of a single blended number, makes it obvious where time is actually being spent and which phase is worth optimizing.
Translating a hostname into an IP address. Repeated requests to the same host are usually much faster here thanks to DNS caching.
The handshake that opens a raw connection between your browser and the server, before any encryption or data exchange happens.
For HTTPS, an extra round trip (or more) to agree on encryption keys. This phase is skipped entirely on plain HTTP connections.
TTFB is server processing plus network latency before the first byte arrives. Download is the time spent streaming the rest of the response body.
Questions about measurement limits, timing phases and privacy.
Browsers only expose detailed DNS, TCP, TLS and TTFB timings for cross-origin requests when the server sends a Timing-Allow-Origin header. Without it, the Resource Timing API zeroes out the individual phases and only the overall duration is available, which this tool shows along with an explanation.
TTFB (time to first byte) is the gap between the browser finishing its request and the first byte of the response arriving. It reflects server processing time and network latency, and is often the biggest lever for perceived API speed.
TCP connect time is the handshake that opens a raw connection to the server. TLS negotiation happens afterward, on top of that connection, to agree on encryption for HTTPS. Plain HTTP requests skip the TLS phase entirely.
No. The Measure tab uses your own browser's fetch and Performance API to time a request it makes directly. Nothing passes through My Panda Toolbox's servers.
No. Measured and simulated timings stay in your browser tab and are never stored or transmitted.