Website Response Time

A full timing breakdown for one request: DNS lookup, connection, time to first byte, and total response time.

What is a website response time test?

A website response time test measures how long a server takes to answer a request, split into the stages that make up that wait. Instead of one number, you see how long the DNS lookup took, how long it took to connect, how long the secure TLS handshake took, how long the server spent before sending the first byte, and the total.

That breakdown shows where a delay comes from, which tells you who can fix it: your DNS provider, your host or the website itself.

How website response time is measured

The tool sends one request from our server to the address you enter, adding https:// if you leave it out, and follows any redirects. It records timestamps as each stage finishes:

DNS lookup: turning the domain name into an IP address.
TCP connection: opening a network connection to the server.
TLS handshake: setting up encryption, shown for HTTPS addresses only.
Time to first byte: how long the server took to start answering once connected.
Total response time: the complete time for the request.

How to test your website response time

Enter a domain or page address.
Press Measure Response Time.
Read the total first, then look for the single largest stage.
Run the test two or three times, because one result can be affected by a passing delay.

Reading the timing breakdown

Slow DNS lookup

A long DNS stage points to slow nameservers or a long chain of CNAME records. Using a fast DNS provider usually fixes it, and repeat visitors rarely notice because DNS answers are cached.

Slow connection or TLS

These depend mainly on distance and network quality between our server and the website. A CDN with locations near your visitors shortens them.

Slow time to first byte

This is the server thinking: running code, querying a database and building the page. Page caching, a faster hosting plan or fixing slow database queries are the usual remedies.

What this test does and does not measure

The test times one request for the main document, made from our server's location. A real browser also downloads stylesheets, scripts, images and fonts and then draws the page, which usually takes longer. Use this tool for a consistent view of server speed, and a browser-based speed test for the full visitor experience.

Response time and search engines

Search engines look at loading measures from real visitors, such as Core Web Vitals, and a slow server response delays all of them, because nothing can appear until the first bytes arrive. Improving time to first byte is therefore often the first step towards a faster page. Google's guidance suggests most sites should aim for a time to first byte of 0.8 seconds or less.

Common uses

Checking whether a slow site is caused by the server or by heavy pages.
Comparing speed before and after enabling caching or changing host.
Spot-checking a server during a busy period.

Common problems and fixes

Results vary a lot. Network conditions and server load change from moment to moment. Run several tests and look at the typical result rather than a single one.

The test times out. The whole request must finish within twelve seconds. A timeout means the server is very slow or not responding.

Redirects add time. Every redirect is included in the total. Link straight to the final address to save that time.

Related tools

Website Status Checker shows timing alongside status and redirects.
Website Health Checker includes a two-second speed check in its score.
HTTP Headers Checker shows caching and compression headers.
DNS Lookup checks the records behind a slow DNS stage.

Frequently asked questions

What is a good website response time?

For the server response measured here, under about 500 milliseconds is good and under 200 milliseconds is excellent. Our Website Health Checker treats anything under two seconds as acceptable. A full page in a browser takes longer, because images, scripts and styles must also download and render.

What is time to first byte?

Time to first byte, or TTFB, is how long the server takes to start sending its answer once the connection is ready. It mostly reflects work on the server: running code, reading a database and building the page. A high TTFB usually means the site needs caching or a faster server.

Why is my response time different each time I test?

Network routes, server load and caching change from moment to moment, so every request takes a slightly different time. The first request after a quiet period can also be slower while caches warm up. Run the test several times and judge the typical value.

Does this test show how fast my page loads in a browser?

Not fully. It measures one request for the main document from our server. A browser also downloads stylesheets, scripts, images and fonts, then draws the page. Use this tool to judge server speed, and a browser-based speed test to judge the complete page load.

Why is there no TLS handshake time?

The TLS stage only exists for HTTPS addresses, where encryption is set up before data is sent. If the final address used plain HTTP, there is no handshake, so that row is hidden. Most websites should use HTTPS, which you can confirm with the SSL Checker.

Where is the response time measured from?

From our server's location. Visitors in other countries may see different times, because distance and network routes affect the connection stages. A CDN reduces this effect by serving visitors from a location near them. Time to first byte on an uncached page mainly reflects server speed.

How can I improve my website response time?

Find the slowest stage first. For a slow DNS stage, use a faster DNS provider. For slow connection or TLS, use a CDN. For a slow time to first byte, enable page caching, optimise slow database queries or move to faster hosting. Avoid unnecessary redirects, which add to every visit.