About the TTFB Speed Monitor
This TTFB test measures time to first byte repeatedly instead of once. A single measurement tells you almost nothing about a website, because the number you happen to catch depends on whether that request hit a warm cache, landed on a busy origin, or arrived while a background job was running. This tool sends up to 30 requests, one per second, and plots each result as it arrives, so you see the shape of the latency rather than one sample of it.
Every probe is broken down into its phases: DNS resolution, TCP connect, TLS handshake, time to first byte, and the download that follows. That breakdown is what turns a slow number into a diagnosis. A spike in TTFB while connect and TLS stay flat points at the origin application or the database behind it. A spike in connect or TLS points at the network path or the edge terminating your certificate.
Alongside the timing, the tool reads the cache headers of every single response and classifies each one as a hit, a miss, expired, stale, bypassed or dynamic. It understands the headers used by Cloudflare, Vercel, Fastly, CloudFront, nginx, Varnish and LiteSpeed, and it also tracks the Age header and the edge location that served the response. That is usually where the answer lives: a site that alternates between 40 ms and 600 ms is almost always alternating between a cache hit and a trip to the origin.
When the run finishes you get the statistics that describe stability rather than speed: median, p95, minimum and maximum, standard deviation, jitter between consecutive probes, and a list of spikes, where a spike is any probe more than double the median and at least 40 ms above it. The tool also lists which response headers changed between samples, which quickly exposes load balancers answering inconsistently, cookies being set at random, or a CDN alternating between edge nodes.
How to use it
- Enter a bare domain or a full URL; https:// is assumed if you leave out the scheme.
- Choose how many probes to run: 10, 20 or 30, sent one second apart.
- Press measure and watch the chart fill in live, one bar per probe.
- Read the bar colours: green is a cache hit, amber is a miss or expired, cyan is dynamic or unknown, red is a failed probe.
- Use the stop button at any time; the statistics are calculated over whatever completed.
- Check the median and p95 together: a large gap between them means the slow tail matters more than the typical case.
- Click any bar or table row to inspect the full response headers of that exact probe.
- Look at the list of headers that changed between samples to spot inconsistent responses.
Examples
- https://example.com
- example.com/pricing
- https://cdn.example.com/static/app.js
- http://example.com (measures the plain HTTP endpoint before any redirect to HTTPS)
What the phase breakdown tells you
Each probe opens a fresh connection, so the handshake cost stays visible instead of being hidden by connection reuse. Reading the phases in order narrows a slow response down to one layer.
- dns: time to resolve the hostname. Consistently high values point at slow or distant authoritative nameservers.
- tcp: time to complete the TCP handshake. This is dominated by network distance to the server or edge.
- tls: time to complete the TLS handshake. Elevated values suggest an old TLS configuration, a large certificate chain, or no session resumption.
- server: time to first byte with the handshakes subtracted, so this is the origin actually thinking: application code, database queries, cache lookups.
- ttfb: request start to first response byte, still including tcp and tls, which is what a browser reports as TTFB. This is the value plotted in the chart.
- dl: time to receive the rest of the response after the first byte. Driven by response size and bandwidth, not by server logic.
How cache status is determined
The tool reads the first cache header it recognises, preferring vendor specific headers over the generic ones, and normalises the value into a single state. Chained values such as the MISS, HIT that Fastly sends are read from the last entry, because that is the layer that actually answered the request.
- cf-cache-status: Cloudflare
- x-vercel-cache and x-nextjs-cache: Vercel and Next.js
- x-litespeed-cache: LiteSpeed and its WordPress cache plugin
- x-cache and x-amz-cf-pop: Fastly, Varnish and CloudFront
- x-cache-status and x-proxy-cache: nginx proxy_cache and similar reverse proxies
- age: proves something cached the response even when no vendor header is present
Reading the stability numbers
Speed and stability are separate problems, and the second one is usually the one users complain about. These are the numbers that describe it.
- median: the typical response. More honest than an average, because one 3 second outlier cannot drag it upward.
- p95: the slow tail. If p95 is far above the median, a noticeable slice of your visitors is having a much worse time than the median suggests.
- jitter: the average change between one probe and the next. High jitter means the site feels erratic even when the median looks fine.
- variation: standard deviation as a percentage of the mean. Under roughly 15 percent reads as stable, above 40 percent reads as unstable.
- spikes: probes more than double the median and at least 40 ms above it, listed by sample number so you can inspect that exact response.
Where the measurement is taken from
Every probe runs from our server in Germany, not from your browser, so the result is not affected by your own connection, your corporate proxy or your local DNS cache. That makes it a clean measurement of the server, but it is a measurement from one location. A visitor on another continent, or behind a different CDN edge, will see different absolute numbers. The stability pattern, which is what this tool is built to show, generally holds regardless of where you measure from.
Frequently asked questions
What is a good TTFB?
Under 200 ms is generally considered good and under 100 ms is fast; Google treats 800 ms as the threshold above which TTFB needs improvement. Those figures assume a cached or lightly dynamic page. For a logged in dashboard doing real work, a higher median is normal, and consistency matters more than the absolute number.
Why does my TTFB jump between two very different values?
That is the classic signature of a cache with a partial hit rate. Compare the bar colours: if the fast probes are green hits and the slow ones amber misses, you are watching requests alternate between the edge and your origin. The note under the chart reports the average hit time against the average miss time so you can quantify the gap.
Why does the first probe often look slower than the rest?
Cold caches at several layers. The first request may miss the CDN, warm an origin cache, open a database connection pool, or compile a template. If only probe number one is slow and the rest are flat, that is usually normal warm up rather than a problem, though it is exactly what a real first time visitor experiences.
Does it follow redirects?
Redirects are resolved once, before sampling starts, and every probe then measures the final URL. Measuring a 301 thirty times would tell you about the redirect rather than the page behind it. The resolved URL and the number of redirects are shown above the chart.
Is running 30 requests going to affect the site I am testing?
No. One request per second for at most 30 seconds is far below normal traffic for any live website, and it is nowhere near a load test. It is deliberately paced this way so the tool observes the site rather than influencing it.
Can I run this from a script or an AI agent?
Yes. The same measurement is available at /api/v1/tools/ttfb with url, samples and interval parameters, and as a tool on the public MCP server. The API version runs a shorter burst so the request stays fast, and returns every sample together with the same aggregate statistics.