Response Time Test
Measure how fast a page responds.
Checked from our server. One location, so results show reachability from there only.
What the response time test does
When a page feels slow, the first question is where the time goes. The response time test requests a URL from our server and splits each request into four phases: looking up the domain in DNS, opening a TCP connection, setting up encryption (the TLS handshake) and waiting for the first byte of the reply.
That breakdown helps you tell a slow server apart from a slow network. Run it before and after a hosting change, after turning on caching, or when visitors say a page takes a while to start loading. It times the page’s own response, not the images and scripts a browser loads afterwards, so it shows the server’s side of page speed.
How to use the response time test
- Paste the URL of the page to test.
- Press Run test. We make three requests, each on a fresh connection, and show the median.
- Read the waterfall to see where the time goes. If the URL redirects, test the final address instead.
Understanding the results
The headline figures are the median total and the median time to first byte. The label beside them is based on time to first byte alone: under 200 ms is marked fast, under 600 ms good, under 1,500 ms slow, and anything longer very slow. The waterfall shows the phases in order, so the longest bar tells you where to look. Long DNS times point at the domain’s name servers. Long connect and TLS bars often reflect the distance between our server and the site. A long first-byte bar means the server took its time building the page, which caching often helps.
The table lists all three runs side by side. If one run is far slower than the others, the server may have had a brief hiccup, and the median keeps it from skewing the result. Each request waits up to six seconds for an answer.
Questions
What is time to first byte?
The time from sending the request to receiving the first byte of the answer. It mostly reflects how fast the server builds the page.
Why are my own load times different?
Checks run from our server, in one location, so results show what that location sees. Your distance from the site, your connection and your browser cache all change what you see.
Why three requests?
A single request can be unusually slow or fast. The median of three is more representative.
Why did it time a redirect instead of my page?
The test times exactly the address you give it and doesn’t follow redirects. If that address answers with a redirect, you’ll see a notice with a link to test the final address instead.
Is the TLS handshake always shown?
Only for https:// addresses. If the timings don’t separate it out, the handshake is counted inside time to first byte, and the result says so.