What is a good response time for a website?

A common target is under 200ms for server response time, the value Google cites as an ideal origin response. Lighthouse only fails its audit above 600ms, and values between 200ms and 600ms are typical for many sites, while anything over 600ms usually points to a misconfiguration or an overloaded backend. The right number depends on geography, since network latency to distant regions can add 100ms or more on its own.

How is response time different from latency?

Latency is just the network delay, the time data spends traveling between client and server. Response time is the full interval from sending the request to receiving the response, so it includes latency plus the TLS handshake and server processing. A request can have low latency of 20ms but a high response time of 800ms if the server itself is slow.

Why measure response time in percentiles instead of an average?

An average is dominated by the common case and can hide a slow tail. If 5 percent of requests take 3 seconds while the rest take 80ms, the mean might read around 226ms and look healthy, but the p95 of 3 seconds reveals the real problem. Reporting p50, p95, and p99 exposes the slow requests that drive complaints and SLA breaches.

What counts as server processing time within response time?

It is the window from when the server receives the request to when it sends the first byte, which is measured as TTFB. This covers application logic, database queries, cache lookups, and any third-party calls the request makes. Lighthouse flags this once it passes 600ms, and it sets the floor for every downstream metric, including Largest Contentful Paint.

What Is Response Time?

Reviewed by Ionut Caval · Updated June 2026

Response time is the elapsed interval from the moment a client sends a request until it receives the response, usually measured for a single request. It is a core signal in synthetic monitoring and a direct proxy for how fast a service feels.

For an HTTPS request, response time is the sum of several stages that run in sequence. Each one adds measurable milliseconds, and a slow value in any single stage inflates the total. Breaking the number into its parts is the only reliable way to find where time is actually going.

DNS lookup: resolving the hostname to an IP, often 20 to 120ms on a cold cache, near 0ms when cached.
TCP connect: the three-way handshake, roughly one network round trip.
TLS handshake: negotiating the encrypted session, one or two extra round trips (TLS 1.3 needs only one).
Server processing: application logic and database work, ending at the first byte returned. This boundary is the TTFB.
Content download: transferring the response body over the wire.

Response time vs. latency vs. page load time

These three terms are routinely confused. Latency is only the network delay component, the time a packet spends in transit. Response time is the full request-to-response interval, including server processing. Page load time is broader still: it covers the entire front-end render, including HTML parsing, subresources, and JavaScript execution after the first response arrives.

Google's older guidance set 200ms as an ideal server response, but Lighthouse and PageSpeed Insights now fail the "Reduce initial server response time" audit only when the time exceeds 600ms. Separately, TTFB is treated as a diagnostic metric in the Core Web Vitals program, with a "good" rating at 800ms or less measured at the 75th percentile, the ceiling rather than the target.

Report percentiles, not just the average

A single mean hides a long tail. If 95 requests return in 80ms and 5 return in 3,000ms, the average is around 226ms while the p95 is 3,000ms, and those slow requests are exactly the ones users notice. Report response time as p50, p95, and p99 so the tail stays visible. Pulsetic plots response time over the chosen interval on its API monitoring checks and on every public status page, making the shape of that distribution easy to read at a glance.

Frequently asked questions

What is a good response time for a website?

A common target is under 200ms for server response time, the value Google cites as an ideal origin response. Lighthouse only fails its audit above 600ms, and values between 200ms and 600ms are typical for many sites, while anything over 600ms usually points to a misconfiguration or an overloaded backend. The right number depends on geography, since network latency to distant regions can add 100ms or more on its own.
How is response time different from latency?

Latency is just the network delay, the time data spends traveling between client and server. Response time is the full interval from sending the request to receiving the response, so it includes latency plus the TLS handshake and server processing. A request can have low latency of 20ms but a high response time of 800ms if the server itself is slow.
Why measure response time in percentiles instead of an average?

An average is dominated by the common case and can hide a slow tail. If 5 percent of requests take 3 seconds while the rest take 80ms, the mean might read around 226ms and look healthy, but the p95 of 3 seconds reveals the real problem. Reporting p50, p95, and p99 exposes the slow requests that drive complaints and SLA breaches.
What counts as server processing time within response time?

It is the window from when the server receives the request to when it sends the first byte, which is measured as TTFB. This covers application logic, database queries, cache lookups, and any third-party calls the request makes. Lighthouse flags this once it passes 600ms, and it sets the floor for every downstream metric, including Largest Contentful Paint.

Put these metrics to work. Monitor your site free.

2-minute setup · Cancel any time
Create Free Account

Your Dashboard

No credit card needed