Website Response Time: What It Is, How to Measure It and How to Improve It

Website response time is the time between a browser (or any client) sending a request to your website and receiving the first part of the server's answer. It covers finding your server, connecting to it, setting up encryption and waiting for your application to produce the page. It's one of the most useful health signals a website has, and it's often confused with page load time.

This guide explains what response time includes, how to measure it, what a good value looks like, how to read the numbers over time and which improvements make the biggest difference. Want a number right now? Run the free website response time checker and come back to interpret the results.

What website response time includes

A single request to an HTTPS page goes through several phases. Each one adds time, and each one has different causes and fixes.

Swipe sideways to see the whole diagram

The time from the start of the request until the first byte of the response arrives is called Time to First Byte (TTFB). In practice, "server response time" and TTFB are often used interchangeably; uptime monitors usually report the time until the response headers arrive, which is essentially the same moment.

Two details are worth knowing:

• Repeat visits are faster. Browsers cache DNS answers and reuse open connections, so DNS, connection and TLS often disappear on the second page a visitor opens. A first visit, or a monitoring check on a fresh connection, pays all of them.
• Redirects multiply the cost. If http://example.com redirects to https://www.example.com/, the visitor pays for two requests before seeing anything.

Response time vs. page load time

Response time and page load time measure different things:

• Response time tells you how quickly the server starts answering the request for the HTML document.
• Page load time, and user-centric metrics such as Largest Contentful Paint (LCP), include everything that happens afterwards: downloading stylesheets, scripts, fonts and images, and rendering the page.

A page can have a fast server response and still feel slow because of heavy images or scripts, and a beautifully optimised front end can't hide a server that takes three seconds to answer. Response time is the foundation: every other loading metric starts after it. Google documents the user-centric metrics at web.dev/vitals. We compare the two perspectives in Website Uptime vs Website Performance.

What is a good website response time?

There's no single correct number, because response time depends on distance, the type of page and the hosting setup. Useful reference points:

• Google's guidance for Time to First Byte suggests that most sites should aim for 0.8 seconds or less and considers values above 1.8 seconds poor, measured from real users.
• Static or well-cached pages served from nearby can respond in tens of milliseconds.
• Dynamic pages that query a database commonly respond in a few hundred milliseconds.
• Consistently taking more than a second or two usually indicates something worth investigating.

More important than any absolute target is your own baseline. If your homepage normally responds in 250 ms and suddenly takes 1,500 ms, something has changed, even though 1.5 seconds isn't catastrophic on its own.

How to measure website response time

1. Use an online response time checker

The quickest option is a tool that requests your page from an external server and breaks the result down by phase. Our free website response time checker sends three requests on fresh connections, shows the median time to first byte and tells you how long DNS, connection, TLS and server processing each took, so you can see which part to fix.

2. Measure from the command line with curl

curl can print detailed timings. Save this format to a file called curl-format.txt:

    dns lookup:  %{time_namelookup}s
       connect:  %{time_connect}s
   tls (total):  %{time_appconnect}s
 first byte at:  %{time_starttransfer}s
         total:  %{time_total}s

Then run:

curl -o /dev/null -s -w "@curl-format.txt" https://example.com/

Note that curl reports cumulative times: each value is measured from the start of the request. To get the duration of a single phase, subtract the previous value. For example, server processing is roughly time_starttransfer − time_appconnect.

3. Use your browser's developer tools

Open the developer tools, go to the Network tab, reload the page and select the first request (the HTML document). The Timing view shows DNS lookup, initial connection, SSL, "waiting for server response" (TTFB) and content download. Remember that your own browser may reuse cached DNS and open connections.

4. Monitor it continuously

A single measurement is a snapshot. Response time changes with traffic, time of day, background jobs and gradual data growth. An uptime monitor records response time on every check, which turns snapshots into a trend. UptimeStats stores the response time of every check, every 5 minutes, and shows 24-hour and 7-day charts on each website's page.

How to read response time data

Look at trends, not single values

Individual checks vary because of network conditions. One slow check is rarely meaningful. Look at the chart over hours and days: is the line flat, gradually rising or spiking at certain times? Medians and averages over a period are more reliable than individual values.

Patterns and what they often mean

