Response Time Benchmarks: Is Your Server Fast Enough?
What server response time measures, how it sits underneath every other speed metric, and how to check your whole top-50 rather than one page at a time.
Like it ? share it
Every page speed metric you care about sits on top of one number you usually do not look at: how long the server takes to answer at all. Images, scripts and rendering all happen after that. If the server takes a second to start replying, nothing downstream can recover it.
That number is time to first byte, and it is the floor under your Largest Contentful Paint.
What is actually being measured
Response time here is the connection, the request, the server's own processing, and the response headers coming back. It stops before the page body is read, so it isolates the server from the size of what it sends.
The question it answers is narrow and useful: how long until the server says anything at all?
Rough bands
There is no official threshold, and the right target depends on what the page has to do. As a working scale:
| Response time | Reading |
|---|---|
| Under 200ms | Fast. The server is not your problem |
| 200 to 500ms | Normal for a database-backed CMS. Room to improve, not urgent |
| 500ms to 1s | Slow enough to feel, and slow enough to squeeze your LCP budget |
| Over 1s | The server is the bottleneck. Nothing you do to the front end will fix it |
Treat these as directions, not grades. A static page answering in 400ms is underperforming. A complex authenticated dashboard at 400ms is doing well.
Checking more than one page
PageSpeed Insights measures one URL at a time, which is right for diagnosis and wrong for finding out where you stand.
Paste your top fifty URLs into the Bulk URL Checker and sort by the time column. The tool flags anything over 500ms, so the slow group separates itself.
Reading the shape
The distribution tells you more than the average.
Everything is slow. If all fifty pages sit around 800ms, the problem is shared: the host, the database, or a cold cache. Nothing template-specific will help.
Most are fast, one group is slow. If the site answers in 100ms except for product pages at 1.2s, the problem lives in that one template. Usually a query that was fine at a hundred rows.
One page is an outlier. Almost always a single expensive thing on that page, and the easiest kind to fix.
Getting the baseline is the point. Without it you cannot tell whether last month's change helped, and you will be arguing about it from memory.