What Is Time to First Byte (TTFB) and Why Does It Matter for Uptime?

Time to First Byte (TTFB) is the time between a browser (or monitoring tool) sending an HTTP request and receiving the first byte of the response from the server. It's one of the most fundamental web performance metrics — and it's directly connected to uptime monitoring.

What TTFB Measures

TTFB captures the full round-trip of a request:

1. DNS lookup time — resolving your domain name to an IP address
2. TCP connection time — establishing the network connection
3. TLS handshake time (for HTTPS) — negotiating the SSL/TLS encryption
4. Server processing time — the server receiving the request, processing it, and beginning to send the response

The sum of these is TTFB. A low TTFB means the server responded quickly. A high TTFB means something in that chain is slow.

What Is a Good TTFB?

General benchmarks:

TTFB	Rating
< 200ms	Excellent
200–500ms	Good
500ms–1s	Needs improvement
1–2s	Poor
> 2s	Very poor

Google's Core Web Vitals guidelines recommend targeting TTFB under 800ms. For the TTFB check specifically used in Largest Contentful Paint (LCP) calculations, under 200ms is ideal.

TTFB vs. Total Page Load Time

TTFB is just the first byte. Total page load time includes:

• Downloading the HTML document
• Parsing the HTML and discovering additional resources
• Downloading CSS, JavaScript, images, and fonts
• Executing JavaScript

TTFB is the starting gun — if it's slow, everything that follows is also delayed. Improving TTFB has a multiplicative effect on overall page load time.

What Causes High TTFB?

Server Processing Time

The most common cause of high TTFB is slow server-side processing — often due to:

• Slow database queries — especially N+1 problems or missing indexes
• Missing or cold cache — uncached pages that require full computation on every request
• Heavy application logic — complex operations running synchronously on every request
• Resource contention — the server is handling too many concurrent requests
• Slow external API calls — synchronous calls to third-party services before the response is sent

Network Factors

• Geographic distance — a user in Australia connecting to a server in the US has significant round-trip latency built in
• CDN issues — if your CDN cache is bypassed or misconfigured, requests go back to the origin server
• Slow DNS — DNS resolution adds to TTFB; use a fast, well-connected DNS provider

Infrastructure Factors

• Under-provisioned server — too little CPU, RAM, or I/O for the load
• Cold dynos/containers — on platforms like Heroku, a "sleeping" dyno has a significant startup delay before TTFB
• TLS/SSL overhead — older TLS configurations have higher handshake times; TLS 1.3 significantly reduces this

TTFB and Uptime Monitoring

Every uptime monitoring check measures response time alongside availability status. When your TTFB spikes, it shows up in your monitoring data as:

• Increased response times — even when the check passes (200 OK)
• Timeout failures — if TTFB exceeds your monitoring timeout (typically 10-30 seconds), the check fails

This means TTFB is directly related to uptime monitoring results. A server that's overwhelmed and taking 25 seconds to respond will show as "down" to your monitoring tool — even though technically it's responding.

Response Time Thresholds

Good monitoring tools let you set response time thresholds that trigger warnings:

• Warning: respond in > 2 seconds
• Critical: respond in > 5 seconds

These catch performance degradation before it becomes outright failure — giving you time to investigate and fix the issue before TTFB climbs high enough to cause actual timeouts.

Improving TTFB

Implement Caching

The single highest-impact TTFB improvement for most sites is aggressive caching:

• Full-page caching — serve static HTML for pages that don't require dynamic computation
• Database query caching — cache frequent, expensive queries in Redis or Memcached
• CDN caching — serve cached responses from edge nodes close to users

Optimise Database Queries

Slow queries are a common TTFB killer. Tools like EXPLAIN ANALYZE in PostgreSQL and MySQL's slow query log help identify problematic queries. Adding indexes to frequently-filtered columns can reduce query time from seconds to milliseconds.

Upgrade to HTTP/2 and TLS 1.3

HTTP/2 multiplexing reduces connection overhead. TLS 1.3 reduces handshake round trips from 2 to 1. Both contribute to lower TTFB, especially for users on higher-latency connections.

Move Your Server Closer to Users

If your users are in Europe and your server is in the US, you're adding ~100ms of baseline latency to every TTFB. A CDN with edge caching, or a server in the same region as your primary users, makes a significant difference.

Monitoring TTFB Over Time

Track TTFB trends in your monitoring dashboard. Gradual increases over weeks often indicate:

• Database growing without proportional indexing improvements
• Accumulated technical debt in hot code paths
• Memory leaks causing garbage collection pauses
• Slowly degrading external API dependencies

Catching these trends early prevents performance degradation from reaching the point of actual downtime.

Domain Monitor records response times for every uptime check, giving you a historical view of your TTFB trends alongside availability data.

---

Track response times alongside uptime at Domain Monitor.

Related Articles

• "What Are Core Web Vitals and How Do They Relate to Monitoring?"
• "What Is Network Latency and How Does It Affect Website Performance?"
• "Monitoring Next.js Applications: A Practical Uptime and Performance Guide"