• Gradual increase over days or weeks: growing database tables without proper indexes, accumulating data, a filling disk or growing traffic.
• Spikes at the same time every day: scheduled jobs such as backups, imports or report generation competing for resources.
• A sudden step change: a deployment, plugin update, configuration change or hosting change.
• Rising response times followed by timeouts: the server is running out of capacity, an early warning of an outage. See What Causes Website Downtime?
• High connection and TLS times but fast server processing: the server is far from where it's being measured, or the network path is congested.

Distance matters

Response time measured from a monitoring server depends on the distance between that server and yours. A monitor on another continent always sees higher numbers than one nearby. Compare measurements from the same location over time, and remember that your visitors' experience depends on where they are.

How to improve website response time

Start with the phase that takes the longest. The breakdown from the response time checker or curl tells you which one that is.

If server processing is slow

This is the most common bottleneck and usually the biggest opportunity.

• Cache full pages. The fastest response is one the server doesn't have to compute. Full-page caching serves pre-built HTML to anonymous visitors; most content management systems have mature caching plugins or modules.
• Use an object cache. An in-memory store avoids repeating expensive database queries and computations on every request.
• Optimise database queries. Enable the slow query log, add indexes for frequent lookups, load only the data a page needs and remove queries that run on every request without need.
• Audit plugins and extensions. Each one may add work to every request. Remove what you don't use and measure after each change.
• Keep the software stack current. Newer versions of language runtimes, web servers and databases often bring significant performance improvements as well as security fixes.
• Move slow work out of the request. Sending emails, generating thumbnails or calling slow external APIs can happen in background jobs instead.
• Right-size the server. If CPU or memory is constantly near its limit, optimisation can only go so far; more resources or more servers may be needed.

If connection and TLS are slow

• Serve from closer to your visitors. Choose a hosting region near your main audience, or put a CDN in front of the site so connections terminate nearby.
• Enable TLS 1.3. It needs fewer round trips for the handshake than older versions.
• Enable HTTP/2 or HTTP/3 to reduce connection overhead for the resources that follow the HTML.
• Serve a compact, complete certificate chain and enable OCSP stapling. Check your certificate with the SSL checker.

If DNS is slow

• Use a fast, reliable DNS provider with servers near your audience.
• Avoid long chains of CNAME records that each require another lookup.
• Use reasonable TTLs so resolvers can cache answers. Inspect your records with the DNS lookup tool and read how DNS problems affect availability.

If redirects add time

Link directly to final URLs, update internal links after migrations and keep necessary redirects to a single hop, for example straight from http://example.com to https://example.com/. The HTTP status checker reveals redirect chains, and our guide to HTTP status codes explains 301 vs 302.

Common mistakes when measuring response time

• Testing only from your own computer. Your browser reuses connections and cached DNS, and your location may be close to the server.
• Judging by one measurement. Use several samples and look at the median.
• Measuring a cached page only. The homepage may be cached while product, search or account pages are generated on every request. Test the pages that matter.
• Confusing response time with load time. A fast TTFB doesn't guarantee a fast page, and the fix for each is different.
• Ignoring the trend. Slowly rising response times are one of the best early warnings you can get.

Frequently asked questions

What is the difference between response time and TTFB?

TTFB is the time until the first byte of the response arrives. Server response time is commonly used to mean the same thing. Some tools use "response time" for the full download of the response instead, so check how a tool defines it.

Does website response time affect SEO?

Response time is the first part of every page load, so it influences user-centric metrics such as Largest Contentful Paint, which are part of how search engines assess page experience. Content relevance and quality matter far more, but a slow server makes everything else slower. Very slow or failing responses also affect how efficiently search engines can crawl your site.

Why is my response time different every time I test?

Network conditions, server load, caching and background jobs all vary. That's why good tools take several samples and report a median, and why monitoring over time is more informative than a single test.

How often should I check response time?

Continuously, through monitoring. Checks every few minutes give you a reliable trend without adding meaningful load to your server.

Summary

• Website response time is how long the server takes to start answering, including DNS, connection, TLS and server processing.
• Google suggests aiming for a TTFB of 0.8 seconds or less; your own baseline and trend matter even more.
• Measure with a phase breakdown so you know which part to fix: an online checker, curl or browser developer tools.
• Caching and efficient database queries fix most slow servers; CDNs, TLS 1.3 and fewer redirects address network-related delays.
• Monitor response time continuously to catch slowdowns before they turn into outages.

Test your site now with the free response time checker, or start monitoring for free to track response time every 5 minutes.