Google recommends keeping TTFB at or below 800 ms, with under 200 ms considered fast. The figure includes connection setup, network latency, and server processing, so the right target depends on how far visitors are from your server and how much work each request does.

Is TTFB a Core Web Vitals metric?

No. TTFB is not one of the three Core Web Vitals (LCP, INP, and CLS), but it is a diagnostic that directly feeds LCP. Since the browser cannot start rendering the largest element until the first byte arrives, a high TTFB raises the floor for LCP, whose good threshold is 2.5 seconds or less at the 75th percentile.

What is the difference between TTFB and latency?

Latency usually refers to the network round-trip time between client and server. TTFB includes that network latency but adds connection setup (DNS, TCP, TLS) and the server's own processing time, so TTFB is always at least as large as raw network latency and reflects more of the request path.

How do you reduce TTFB?

Cache responses so the server does less work, serve content from a CDN or edge location closer to users to cut network latency, optimize slow database queries and application code, and remove unnecessary redirects, since each redirect adds a full round trip before the real response can begin.

What Is TTFB (Time to First Byte)?

Reviewed by Ionut Caval · Updated June 2026

TTFB (Time to First Byte) is the time between a browser sending an HTTP request and the first byte of the server's response arriving. It measures server and network responsiveness, and because rendering cannot begin until it completes, it is the foundation of LCP (Largest Contentful Paint).

TTFB measures how quickly a server starts replying. The browser opens a connection, sends an HTTP request, and TTFB is the elapsed time until the first byte of the response arrives. That single number folds together several stages: DNS lookup, the TCP and TLS handshakes, the time the request spends in transit, the server's own processing (application code, database queries, template rendering), and the network trip back. Because it captures everything up to the response starting, TTFB is the clearest signal of back-end and network responsiveness, separate from how long the page then takes to render.

What counts as a good TTFB

Google suggests keeping TTFB at or below 800 ms for most sites, with under 200 ms considered fast. TTFB is not itself a Core Web Vitals metric, but it is the foundation of one: LCP (Largest Contentful Paint). LCP has a "good" threshold of 2.5 seconds or less at the 75th percentile, and every millisecond of TTFB is spent before the browser can even begin downloading and painting that largest element. A slow server therefore puts a hard floor under LCP no matter how well the front end is optimized.

The main contributors to TTFB are worth separating, because they are fixed in different ways:

Connection setup: DNS resolution plus the TCP and TLS handshakes, paid once per new connection.
Network latency: the round-trip distance between the visitor and the server, which a CDN or edge caching shortens.
Server processing: application logic, database queries, and rendering, the part most under your control.
Redirects: each extra hop adds a full round trip before the real response can start.

How TTFB is measured and reduced

TTFB shows up in two places. In the field, real user monitoring reads it from the browser's PerformanceNavigationTiming API across genuine visitor sessions, capturing the real spread of devices and networks. In the lab, synthetic monitoring records it on every scheduled uptime check, so a creeping server slowdown surfaces before users complain. The two views answer different questions, as covered in synthetic monitoring vs real user monitoring. Common fixes include caching responses, serving from a CDN closer to users, tuning slow database queries, and removing redundant redirects. Because TTFB sits on the path of every request, watching it alongside uptime turns a vague "the site feels slow" into a measured number you can act on. Pulsetic's uptime and API monitoring records response timing on each check from multiple regions, so a regional latency spike is not mistaken for a server problem.

Frequently asked questions

What is a good TTFB?

Google recommends keeping TTFB at or below 800 ms, with under 200 ms considered fast. The figure includes connection setup, network latency, and server processing, so the right target depends on how far visitors are from your server and how much work each request does.
Is TTFB a Core Web Vitals metric?

No. TTFB is not one of the three Core Web Vitals (LCP, INP, and CLS), but it is a diagnostic that directly feeds LCP. Since the browser cannot start rendering the largest element until the first byte arrives, a high TTFB raises the floor for LCP, whose good threshold is 2.5 seconds or less at the 75th percentile.
What is the difference between TTFB and latency?

Latency usually refers to the network round-trip time between client and server. TTFB includes that network latency but adds connection setup (DNS, TCP, TLS) and the server's own processing time, so TTFB is always at least as large as raw network latency and reflects more of the request path.
How do you reduce TTFB?

Cache responses so the server does less work, serve content from a CDN or edge location closer to users to cut network latency, optimize slow database queries and application code, and remove unnecessary redirects, since each redirect adds a full round trip before the real response can begin.

Put these metrics to work. Monitor your site free.

2-minute setup · Cancel any time
Create Free Account

Your Dashboard

No credit card needed