What Is Server Response Time (TTFB)? Complete Guide (2026)
Hi, I'm Saar - a software engineer, SEO specialist, and lecturer who loves building tools and teaching tech.
View author profile →What Is Server Response Time?
Server Response Time — formally known as Time to First Byte (TTFB) — is the duration between the browser sending a request for a page and receiving the very first byte of HTML in response. Every other performance metric depends on it: nothing the browser does (paint, parse, render) can begin until the server has delivered something to work with.
Key Facts (TL;DR)
- Good TTFB: ≤ 800 ms at the 75th percentile of real-user requests — Google's recommended threshold.
- Needs Improvement: 800 – 1,800 ms — the page-load chain begins late; FCP and LCP suffer proportionally.
- Poor: > 1,800 ms — users see a blank screen long enough to abandon before content even arrives.
- Not in performance score, but gates everything in it. TTFB doesn't have its own weight, but every metric in the score (FCP, LCP, Speed Index, TBT) starts after TTFB completes.
- Composite measurement: TTFB includes redirect time, DNS lookup, TCP connection, TLS handshake, request, and server processing — all before the first byte arrives.
- Field metric available: Unlike most lab metrics, TTFB is reported in real-user data via the Chrome User Experience Report (CrUX) and Google Search Console.
- Business impact: Industry analysis consistently shows pages with TTFB < 200 ms have ~30% lower bounce rates than pages with TTFB > 1,000 ms, even when all other metrics are held constant.
Think of TTFB the way you think of restaurant service. The kitchen can't cook before the order arrives, the waiter can't deliver before the kitchen plates it, and you can't eat before the waiter walks. TTFB is the moment the order finally hits the kitchen — and every minute of delay there shifts the whole evening.
Why TTFB Matters for Every Other Metric
- It gates the entire load.If TTFB is 1,500 ms, the absolute earliest possible FCP is > 1,500 ms. No amount of front-end optimization can compensate.
- It affects every visitor on every page. Frontend optimizations like image lazy-loading help only some visitors on some pages. TTFB optimizations help every request on every page, every time.
- Direct ranking impact via LCP. Largest Contentful Paint is a confirmed Google ranking signal, and LCP is bounded below by TTFB. A 1,200 ms TTFB makes a passing LCP nearly impossible on a content-heavy page.
- Reflected in real-user data.Unlike most lab metrics, TTFB is measurable in the field and surfaces directly in Google Search Console's Core Web Vitals report when pages fail.
- AI search visibility. Slow servers also affect crawl budgets. AI search systems re-crawl pages less frequently when origin response is slow, which means stale content shows up in generative results.
- Conversion correlation. Cross-industry data consistently shows TTFB improvements compound — every 100 ms shaved typically adds 1–2% to conversion.
What Happens Inside TTFB
TTFB isn't a single thing. It's the sum of every step between the user clicking a link and the first byte of HTML arriving:
- Redirect time — if the URL redirects (HTTP → HTTPS, www → apex, trailing-slash normalization), each redirect adds a full round-trip.
- DNS lookup — translating the domain to an IP address (typically 20–120 ms for cold lookups).
- TCP connection — opening a connection to the server (1 RTT).
- TLS handshake — establishing HTTPS encryption (1–2 RTTs depending on TLS version).
- Request sent — browser transmits the HTTP request.
- Server processing — your application generates the HTML response (often the dominant component for dynamic apps).
- First byte received — TTFB ends here.
Example TTFB breakdown for a slow request:
Redirect (HTTP → HTTPS): 180 ms
DNS lookup: 50 ms
TCP connection: 80 ms
TLS handshake: 120 ms
Server processing (uncached): 900 ms
─────────────────────────────────────
TTFB total: 1,330 ms (poor)Server Processing Is Usually the Big One
For static sites and well-cached dynamic sites, the network steps (DNS, TCP, TLS) typically add up to 200–300 ms. The remaining TTFB is server processing — and that's where database queries, application logic, and rendering live. For most slow sites, server processing is 70–90% of total TTFB, which means it's where your optimization effort belongs.
How to Check Your TTFB
- Greadme's deep scan — surfaces TTFB alongside every other Web Vital, breaks it down into network and server-processing components, and pairs each issue with an AI-generated fix or one-click GitHub PR. Recommended starting point.
- Greadme's crawler scan — measures TTFB across every indexable page on your site so you can identify which routes (or templates) are slowest at the origin.
- Google Search Console → Core Web Vitals report — TTFB issues surface here when they pull LCP into the "poor" bucket. Filter for slow LCP and check whether server response is the cause.
- Chrome DevTools → Network tab — open the page, check the "Timing" panel for the document request. The "Waiting (TTFB)" row shows the exact server-processing portion.
- web.dev articles — Google's reference docs on TTFB, edge caching, and HTTP/2/3 are the primary sources for the techniques in this guide.
10 Proven Ways to Improve TTFB
1. Cache HTML at the Edge
The fastest server response is no server response. CDN edge caching serves your HTML from a node geographically close to the user — TTFB typically drops from 800–1,500 ms to under 100 ms.
Fix: Configure your CDN to cache full HTML responses for content that doesn't change per-user. For pages that do vary per user, cache fragments and assemble at the edge.
2. Eliminate Redirect Chains
Each redirect adds a full round-trip. http://example.com/page → https://example.com/page → https://www.example.com/page → https://www.example.com/page/ can easily add 400+ ms before the real request is even processed.
Fix:Audit redirects with a tool like Ahrefs or your CDN's logs. Update internal links and canonicals to point directly to the final URL. Set redirects at the CDN edge, not the origin.
3. Cache Database Queries
For dynamic sites, database queries are usually the slowest step in server processing. A 200 ms uncached query repeated on every request is a 200 ms TTFB tax.
Fix: Cache query results in Redis or Memcached. For read-heavy traffic, even a 30-second cache can cut origin TTFB by 80%. For per-user data, use short-TTL caches keyed on user ID.
4. Use HTTP/2 or HTTP/3
HTTP/3 (over QUIC) eliminates the TCP handshake and combines connection setup with TLS — saving 1–2 round-trips on the first request. For repeat visitors, HTTP/2 connection coalescing avoids reopening connections per resource.
Fix: Enable HTTP/2 on your origin and HTTP/3 at the CDN edge. Most modern CDNs support both with a single toggle.
5. Move to Edge Rendering or Static Generation
Server-rendering at a single regional origin pays distance latency for every visitor. Edge rendering platforms run the same code at locations near every user.
Fix: For content-heavy pages (blog, marketing, docs), prefer Static Site Generation. For dynamic pages, move rendering to the edge where possible. SSR at a single origin should be the last choice, not the first.
6. Audit Synchronous External API Calls
If your server makes a blocking API call to a third-party service before responding, your TTFB includes their entire response time. A 600 ms call to a recommendation engine = 600 ms added to your TTFB.
Fix: Move non-critical API calls client-side (after page load), or call them in parallel with a strict timeout (e.g. Promise.race([apiCall, timeout(200)])). Cache API responses aggressively.
7. Use Connection Keep-Alive and HTTP/2 Push Sparingly
Keep-alive lets the browser reuse the TCP+TLS connection across requests, eliminating handshake overhead on every subsequent fetch. Properly configured, it can save 200+ ms per resource for cold visitors.
Fix: Ensure Connection: keep-alive is set on origin responses. Use HTTP/2 server push only for resources guaranteed to be needed; misused push wastes bandwidth.
8. Compress Responses
Brotli or gzip compression on HTML can shrink the payload by 70–80%. Smaller payload = fewer round-trips to deliver. Most CDNs and modern servers enable this with a single setting.
Fix: Verify Brotli (preferred) or gzip is enabled at the edge. Compress JSON responses too.
9. Choose Hosting Geographically Close to Your Users
If 80% of your traffic is in Europe and your origin is in us-east-1, every visitor pays 80–120 ms of distance latency on every request. Pick a region that matches your audience — or, better, use multi-region edge deployment.
10. Set Performance Budgets and Monitor in CI
The cheapest TTFB regression is the one that gets caught at deploy time. Track p75 TTFB in CI and fail the build if it regresses more than your budget allows.
Fix:Add a synthetic test to your CI pipeline that hits a representative URL and asserts TTFB < 800 ms. Alert on real-user TTFB regressions in production via your APM.
Common TTFB Problems and Fixes
Problem: Shared Hosting With Noisy Neighbors
What's happening: Your site is on a shared server with hundreds of others, and a traffic spike on one of them starves yours of CPU.
Fix: Upgrade to managed/cloud hosting with dedicated resources, or front the origin with edge caching so the noisy neighbor problem rarely matters.
Problem: Uncached Database Queries on Every Page
What's happening: Each page load runs the same expensive queries (e.g. fetching navigation, sidebar widgets, related-posts lists) and those queries take 200–400 ms each.
Fix: Cache the query results in Redis with a sensible TTL (5–60 minutes for navigation; 24h for long-tail content). Even uncached queries should be heavily indexed.
Problem: Origin Located Far From Users
What's happening: Your origin is in one region, but your audience is global. Every visitor pays 200–500 ms of physical distance latency.
Fix: Front the origin with a CDN that has edge nodes in your audience's regions. For dynamic content, move rendering to the edge.
Problem: Long Redirect Chain
What's happening: The original URL redirects through 2–4 intermediate URLs before landing on the canonical version, each costing a round-trip.
Fix: Update internal links and canonical tags to point directly at the final URL. Configure redirects at the CDN edge, not the origin. Avoid redirect loops by monitoring with Ahrefs, Semrush, or Google Search Console's URL Inspection tool.
How TTFB Affects Other Performance Metrics
| Metric | Good Threshold | How TTFB Affects It |
|---|---|---|
| First Contentful Paint (FCP) | ≤ 1.8 s | Bounded below by TTFB; FCP can never be faster than TTFB + parse time. |
| Largest Contentful Paint (LCP) | ≤ 2.5 s | TTFB is the first ~30–40% of LCP for most pages — and LCP is a Core Web Vital ranking signal. |
| Speed Index | ≤ 3.4 s | Visual progress can't begin until HTML arrives. Slow TTFB pushes the whole curve right. |
| Time to Interactive (TTI) | ≤ 3.8 s | JavaScript can't start parsing until HTML is delivered, so TTI shifts proportionally with TTFB. |
| Cumulative Layout Shift (CLS) | ≤ 0.1 | Indirect — slow TTFB delays font and image loads, which can produce shifts. |
Bottom line: If TTFB is over 800 ms, no amount of front-end optimization will rescue your Core Web Vitals. Fix TTFB first.
FAQ
What is a good TTFB score?
Google's recommended threshold is 800 ms or lessat the 75th percentile of real-user requests. Between 800 ms and 1,800 ms "needs improvement," and over 1,800 ms is poor. For best-in-class sites, TTFB under 200 ms is achievable with edge caching.
Is TTFB a Core Web Vital?
No. The three Core Web Vitals are LCP, INP, and CLS. TTFB is a foundational metric that affects all of them, but it's not itself a ranking signal. That said — Google reports TTFB in the Search Console Core Web Vitals report when it pulls LCP into the "poor" bucket, so practically speaking, slow TTFB still hurts SEO.
Why does Google measure TTFB at the 75th percentile?
Because real-user TTFB varies wildly by location, network, and device. Measuring at p75 means "75% of your users get this experience or better" — a stricter and more realistic bar than median or average.
What's the difference between TTFB and Server Response Time?
They're the same metric, just two names. The web.dev community standardized on TTFB; older audit tools historically called it "Server Response Time." Both refer to the time from request initiation to first byte received.
Will a CDN always improve TTFB?
Almost always — if it caches HTML at the edge. A CDN that only caches static assets (images, CSS, JS) won't help TTFB much because the HTML still comes from the origin. Edge caching of HTML is what produces the dramatic 800 ms → 80 ms improvements.
How do I improve TTFB on a server-rendered React/Next.js app?
Three main levers: (1) move static-shape pages to generateStaticParams+ ISR for fully cached HTML, (2) cache data fetches at the page level so repeated visitors hit a hot cache, and (3) deploy to Edge runtime for routes that genuinely need server logic but don't need a long-running Node environment.
Does TTFB affect AI search engines like ChatGPT and Perplexity?
Indirectly. Slow servers reduce crawl frequency for both Googlebot and AI crawlers. Stale content gets surfaced in generative results, and AI systems preferentially cite well-ranked pages — both of which are hurt by slow TTFB.
Conclusion
TTFB is the foundation of every other performance metric. No amount of image optimization, code splitting, or critical-CSS work can rescue a page that takes 1,500 ms to deliver its first byte. Hit the ≤ 800 ms threshold by attacking three things in order: cache HTML at the edge, cache database queries, and eliminate unnecessary redirect chains. Most sites that fix those three see TTFB drop by 60–80% with no other changes.
Run a Greadme deep scan to see your TTFB, identify whether the problem is network or server processing, and get a prioritized fix list.