What is server response time, and what is good?

Server response time is the time between a browser requesting a page and the server sending back the first part of the response, before any of the page has actually loaded or rendered. It is commonly measured as Time to First Byte, or TTFB, and it covers everything that has to happen before the server can start sending anything back: receiving the request, running whatever code generates the page, querying a database if one is involved, and beginning to transmit the response.

What it does and does not include

This is the part people mix up most often. Server response time is only the delay before the first byte arrives — it does not include downloading the rest of the page, fetching images and scripts, or the browser rendering any of it. A page can have an excellent server response time and still take several seconds to fully load, if it is carrying a lot of images or JavaScript afterwards. Equally, a page can have a poor server response time and still be small and simple once it starts arriving — the two numbers measure completely different things.

What counts as good

Google's web.dev documentation gives published guidance for TTFB specifically: under roughly 0.8 seconds is considered good, with the figure rising into "needs improvement" and "poor" bands above that. This is separate from the three Core Web Vitals themselves, but it is one of the most direct inputs into Largest Contentful Paint, because nothing on the page can render until the first byte has actually arrived — a slow response time adds directly to every metric measured afterwards.

What actually causes a slow response

A handful of causes account for most of it:

• An uncached dynamic page. If every request rebuilds the page from scratch — running database queries, executing template code — that work happens again for every single visitor, every single time.
• A slow database query. One inefficient query on a busy page can dominate the entire response time on its own. See how to find the query slowing your site down.
• Too much running on every request. Plugins, middleware or tracking code that executes regardless of what the page actually needs adds up, especially where several of them do similar work independently.
• Genuine server load. An account under sustained heavy resource use responds more slowly across the board, which is one of the real signals covered in when to upgrade your hosting plan.

How to check it, and rule out the rest of the page

Most speed testing tools report TTFB as a distinct figure separate from the overall load time, so you do not need to calculate it by hand. The useful comparison is testing a simple, mostly static page on the same site alongside a complex, database-heavy one. If both are slow to first byte, the cause sits upstream of any individual page's content — the server, the database, or something running on every request. If only the complex page is slow, the cause is specific to what that page does, not the hosting underneath it.

If TTFB is consistently high on simple pages after ruling out an obvious slow query or an uncached dynamic page, that is a legitimate reason to look at your hosting plan rather than the page's front end — see does hosting actually affect site speed for how to make that call properly.