TTFB checker
Measure time to first byte for any page and see exactly where it goes: DNS lookup, TCP connect, TLS handshake and the time your server spends building the page.
We connect from a server, follow redirects, then time three fresh requests (new DNS, TCP and TLS each time) and report the median.
What time to first byte measures
TTFB is the time from the moment the browser starts navigating to the moment the first byte of the HTML response arrives. It adds up every step before the server can start sending anything:
- Redirects: each hop (http → https, example.com → www) repeats the whole process.
- DNS lookup: turning the domain name into an IP address.
- TCP connect: one round trip to open the connection.
- TLS handshake: one more round trip on TLS 1.3, two on TLS 1.2, to set up encryption.
- Server time: the server receives the request, runs your code and database queries, and starts replying.
Connection steps are bound by distance: light in fibre covers about 200 km per millisecond, so a visitor 8,000 km from your server pays roughly 80 ms for every round trip before any code runs. That is why a CDN helps even for dynamic pages. Server time is the part you control in code, and caching the finished HTML removes most of it.
How to reduce TTFB
- Serve cached HTML from a CDN edge (full-page caching, static generation or stale-while-revalidate).
- Cut redirect hops: link to the final canonical URL and set up HSTS so browsers go straight to https.
- Speed up the origin: add database indexes, cache expensive queries, and upgrade from overloaded shared hosting.
- Use TLS 1.3 and HTTP/2 or HTTP/3, which most CDNs enable by default.
- Send the
<head>early with streaming or103 Early Hintsso the browser can start fetching CSS while the server finishes.
Questions people ask
What is a good TTFB?
Google’s guidance is 0.8 seconds or less at the 75th percentile of real visits, and over 1.8 seconds is poor. TTFB isn’t a Core Web Vital itself, but everything else, including LCP, waits for it.
Why is my first request slower than the others?
Each of our three requests opens a fresh connection, so DNS, TCP and TLS are always included. If the first is much slower, the server or CDN likely had a cold cache and the later requests were served from cache.
Why does this TTFB differ from PageSpeed Insights?
Our probe runs from one server location without a browser. Lighthouse’s “server response time” only covers the wait for the HTML, not DNS and connection setup, and field TTFB is the 75th percentile of real users all over the world. Each answers a slightly different question.
Does TTFB include redirects?
Yes. In Google’s definition TTFB starts at navigation, so every redirect hop before the final page is included. We time the redirect chain and add it to the headline number.