←  All terms
T
Performance

Time to First Byte

Time to First Byte measures the time from starting a request until the first byte of the server response arrives.

Time to First Byte indicates how quickly a server begins responding after a request is initiated. The metric can be influenced by server processing, hosting infrastructure, network latency, and caching. For a meaningful performance assessment, TTFB should be considered alongside real-user data, repeatable lab tests, and clearly defined performance targets. The concept is closely related to Caching and CDN.

Read more

Caching

CDN

Server-Side Rendering

Largest Contentful Paint

FAQ

Time to First Byte

How can Time to First Byte be reduced?
Through caching of finished HTML, delivery via a CDN close to the visitor, faster database and server logic, fewer redirects, and prebuilt static pages. Which measure helps depends on the cause. Measure first, then change; lab and field data can differ.
How does Time to First Byte affect Largest Contentful Paint?
Directly: LCP cannot start before the HTML arrives. Any delay at the first byte pushes everything after it back. A good TTFB does not guarantee a good LCP, but a poor one makes the 2.5 s threshold hard to reach.
What causes a high Time to First Byte?
Slow server processing, database queries, missing caching, long network paths to the origin server, redirects, and costly TLS negotiation. For dynamically generated pages the cause usually sits in the backend, for static ones in the network or hosting. Breaking the timing into phases shows where to start.
What is a good value for Time to First Byte?
There is no threshold as firm as for the Core Web Vitals, because TTFB is not one of them. The lower it is, the more time remains for a good LCP of at most 2.5 s. It is best assessed at the 75th percentile with field data rather than from single lab measurements.