Response time is the part of page speed that happens before the browser can do anything at all. If the server takes two seconds to send the first byte, no amount of image compression will make the page feel fast. Here's what "good" looks like, how to measure it honestly, and what to fix first.
Response time vs TTFB
Time to First Byte (TTFB) is the time from the start of navigation until the first byte of the response arrives. It includes:
redirects + DNS lookup + TCP connect + TLS handshake + server processing + first byte over the network
Server response time usually means just the server processing part - how long your application took to produce the page. Both matter: the first shows what users experience, the second shows what your code and hosting are doing.
What counts as good
| Measure | Good | Needs work | Poor |
|---|---|---|---|
| TTFB (real users, p75) - Google's guidance | ≤ 0.8 s | 0.8 - 1.8 s | > 1.8 s |
| Server time, cached / static page | < 100 ms | 100 - 300 ms | > 300 ms |
| Server time, dynamic page (logged-in, cart, dashboard) | < 300 ms | 300 - 800 ms | > 800 ms |
| API endpoint (simple read) | < 200 ms | 200 - 500 ms | > 500 ms |
The server-time rows are practical targets rather than official thresholds. The most useful benchmark is your own history: a page that normally answers in 180 ms and suddenly takes 700 ms has a problem, even though 700 ms sounds acceptable.
How response time affects Core Web Vitals and SEO
TTFB isn't one of the three Core Web Vitals (LCP, INP and CLS), but it comes before all of them. Largest Contentful Paint can't happen until the HTML arrives, so if TTFB is 1.5 seconds, a "good" LCP of 2.5 seconds leaves just one second for everything else. Slow servers are one of the most common reasons sites fail LCP on mobile.
It also affects crawling. Google adjusts how much it crawls based on how quickly and reliably your server responds. Consistently slow responses mean fewer pages crawled per visit - which matters most for new sites trying to get content indexed.
How to measure it properly
From the command line
curl -o /dev/null -s -w \
"dns %{time_namelookup}s connect %{time_connect}s tls %{time_appconnect}s ttfb %{time_starttransfer}s total %{time_total}s\n" \
https://example.com
This splits TTFB into its parts: a slow dns or tls points at infrastructure, while a big gap between tls and ttfb is your server's processing time.
In the browser
DevTools → Network → select the document → Timing. "Waiting for server response" is the server part.
From real users
The Chrome UX Report (shown in PageSpeed Insights and Search Console) reports field TTFB at the 75th percentile. It's what Google sees, but it's aggregated over 28 days.
Continuously
One-off tests show a moment in time. An uptime monitor records the response time of every check, around the clock, so you see trends, daily patterns and the exact time a slowdown started.
What makes the biggest difference
- Cache full pages. For anonymous visitors, serving cached HTML from the server or a CDN takes TTFB from hundreds of milliseconds to tens. Nothing else comes close.
- Fix slow queries. Turn on the database slow query log and add the missing indexes. On WordPress and WooCommerce, autoloaded options and unindexed meta queries are frequent offenders.
- Use a persistent object cache (Redis or Memcached) for repeated expensive lookups.
- Keep PHP and your runtime current. Each major PHP version has brought real performance gains; make sure OPcache is on.
- Serve from near your users. A server in one region is 150-300 ms away from users on the other side of the world before any work is done. A CDN fixes this for cacheable pages.
- Remove redirect chains.
http → https → www → /en/costs a full round-trip per hop. Link straight to the final URL. - Use HTTP/2 or HTTP/3 and TLS 1.3 to cut connection setup time.
Watch it over time
Response times drift: a table grows, a plugin update adds a query, traffic doubles. Upmonora records response time on every check, charts it per monitor and compares it with the monitor's own baseline. When a site gets meaningfully slower, AI insights flag it with a plain-language explanation - long before it turns into the timeouts in our 504 guide. Want a quick reading now? The free website checker shows the response time of any public URL.
Frequently asked questions
What is a good TTFB?
Google's guidance is that a Time to First Byte of 0.8 seconds or less is good for most sites, measured at the 75th percentile of real visits. For the server part alone, aim for under 200-300 ms for pages served from cache and under 600 ms for dynamic pages.
Does TTFB affect SEO?
Not directly - TTFB is not one of the three Core Web Vitals. But it comes first in the loading chain, so a slow TTFB makes Largest Contentful Paint (LCP) slow, and LCP is used in Google's page experience signals.
Why is my TTFB high?
Usually slow server-side work (database queries, uncached pages, slow plugins), too few workers for the traffic, a server far away from your visitors, or extra redirects and slow DNS or TLS before the request even starts.
How do I measure response time over time?
Use an uptime monitor that records the response time of every check. That gives you a trend and alerts you to sudden slowdowns - something one-off speed tests cannot do.
