Start here
Before You Fix It: What This Check Means
Server response time (TTFB) is upstream latency that cascades into all downstream milestones. In plain terms, this tells you whether users are likely to feel this page as fast, stable, and usable. Scavo reads `ttfb` when available (or falls back to load-time signal if needed) and applies thresholds.
Why this matters in practice: degraded speed here often compounds into lower conversion and weaker user trust.
How to use this result: treat this as directional evidence, not final truth. Synthetic sampling may not fully match real-user device/network variability. First, confirm the issue in live output: verify directly in live production output with browser/network tools Then ship one controlled change: Profile backend response path and eliminate slow blocking calls. Finally, re-scan the same URL to confirm the result improves.
TL;DR: Your server takes too long to respond to the first request, delaying everything else on the page.
Google recommends a TTFB of 0.8 seconds or less, with 200ms as the ideal target (Seobility/Google). An analysis of 143,827 URLs found that TTFB was the strongest speed-related correlation with rankings (Neil Patel). TTFB is the foundation — no amount of frontend optimisation can overcome a slow server. Common causes: unoptimised database queries, no page caching, or inadequate hosting.
What Scavo checks (plain English)
Scavo reads ttfb when available (or falls back to load-time signal if needed) and applies thresholds:
- Pass:
< 200ms(excellent) - Pass:
< 600ms(good) - Warning:
>= 600msand< 1000ms - Fail:
>= 1000ms - Info: timing unavailable
How Scavo scores this check
Scavo assigns one result state for this check on the tested page:
- Pass: baseline signals for this check were found.
- Warning: partial coverage or risk signals were found and should be reviewed.
- Fail: required signals were missing or risky behavior was confirmed.
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
In your scan report, this appears under What failed / What needs attention / What is working for server_response_time, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
server_response_time - Category:
PERFORMANCE
Why fixing this matters
High TTFB slows first paint, increases bounce risk, and often indicates backend/cache bottlenecks. Even strong frontend optimization cannot fully mask a slow server start.
TTFB is also a useful operations signal: regressions often correlate with deployment, database, or cache-path changes.
Common reasons this check flags
- Slow origin compute/query path.
- Cache misses or weak edge caching.
- Geographic distance and network path inefficiency.
- Saturated infrastructure or misconfigured keep-alive/TLS settings.
If you are not technical
- Ask for TTFB trend by key pages, not one sample.
- Prioritize highest-traffic URLs first.
- Require root-cause split: backend, cache, network.
- Re-run Scavo after fixes and track stability over time.
Technical handoff message
Copy and share this with your developer.
Scavo flagged Server First Byte (TTFB) (server_response_time). Please investigate backend/cache/network causes of elevated first-byte latency, apply the smallest safe fix, and share before/after TTFB evidence.If you are technical
- Profile backend response path and eliminate slow blocking calls.
- Increase cache hit rates (edge + application caching).
- Tune DB queries and connection pooling.
- Reduce redirect/auth overhead on public pages.
- Monitor p50/p95 TTFB in production observability stack.
How to verify
- Measure TTFB in browser/network tooling and server traces.
- Compare values across regions/devices where possible.
- Validate improvements persist over multiple scans.
- Re-run Scavo and confirm threshold class improves.
What this scan cannot confirm
- It does not identify exact backend line-level bottlenecks.
- It does not reflect full-page interactivity by itself.
- One fast sample does not guarantee sustained stability.
Owner checklist
- [ ] Assign owner for first-byte latency SLOs.
- [ ] Track p50/p95 TTFB continuously.
- [ ] Alert on sustained regression windows.
- [ ] Revalidate after infra/database/cache changes.
FAQ
Is 600ms always too slow?
This check treats sub-600ms as good. Context matters, but consistent low latency is the target direction.
Why does this use fallback timing sometimes?
If direct TTFB is missing, Scavo uses available timing signals to avoid losing observability.
Can CDN fully solve high TTFB?
It helps for cacheable content, but dynamic/backend bottlenecks still require origin fixes.
What should we fix first?
Cache strategy and backend hot paths on top-converting routes.
Sources
- web.dev: Optimize TTFB
- MDN: PerformanceNavigationTiming
- Google Lighthouse: Server response time diagnostics
Need a TTFB triage template that maps findings to backend/cache/network owners? Send support your current timing breakdown.
