Website Response Time Explained: TTFB, Latency, and When Slow Becomes Down
TTFB measures the duration from HTTP request dispatch to the first byte of response ”” it is the server’s answer to: “How long did processing take?” Above 800ms, it signals a server-side problem. Above 10 seconds, monitoring probes time out and it counts as downtime.
Fast: TTFB < 200ms — server processed and responded before users perceive any delay.
Acceptable: 200–800ms — Google’s “good” TTFB range for Core Web Vitals.
Slow: 800ms–3s — users notice. Bounce rate increases measurably above 3s.
Functional downtime: >10s — probe timeouts fire, uptime monitors record a down event, users have abandoned the page.
What TTFB Measures and What It Does Not
TTFB (Time to First Byte) measures the total elapsed time from when an HTTP request is dispatched by the client to when the first byte of the HTTP response header is received. It captures two distinct components: network round-trip time (RTT) between the client and server, and server-side processing time (the time the server spends generating the response before sending any data). TTFB = DNS lookup + TCP handshake + TLS handshake + server processing time + first byte transit.
The server processing component is the only part of TTFB that application developers can directly control. DNS lookup time is determined by resolver performance and TTL. TCP handshake time is determined by geographic distance (1 RTT = 2× one-way latency). TLS handshake time is reduced by TLS 1.3 (0-RTT resumption) and CDN termination near the user. When TTFB is high, the first question is always: how much of that time is server processing vs network transit?
To isolate server processing time from network latency, measure TTFB from the same geographic location as the server (co-located test) and compare it to TTFB from a geographically distant client. The difference is network transit time; the co-located measurement is server processing time alone. TTFB does not measure page load time, resource download time, JavaScript execution time, or Time to Interactive — it measures only the server’s response latency before the client has received any content at all.
TTFB with a CDN: When a CDN is in full-proxy mode and the request is a cache hit, TTFB measures the CDN PoP’s response time — typically 5–50ms, regardless of where your origin is. For cache misses, TTFB includes the CDN-to-origin round trip, which can add 50–200ms depending on geographic distance between the PoP and your origin data center.
Response Time Benchmarks — What Is Fast, Acceptable, Slow, and Down
TTFB benchmarks are contextual: a 500ms TTFB is acceptable for a server-rendered dynamic page making database queries, but indicates a serious problem for a static file served from a CDN cache. The appropriate benchmark depends on what your server is doing to generate the response. A CDN serving cached HTML should return TTFB under 50ms. A server-rendered page querying a database should return TTFB under 500ms. An API endpoint performing complex business logic may justify 300–700ms. Google’s universal guidance for Core Web Vitals sets 800ms as the maximum “good” TTFB for any page type.
Amazon’s research showed every 100ms of additional latency costs 1% in revenue. Google found a 0.5-second delay in search results reduced traffic by 20%. These figures are for page load time, not TTFB alone — but TTFB is the first bottleneck in the chain. A slow TTFB delays every subsequent resource load: CSS cannot begin downloading until the HTML arrives, JavaScript cannot execute until it downloads, and the page cannot render until scripts execute. TTFB compression is always the highest-leverage performance optimization because it has a multiplicative effect on all downstream loading.
What Causes High TTFB — Server, Network, and Application Layer
High TTFB has distinct root causes at the database layer, application layer, network layer, and CDN configuration layer — and diagnosing which layer is responsible determines the fix. The most common cause is a slow database query blocking the response thread, but application architecture, geographic distance, and missing caching each account for a significant share of high-TTFB incidents.
Slow or unindexed database queries
A query performing a full table scan on a million-row table blocks the application thread until it completes. The HTTP response cannot begin until the query finishes — adding the query execution time directly to TTFB. This is the most common cause of high TTFB in server-rendered applications.
Fix: Add indexes, paginate results, cache query results in Redis, use EXPLAIN ANALYZE to identify slow queries.No server-side caching (cache bypass on every request)
Every request regenerates the page from scratch: querying the database, rendering templates, computing personalizations. For pages with identical content for all users, full-page caching (Redis, Varnish, CDN caching) eliminates server processing time entirely — reducing TTFB from 500ms to under 10ms for cached responses.
Fix: Implement full-page caching for static and semi-static content. Cache database query results. Use stale-while-revalidate for near-real-time content.Synchronous blocking external API calls
Server-side code making synchronous HTTP requests to external APIs (payment processors, shipping rate calculators, CRM APIs) in the request path blocks the response until the external API responds. If that API has 400ms TTFB, your TTFB inherits that latency.
Fix: Cache external API responses. Move non-critical API calls to async background jobs. Implement circuit breakers with fallback values for non-essential external data.Geographic distance between user and server
Light travels through fiber at ~200,000 km/s. A request from Sydney to a server in Virginia (15,000 km apart) has a minimum one-way latency of ~75ms, giving a minimum RTT of ~150ms before any server processing begins. Users 10,000+ km from a single-region origin will always have high TTFB due to physics alone.
Fix: Use a CDN with edge caching for static content. Deploy your application to multiple regions (multi-region active-active) for dynamic content close to global users.Connection pool exhaustion under load
When concurrent requests exceed the database connection pool size, new requests queue waiting for a connection to become available. TTFB includes the queue wait time. Under high traffic, a pool of 20 connections handling 100 concurrent requests will add hundreds of milliseconds of queue latency to most requests.
Fix: Increase connection pool size, implement connection pooling via PgBouncer (PostgreSQL) or ProxySQL (MySQL), optimize query execution time to release connections faster.CDN cache miss rate too high
Incorrect Cache-Control headers, highly personalized URLs, query string variations (CDN treats ?v=1 and ?v=2 as separate cache entries), or a cache-busting configuration means most requests bypass the CDN cache and hit the origin. A CDN with a 10% cache hit rate provides almost no TTFB benefit while adding CDN processing overhead to every cache miss.
TTFB vs Page Load Time vs Time to Interactive
TTFB, page load time, and Time to Interactive (TTI) measure different phases of the user experience and require different optimization strategies. Conflating them leads to misdiagnosed performance problems: optimizing images (page load time) does nothing for a server bottleneck causing high TTFB; improving TTFB does nothing for a JavaScript execution bottleneck causing poor TTI.
| Metric | What It Measures | Who Controls It | Primary Fix |
|---|---|---|---|
| TTFB | Time from request dispatch to first response byte. Server processing + network RTT. | Backend engineers, DevOps | Database optimization, server-side caching, CDN, geographic proximity |
| FCP (First Contentful Paint) | Time until the browser renders the first piece of DOM content (text, image, SVG). TTFB + HTML parse + first render. | Frontend + backend | Reduce TTFB, inline critical CSS, eliminate render-blocking resources |
| LCP (Largest Contentful Paint) | Time until the largest visible content element is rendered. Core Web Vitals ranking signal. Directly affected by TTFB. | Frontend + backend + CDN | Reduce TTFB, preload hero images, use CDN for image delivery, reduce resource size |
| Page Load Time | Time until all resources (HTML, CSS, JS, images) have loaded and the load event fires. |
Frontend engineers | Image optimization, lazy loading, code splitting, async resource loading |
| TTI (Time to Interactive) | Time until the page is visually rendered AND responsive to user input (main thread not blocked by JS). | Frontend engineers | Reduce JavaScript bundle size, defer non-critical JS, eliminate long tasks on the main thread |
The relationship between these metrics: TTFB is always first in the chain, and high TTFB degrades all downstream metrics. If TTFB is 2 seconds, FCP cannot be below 2 seconds. LCP cannot be below FCP. TTI cannot be below LCP. This cascading dependency means TTFB optimization has the highest potential impact on Core Web Vitals scores because it compresses the floor of all other timing metrics simultaneously.
How Response Time Affects SEO (Core Web Vitals)
Google officially incorporated Core Web Vitals as a ranking signal in June 2021, making TTFB an indirect ranking factor through its effect on LCP (Largest Contentful Paint). Google does not use raw TTFB as a direct ranking signal — it uses LCP, CLS, and INP (Interaction to Next Paint, replacing FID in March 2024). But because TTFB is the first step in the chain that determines LCP, a high TTFB mechanically degrades LCP scores and can push pages from the “Good” threshold into “Needs Improvement.”
Time until the largest visible content element renders. Directly affected by TTFB: the HTML cannot parse, images cannot preload, and content cannot render until the server responds. A 1-second TTFB virtually guarantees a poor LCP score.
Good: < 2.5s | Needs improvement: 2.5–4s | Poor: > 4sTime from user interaction to next visual update. Primarily a client-side / JavaScript metric. Less directly affected by TTFB, but slow server-side API responses to user actions (form submissions, searches) will increase INP for server-dependent interactions.
Good: < 200ms | Needs improvement: 200–500ms | Poor: > 500msTotal visual instability from unexpected layout shifts during loading. Not directly caused by TTFB. However, delayed server responses that cause late-loading content can trigger layout shifts when elements reflow after async data arrives.
Good: < 0.1 | Needs improvement: 0.1–0.25 | Poor: > 0.25Google measures Core Web Vitals using real-user data from Chrome browsers via the Chrome User Experience Report (CrUX) — not from synthetic lab tests. This means TTFB performance at the p75 (75th percentile) of your actual user traffic determines your Core Web Vitals score, not your best-case performance from a nearby probe location. A site with excellent median TTFB but high TTFB at the p75 (caused by slow database queries under load or by users in distant geographic regions) may have poor Core Web Vitals scores despite looking fast in synthetic tests from the same data center.
Measure your real TTFB: Use the Chrome User Experience Report (CrUX) dashboard at g.co/chromeuxreport or Google Search Console’s Core Web Vitals report to see your actual p75 TTFB from real Chrome users. Synthetic tools like WebPageTest or Lighthouse show lab conditions from specific locations — useful for debugging but not representative of your full user base’s experience.
How to Measure Your TTFB (curl, Chrome DevTools, WebPageTest)
TTFB measurement tools fall into three categories: command-line probes (curl) for raw server measurement, browser DevTools for full connection timing breakdown, and synthetic testing services for geographic comparison. Each provides a different view of the same metric and is useful at a different stage of diagnosis.
The most revealing diagnostic combination: run curl from localhost (or co-located server) to get pure server processing time, then run curl from a distant location to get the full TTFB including network transit. If local TTFB is 50ms but remote TTFB is 600ms, the bottleneck is geographic distance — a CDN will fix it. If local TTFB is already 400ms, the bottleneck is server-side processing — the CDN will help for cached content but not for dynamic responses.
When Does Slow Response Count as Downtime?
Response time crosses the threshold into functional downtime at two distinct points: the monitoring probe timeout and the user abandonment threshold. These thresholds are different numbers with different consequences, and both matter for understanding the real-world impact of high response times on availability metrics and user experience.
Imperceptible — users perceive as instant
Below the human perception threshold for response latency. No user experience impact. Core Web Vitals score: Good. Monitoring probe: always passes.
Noticeable but acceptable
Users are aware of the response time but remain engaged. Google’s “Good” TTFB threshold. Bounce rate increase is statistically negligible in this range for most content types.
Slow — measurable bounce rate impact
Users notice the delay. Google’s research: pages that load in 1–3 seconds have 32% higher bounce probability than sub-1-second pages. Core Web Vitals: Needs Improvement. Monitoring probe: passes if overall request completes within timeout.
Severely degraded — most users have abandoned
Google: 53% of mobile users abandon pages that take over 3 seconds to load. Revenue impact is measurable. Functionally equivalent to downtime for conversion-dependent pages. Core Web Vitals: Poor. Monitoring probe still passes if request eventually completes within 10s.
Probe timeout — counted as downtime
DownCheck’s 10-second timeout fires. The probe records a failure. The result counts as downtime in the uptime percentage calculation. Users abandoned the page several seconds earlier. This is the threshold where “slow” officially becomes “down” in monitoring systems — though the functional downtime for users began at 3–5 seconds.
The monitoring gap: A server responding in 8 seconds is counted as “up” by a 10-second timeout monitor, but has a 53%+ user abandonment rate and near-zero conversion rate. Uptime monitoring alone misses this “functional downtime” zone between 3s and 10s. Supplement probe-based uptime monitoring with response time alerting — alert when p95 response time exceeds 3 seconds, not just when probes time out at 10 seconds. See the monitoring guide for alert configuration.
How DownCheck Measures and Reports Response Time
DownCheck records the response time of every HTTP probe as the elapsed time from request dispatch to receipt of a valid HTTP response, capturing latency from the probe infrastructure’s perspective — the equivalent of a user request from that geographic location. Response time is recorded for every probe whether the probe passes or fails, enabling trend analysis of response time degradation before it crosses the timeout threshold into recorded downtime.
Probe Timeout
Any HTTP probe taking longer than 10 seconds is recorded as a failed probe and counts as downtime. This is the threshold at which slow officially becomes down in DownCheck’s uptime calculation. The 10-second threshold aligns with browser default timeout behavior and matches most industry-standard monitoring tool defaults.
Response Time Recorded
For successful probes (HTTP 200–399 within 10s), DownCheck records the exact response time in milliseconds. This enables historical trending: a service that was responding in 200ms last week but 800ms today is degrading and should be investigated before it crosses into downtime territory.
Independent Probes
Response times are captured independently by the Railway HTTP probe, Cloudflare Edge probe, and DNS multi-resolver check. Comparing Railway response time (US origin-pull) against CF Edge response time (nearest CDN PoP) immediately reveals whether high latency is in the CDN-to-origin leg or at the origin itself.
Services Tracked
DownCheck tracks response times for 55+ major services including AWS, Cloudflare, GitHub, Stripe, and Shopify at 5-minute intervals, building a historical baseline of normal response times. When a service’s response time exceeds its baseline significantly, it signals degradation ahead of a full outage.
The practical use of DownCheck’s response time data: when your continuous monitor fires an alert, run a DownCheck probe immediately. If the Railway probe returns in 8,500ms (near-timeout) while the CF Edge probe returns in 150ms, your CDN is serving cached content at normal speed but your origin is severely degraded — users on cache misses are experiencing near-downtime latency while cached users are fine. This is a partial degradation scenario invisible to single-probe monitors but clearly visible in DownCheck’s probe comparison. Pair with uptime percentage tracking to quantify how much degraded response time is costing you in real availability terms.
Frequently Asked Questions
Check response time right now
DownCheck measures response time via HTTP probe and 4-resolver DNS consensus simultaneously — immediately showing whether slowness is at your CDN edge or at your origin.
Measure a site →