Your homepage feels slow. Lighthouse gives you a 64. Users complain that pages take "forever" to load. But your CDN dashboard says cache hit ratio is 99%. Your application logs say responses are returning in under 200ms.
Where's the missing time?
Almost always: it's in TTFB — Time To First Byte. The seconds between the browser saying "give me this page" and the server actually starting to send a response. TTFB is invisible to most monitoring setups because it sits at the boundary between your network, your CDN, your reverse proxy, and your application — and gets blamed on whichever layer the operator is least familiar with.
This guide covers what TTFB actually measures, how to monitor it, what causes it to spike, and how to fix the most common slow-TTFB problems.
What TTFB Actually Measures
TTFB is the time from when the browser sends an HTTP request to when it receives the first byte of the response. It's a single number that bundles together a lot of distinct work:
- DNS lookup — Resolving your domain to an IP
- TCP connection — Three-way handshake to your server or edge node
- TLS handshake — Setting up the secure connection (typically 1–2 round trips)
- Server processing — The time your application spends building the response
- Network latency — Each round trip's distance contribution
If you only look at TTFB, you can't tell which of those is the culprit. But TTFB is the single most useful "is the server side healthy?" metric, because if any of those layers is broken, TTFB will be the first to show it.
Google considers TTFB a real user experience signal and uses it as a Core Web Vitals input. Sub-200ms TTFB is the rough target for fast sites; anything over 800ms is generally considered slow.
Why TTFB Matters
Real user experience
Every visitor experiences TTFB before they see anything. A 2-second TTFB means the browser stares at a blank tab for two seconds before it can even start rendering. No optimization to your CSS, JavaScript, or images can fix that.
SEO
Google has stated that TTFB is part of the page experience signal. High TTFB hurts rankings indirectly through worse Core Web Vitals (LCP, in particular, depends heavily on TTFB) and directly through Google's documented preference for fast sites.
Conversion rate
Multiple studies have shown that every additional 100ms of page load time costs measurable conversion. TTFB is the part you can usually fix the fastest because it's almost entirely server-side.
The first signal of trouble
Application slowdowns almost always show up in TTFB before they show up in error rates. A growing TTFB graph is your earliest warning that something is wrong — a slow database query, a memory leak, a noisy neighbor on your hosting.
What to Monitor
1) TTFB on Key Pages
Not every page is equal. Monitor the ones that matter most:
- Homepage — Your first impression
- Top organic landing pages — The pages Google sends traffic to
- Pricing / signup / checkout — Pages tied directly to revenue
- API endpoints — The TTFB equivalent for APIs is response time, but the diagnostic is the same
2) TTFB by Region
A Frankfurt user and a São Paulo user have completely different TTFB experiences. Monitor from multiple regions:
- Each region you serve customers in — At minimum North America, Europe, and one of Asia/South America/Oceania
- Both nearest and farthest — Compare to detect when geographic latency is the dominant factor
- Cache vs. origin — If you use a CDN, monitor both edge-cached pages and origin-only paths
See Multi-Region Monitoring: Why Location Matters for the full case.
3) TTFB on Cached vs. Uncached Responses
A 50ms TTFB on a cached HTML page tells you the CDN is healthy. A 1.5-second TTFB on an uncached dynamic page tells you the origin is slow.
- Cached pages — Should be 20–100ms via a CDN
- Cache-bypass requests — Add a cache-buster query param to force origin; this is your "real" backend TTFB
- Authenticated / personalized pages — Always uncached; these reveal actual application performance
4) p50, p95, and p99 — Not Just Average
Average TTFB hides outliers. The user with a 4-second TTFB is the user who churns.
- p50 — Most common experience
- p95 — Slowest 1 in 20 requests; the threshold above which user complaints multiply
- p99 — Worst-case experience; tells you about garbage collection pauses, connection pool exhaustion, etc.
Alert on p95 regressions, not just averages.
5) Trend, Not Just Threshold
A static TTFB threshold catches outages, but slow degradation is harder to catch. Watch:
- Week-over-week trend — Is TTFB drifting up?
- Post-deploy comparison — Did the deploy 30 minutes ago cause a 30% TTFB increase?
- Time-of-day patterns — TTFB spike at 9 AM ET? You're under-provisioned for peak
Common Causes of High TTFB
| Cause | Where to Look | Typical Fix |
|---|---|---|
| Slow database query | DB slow query log, ORM logs | Add an index, denormalize, or cache |
| N+1 queries in the request handler | Application profiling | Eager-load relations, use a query batcher |
| Cold serverless function | Lambda / Cloud Run logs | Provisioned concurrency, lighter runtime |
| TLS handshake on every request | TLS metrics, connection logs | Enable session resumption, HTTP/2 / HTTP/3 |
| Far-away origin without CDN | Geographic latency tests | Put a CDN in front, or move origin closer |
| CPU-bound application | Process CPU metrics | Profile and optimize hot paths, or scale up |
| Memory exhaustion / GC pauses | Heap usage, GC logs | Tune GC, fix leaks, increase memory |
| Misconfigured connection pool | DB connection metrics | Resize pool, fix connection leaks |
| Synchronous third-party API call | Application traces | Move to async, cache the response |
| Template rendering on every request | Application profiling | Cache rendered HTML or fragments |
| Slow DNS | DNS resolution timing | Switch DNS providers, use a CDN's DNS |
| TCP slow start on large pages | Network captures | HTTP/2 / HTTP/3, smaller initial payload |
How to Diagnose Slow TTFB
When TTFB monitoring fires, walk through this triage in order:
1. Is it the network or the server?
Compare TTFB across regions. If TTFB is high everywhere equally, it's the server. If it varies dramatically by region, the network or DNS is involved.
2. Is it a cache miss?
Hit the page with a cache-buster query string. If TTFB jumps from 80ms to 1500ms, you're seeing your origin's true performance — and your cache is doing its job.
3. Is it the application or what's behind it?
Most application monitoring (APM) tools break down TTFB into:
- Time spent in the framework / router
- Time spent in database queries
- Time spent in external HTTP calls
- Time spent in template rendering
Identify which dominant chunk is responsible. If you don't have APM, add basic timing instrumentation around your slow handlers.
4. Did something change recently?
Almost every TTFB regression is caused by a recent change:
- A deploy that introduced an N+1 query
- A traffic increase that exceeded a connection pool's capacity
- A schema migration that invalidated a cache
- A new third-party integration on a hot path
- An auto-scaling policy that didn't trigger
Post-deploy validation catches the deploy-related ones.
How to Fix the Most Common TTFB Problems
Cache aggressively
Most HTML and API responses can be cached for at least a few seconds. Even 10-second caching dramatically reduces origin load.
- HTML pages: cache at the CDN with short TTLs and stale-while-revalidate
- API responses: cache by query parameters with appropriate Vary headers
- Personalization: serve a generic cached version with personalization filled in client-side
Move closer to users
A CDN with edge nodes around the world cuts the network portion of TTFB to single-digit milliseconds for cached responses. Even for uncached responses, edge proxies can reuse warm TLS connections to your origin.
Optimize the slow path
Identify your top 3 slowest endpoints by TTFB and profile them. The fixes are usually straightforward once you can see where the time goes:
- Add an index to the slow query
- Cache the third-party API response
- Defer non-essential work to a background job
- Pre-render or pre-compute static portions
Right-size your infrastructure
If TTFB is high and CPU is pinned, you're under-provisioned. Scale horizontally before scaling vertically — more instances are usually cheaper than bigger instances, and they handle traffic spikes better.
Use HTTP/2 or HTTP/3
Both reduce the round trips required for TLS and request multiplexing. The benefit is most visible on first-byte time for second and subsequent requests on a connection.
TTFB vs. Other Performance Metrics
| Metric | What It Measures | When TTFB Is the Cause |
|---|---|---|
| LCP (Largest Contentful Paint) | When the largest visible element renders | Always — TTFB is the floor for LCP |
| FCP (First Contentful Paint) | When the first text or image appears | Always — TTFB is the floor for FCP |
| INP (Interaction to Next Paint) | Responsiveness to user input | Rarely — INP is mostly client-side |
| Total Page Load | When the page is fully loaded | Partially — TTFB is one component |
| Response time (API) | Same as TTFB for APIs | Always — TTFB is response time for non-streaming responses |
If you're trying to improve LCP and your TTFB is over 600ms, fixing TTFB is almost always the highest-leverage change you can make.
How Webalert Helps
Webalert tracks response time (TTFB) on every check and alerts on regressions:
- Multi-region checks — TTFB measured from regions worldwide so you see what real users experience
- p50 / p95 response time alerts — Catch slowdowns that average-based monitoring misses
- Content validation — Combine TTFB with content checks so you know the slow response is also correct
- Response time history — Spot week-over-week regressions before they become outages
- SSL monitoring — Catch TLS handshake issues that inflate TTFB
- Multi-channel alerts — Email, SMS, Slack, Discord, Microsoft Teams, webhooks
- 5-minute setup — Add a check for any URL and start tracking TTFB immediately
See features and pricing for details.
Summary
- TTFB is the time from request to first response byte — a bundle of DNS, TCP, TLS, and server processing.
- High TTFB hurts user experience, conversion, and SEO (it's a Core Web Vitals input).
- Monitor TTFB by region, by cached/uncached response, and at p95/p99 — not just averages.
- The most common culprits are slow database queries, N+1 patterns, missing caches, and far-away origins.
- Use post-deploy comparison to catch regressions immediately.
- Fix in this order: cache aggressively, move closer to users, optimize hot paths, right-size infrastructure.
If your site feels slow, it's probably TTFB. Monitor it, and you can fix it.