TTFB Test
This free TTFB test measures how long a website takes to start answering. It times the DNS lookup, the connection, the TLS handshake and the wait for the first byte on three fresh connections from our server in Germany, then grades the median.
Free, no signup.
What the TTFB test measures
TTFB means time to first byte: how long passes between asking a server for a page and the first byte of its answer arriving. We run the request three times, each on a new connection, and split every run into its steps: finding the address (DNS), connecting, setting up encryption (TLS) and waiting for the server to start answering.
After the first byte comes the download of the page, which is also shown, so you can see whether a slow page is slow to start or slow to finish. The grade uses the median of the three TTFB figures, which keeps one unlucky run from deciding the result.
How to read the grade
A median TTFB of 800 ms or less is graded Good. Up to 1,800 ms is Needs improvement, and above that it is Poor. These are the limits web.dev suggests for how fast a server should start answering.
Each bar shows where one run spent its time. A long waiting part usually means the server is slow to build the page, for example because of heavy PHP code, a slow database or a busy shared machine. A long connect or TLS part points to distance or an overloaded network, and a long DNS part to a slow name server.
Why our number can differ from yours
We test from our server in Germany, over HTTP/1.1, and every run opens a fresh connection. A visitor on another continent sees a higher figure, because every round trip takes longer. Browsers also reuse connections and often speak HTTP/2 or HTTP/3, so the connection part is smaller for them on repeat visits.
A CDN or page cache changes the picture the most. When the cache headers say HIT, a cache answered and the figure is usually much lower than what the server behind it needs to build the page. A MISS means the request went through to the origin server. We don't follow redirects, so if the address redirects you see the time for the redirect, and you can test the final URL with one click. The total leaves out the DNS lookup, because only the first run does one.
How to lower a slow TTFB
Start with caching: a full-page cache or a CDN lets repeat requests skip the slow work. Then look at what the server does for each page, such as slow database queries, plugins or themes that do too much, and an old PHP version. Fast storage and enough free memory on the server help too.
If the waiting part stays high on a quiet site, the server itself may be too small or too busy, and a move to a plan with more resources can help. Run the test a few times at different hours, because a figure that is only bad at busy times points to a shared machine under load.
Frequently asked questions
What is TTFB?
TTFB stands for time to first byte. It is the time from sending a request to the first byte of the answer coming back. It includes the network trip and the time the server needs to start answering, so it shows how quick the server and the connection to it are.
What is a good TTFB?
A TTFB of 800 ms or less is considered good, up to 1,800 ms needs improvement and anything above is poor. Those limits come from web.dev. Our figure is one measurement from Germany, so use it as a guide and compare runs over time.
Why is my TTFB different in PageSpeed Insights or my browser?
Each tool measures from another place, over another protocol and with different caching. We test from our server in Germany, over HTTP/1.1, with a fresh connection per run. Browsers reuse connections, use HTTP/2 or HTTP/3 and may get a cached page, so their numbers can be lower or higher.
How can I lower my TTFB?
Use a full-page cache or a CDN, keep your PHP version and software up to date, remove slow plugins and database queries, and make sure the server has enough resources. The bars show whether the time goes into DNS, connecting, TLS or the wait for the first byte, which tells you where to look first.
What do cache HIT and MISS mean?
HIT means a cache answered without asking the origin server, which is usually much faster. MISS means the page was not in the cache, so the request went to the origin. Headers such as cf-cache-status, x-cache and x-litespeed-cache say which one happened.
Why does the test not follow redirects?
The time to reach a redirect and the time to reach the final page are two different things. We time the address you enter. If it redirects, the result shows where, and the Test the final URL button runs the test again on that address.
Why is DNS not part of the total?
Only the first run looks up the address, and the other two reuse it, so counting DNS would make the runs hard to compare. The DNS time is shown by itself, and the total starts when the connection starts.
How often can I run this test?
Each visitor can run 2 checks a minute and 10 an hour, and each site can be tested 20 times an hour. We don't keep results, so every check is a fresh measurement.
Do you store the results?
We don't keep the timings. Our server logs which host was tested for 14 days so we can deal with abuse. We don't store your IP address, only a scrambled form of it.
Dig deeper
HTTP/3 Test
Does a site offer HTTP/3 and HTTP/2? We read what it advertises and send a QUIC probe, so you see what browsers can use.
Test HTTP/3HTTP Header Checker
Every response header a site sends, after its redirects, with the common ones explained in plain English.
See headersWebsite Down Checker
Is a site down for everyone or just you? See the status code, how fast it answered and why it fails.
Check a site