A good website response time, measured as time to first byte for an HTML page, is roughly under 200 milliseconds for a cached page and under 600 milliseconds for a dynamic one. Google’s web.dev guidance treats a time to first byte of 0.8 seconds or less as good. Above about one second, visitors start to feel the wait before anything appears on screen. These numbers are rules of thumb, not hard limits: what matters more is that your response time is stable, and that you notice when it drifts.
This guide explains what response time measures, how it differs from page load time, why your monitor and your browser report different numbers, and how to track it so slowdowns get fixed before they turn into outages.
Response time is not page load time
The two terms are often mixed up, but they measure different things.
- Response time is how long the server takes to answer a single request. For a monitor, it usually means the time from sending the request until the response has arrived.
- Page load time is how long the browser takes to show a usable page. It includes the response time of the HTML document, plus downloading and running CSS, JavaScript, fonts and images, often dozens of further requests.
A page can have a fast response time and a slow page load, for example when the server answers in 150 milliseconds but the page then loads three megabytes of JavaScript. Our tips for a faster loading website cover that front-end side. The reverse also happens: a well-optimised front end cannot hide a server that takes four seconds to produce the HTML. Response time is the part your server and your hosting control. Page load is the part your front end controls. Both matter, and they need different fixes.
What time to first byte includes
Time to first byte, or TTFB, is the time from the start of the request until the first byte of the response arrives. It is made up of several steps:
- DNS lookup: turning the hostname into an IP address.
- TCP connection: the round trip to open a connection.
- TLS handshake: agreeing on encryption for HTTPS.
- Server processing: the application runs, queries the database and builds the response.
- First byte on the wire: the start of the response travelling back.
You can see each step for your own site with curl:
curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://northwind.shop/The values are cumulative. If tls is 0.12 seconds and ttfb is 0.95 seconds, the server spent about 0.8 seconds producing the page. That is the number to work on. If the DNS or connect steps are large, the problem is distance, network or DNS rather than your application.
Why monitors and browsers report different numbers
It is normal for your uptime monitor, your browser’s developer tools and a performance testing tool to show different response times for the same page. The common reasons:
- Location. A check from another continent adds round trips for every step above. A server in Stockholm answers a visitor in Stockholm faster than a check from the US East Coast.
- Connection reuse. Your browser keeps connections open and reuses them. A monitoring check often opens a fresh connection each time, so it pays for DNS, TCP and TLS on every request.
- Caching. Your browser may have the page or parts of it cached, and a CDN may serve a cached copy to some regions and not others.
- What is measured. One tool reports TTFB, another the total time to download the full response, a third the whole page load.
- Cookies and logins. Logged-in users often bypass the page cache, so their responses are slower than an anonymous check.
None of these makes one number wrong. What matters is to compare like with like: the same check, from the same location, over time. A monitor that measures the same request every minute gives you a consistent baseline, and changes against that baseline are what you act on.
Reasonable targets, as rules of thumb
The ranges below are rules of thumb for the server response of an HTML page or API call, measured from a location reasonably close to your server. They are a starting point for your own baseline, not a standard.
| Type of response | Comfortable | Worth investigating |
|---|---|---|
| Cached page or static file via CDN | under 100–200 ms | above 400 ms |
| Dynamic page (CMS, shop, app) | under 300–600 ms | above 1 s |
| Simple API read endpoint | under 100–300 ms | above 800 ms |
| Search, reports, heavy queries | under 1–2 s | above 3 s |
Two notes on reading the table. First, add network distance: a check from another continent can add a few hundred milliseconds on top, and that is not something your application can fix. Second, the column that matters most is the one you set yourself. If your checkout normally answers in 350 ms and today it answers in 900 ms, something has changed, even though 900 ms still looks acceptable on paper.
What slows response times down
When response time goes up, the cause is almost always one of these:
- Slow database queries: a missing index, a query that grows with the size of a table, or a plugin running dozens of queries per page.
- No page or object cache: every request rebuilds the same page from scratch.
- External calls during the request: payment, shipping, search or analytics APIs called synchronously while the visitor waits.
- Too few workers: requests queue behind each other when PHP-FPM, Node or application server workers are all busy.
- Resource pressure: CPU at the limit, memory swapping or disk I/O saturated by backups or log writes.
- Cold starts: serverless functions and containers that scaled to zero take time to start the first request.
- Distance: visitors far from the server with no CDN in between.
Queues are the reason response time matters for availability. When responses get slower, each request holds a worker longer, the pool fills up, and new requests wait or are rejected. A slowdown that starts as an extra half second can end as a 503 Service Unavailable error at the next traffic peak.
Track the trend, not a single check
A single slow check means little. A network blip, a garbage collection pause or a cache miss can make one request slow. What tells you something is wrong is a pattern:
- A step change: response time jumps after a deploy, a plugin update or a hosting change, and stays there.
- A slow climb: response time grows a little every week as a table or a log grows.
- A daily pattern: response time spikes at the same hour every day, often a backup, an import or a cron job competing for resources.
- A regional difference: one region is slow while another is fine, which points at a CDN, routing or DNS rather than the server.
Uptimecheck stores the response time of every check for each uptime monitor and API monitor, and the weekly and monthly email reports summarise response times next to uptime. That history is what lets you see a step change on the day it happens instead of weeks later.
Alert on sustained slowness
Alerting on every slow check creates noise, and noisy alerts get ignored. Alert on slowness that lasts. A practical approach:
- Measure your baseline for each important endpoint over a week or two.
- Set the warning level clearly above normal variation, for example two to three times the usual response time.
- Only alert when the slowness persists over several consecutive checks or minutes.
- Send slowness warnings to a team channel, and keep phone or SMS alerts for outright failures.
- Set a timeout on every check. A response that takes 30 seconds is a failure for a visitor, whatever the status code.
The same principles apply to every alert you configure. Our guide on reducing false alerts in uptime monitoring covers confirmation and thresholds in more detail, and choosing server alert thresholds explains how to set limits for CPU, memory and disk. When response times climb, server monitoring next to your uptime checks shows whether the server is the cause, so you are not guessing between the database, the network and the code.
Response time checklist
- Measure TTFB for your key pages and endpoints with curl, from near your server.
- Monitor the same pages every minute and keep the history.
- Write down a baseline per endpoint and compare against it, not against a generic number.
- Investigate step changes after deploys and slow climbs over weeks.
- Cache what you can, fix slow queries and move external calls out of the request.
- Alert on sustained slowness and on timeouts, not on single slow checks.
Summary
A good response time is one that is low for its kind of page, close to your own baseline and stable over time. As a rule of thumb, aim for a few hundred milliseconds for dynamic pages and well under that for cached ones. Measure it the same way every time, watch the trend and treat a sustained rise as an early warning, because today’s slow page is often tomorrow’s outage.
Uptimecheck records response times on every check, so you see slowdowns as well as outages. Try it free for 14 days, no credit card required.