TTFB Checker: Test Time to First Byte Online

TTFB Checker: Test the Time to First Byte of a Website

TTFB (time to first byte) is the time from the moment a browser asks for a page to the moment the first byte of the answer arrives. It shows how fast the server and the network start to answer, before a single line of the page is shown. Enter an address, choose how many runs to make, and get the TTFB split into phases: redirects, DNS, connect, TLS and the wait for the server. The tool is also known as a time to first byte test and a server response time checker.

What TTFB is made of

• Redirects. Every redirect (for example http to https, then to www) is a full request before the real one.
• DNS. Finding the IP address of the host name.
• Connect. The TCP connection to the server. It depends on the distance between the visitor and the server: a CDN has servers close to visitors.
• TLS. The handshake of HTTPS, after the connection is made.
• Wait. The time of the server itself: the request travels there, the application and the database build the page, and the first byte comes back. Slow work of the server shows up here.

What is a good TTFB

Google gives the thresholds on web.dev: a TTFB of 0.8 seconds or less is good and above 1.8 seconds is poor; the range in between needs improvement. TTFB is not one of the Core Web Vitals, but Google says that sites should aim for 0.8 seconds or less, so that most visitors (the 75th percentile) get a good First Contentful Paint.

Why the tool makes several runs

One number is not reliable: the network jumps from one request to another. The first run is marked cold: the caches of the site and the DNS may still be empty, so it can be slower than the next ones. Every run opens a new connection, and the tool shows the fastest run, the slowest run and the median, which is the number to compare between tests.

How to make TTFB lower

The list follows the guide of Google on web.dev, "Optimize Time to First Byte":

• Check the hosting first. Shared hosting is generally slower.
• Use a CDN. Its servers are closer to the visitors, and a CDN usually brings HTTP/2, HTTP/3, modern TLS and better compression.
• Use cached content where possible, with the Cache-Control headers.
• Avoid redirects. One redirect adds a delay to the request. HSTS (and the HSTS preload list) removes the redirect from http to https.
• Send the page in parts (streaming), use 103 Early Hints for the important resources, and add the Server-Timing header to see where the time of the server goes.

How to measure TTFB yourself

With curl. This command prints the time of every phase. Note that curl shows the sum from the start, so the numbers grow from line to line, and time_starttransfer is the TTFB:

curl -o /dev/null -s -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n' https://example.com/

In the browser. Open the developer tools of Chrome, the tab Network, click the first request and open Timing. The line "Waiting (TTFB)" is the time the browser waits for the first byte; Chrome says that it includes one round trip of latency and the time the server took to prepare the response. Google also names the Chrome User Experience Report (CrUX), the web-vitals library and WebPageTest as tools that measure TTFB. This page shows the phases one by one.

How this checker works

• The request is made from the server of dieg.dev, from one place. The numbers of a visitor in another country, or of a site that is fast only near its server, can be very different.
• The tool sends its own name in the User-Agent (DiegDevChecker) and only a plain GET request: no cookies, no login, no forms. Only public addresses and the usual web ports are checked.
• The first run also reads the HTML (at most 2 MB) to show its size and the compression. The other runs stop as soon as the answer starts.
• The number of checks is limited for every visitor and for every checked site, so that the tool cannot be used to load a site. A short journal of the checks (the checked host, the time and a code of the visitor, not the address) is kept for 7 days to answer complaints.

Related tools

To see the whole redirect chain and the headers use the HTTP status code and redirect checker, to check the certificate the DNS lookup (it shows the SSL certificate too), and to see which HTTP version (HTTP/1.1 or HTTP/2) the server uses and whether it announces HTTP/3 the same HTTP status code checker.