Home > Web Vitals > Performance > Time To First Byte

Time To First Byte (TTFB)

Last updated July 20, 2025

TTFB (Time To First Byte) is a key performance metric that measures how long it takes for a browser to receive the first byte of a page’s content from the server. It captures everything that happens from the moment a request is made until the very first byte of the response is received — including DNS lookup, TCP and TLS connection, and server processing time.

While TTFB isn’t one of the three Core Web Vitals, it directly influences metrics like FCP (First Contentful Paint) and LCP (Largest Contentful Paint), making it a foundational part of perceived performance.

What it measures

TTFB tracks the time between the start of a request and the moment the browser receives the first byte of the response. It includes:

  • DNS resolution
  • TCP handshake
  • TLS negotiation (for HTTPS)
  • Server processing

Unlike FCP or LCP, which measure rendering milestones, TTFB reflects the backend performance and network latency.

Why it matters (UX/SEO impact)

TTFB plays a critical role in how fast your site feels to users. A high TTFB means your page hasn’t even started to render, leading to a blank screen and user frustration. Moreover, search engines like Google factor in TTFB when crawling and indexing — slow response times can reduce crawl efficiency.

Relation to other Web Vitals

Although TTFB is not a Core Web Vital, it sets the stage for all others. For example:

  • A high TTFB delays FCP and LCP.
  • Even with fast rendering code, slow server response increases load times.
  • Optimizing TTFB can lead to significant improvements in perceived speed.

Common Causes of Poor TTFB

  • Slow server-side processing (e.g., unoptimized database queries)
  • Heavy backend frameworks or middleware layers
  • Uncached dynamic pages
  • Large session state or authentication bottlenecks
  • Lack of CDN or edge infrastructure
  • Origin server far from end-users

How TTFB is Measured

In the browser, TTFB is usually calculated as:

    

  1. TTFB = responseStart - requestStart
    2.

Or with the Navigation Timing API:

    

  1. const entry = performance.getEntriesByType('navigation')[0];
    2. 

  2. console.log('TTFB:', entry.responseStart);
    3.

You can also monitor TTFB in real-time using a PerformanceObserver:

    

  1. new PerformanceObserver((entryList) => {
    2. 

  2.   const nav = entryList.getEntries()[0];
    3. 

  3.   console.log('TTFB:', nav.responseStart);
    4. 

  4. }).observe({ type: 'navigation', buffered: true });
    5.

What is a Good TTFB Score?

  • Good: ≤ 200 ms
  • Needs Improvement: 200 – 500 ms
  • Poor: > 500 ms
Score Scale
200ms
500ms

The 75th percentile rule applies: Google recommends keeping TTFB under 200ms for at least 75% of user visits.

How to Improve TTFB

1. Implement Full-Page Caching

Caching the entire HTML output at the server level or using a CDN dramatically reduces backend processing time for repeat visits.

    

  1. <staticContent>
    2. 

  2.   <clientCache cacheControlMode="UseMaxAge"
    3. 

  3.        cacheControlMaxAge="7.00:00:00" />
    4. 

  4. </staticContent>
    5.

Use output caching in platforms like ASP.NET, PHP (with OPcache), or Next.js (via getStaticProps).

2. Optimize Server Logic and Database Queries

Refactor server-side logic to eliminate blocking operations, reduce API calls, and optimize database access using proper indexing and query tuning.

  • Use async patterns or background jobs for heavy lifting.
  • Avoid deep joins and unindexed WHERE clauses.
  • Profile endpoints and eliminate redundant logic.

3. Use a CDN and Edge Rendering

Deploy a Content Delivery Network to cache static responses geographically close to users.

    

  1. // Example HTTP header for edge caching
    2. 

  2. Cache-Control: public, max-age=86400, s-maxage=86400
    3.

Consider full-page caching at the edge using Cloudflare Workers, Netlify Edge Functions, or similar.

4. Reduce TLS and Connection Overhead

Enable HTTP/2 or HTTP/3, reuse connections, and minimize TLS handshakes by setting a long keep-alive timeout.

    

  1. KeepAliveTimeout 5
    2. 

  2. MaxKeepAliveRequests 100
    3.

Use tools like SSL Labs to verify TLS handshake speed and configuration.

5. Prioritize Critical Requests

Defer non-essential middleware and avoid server logic that blocks the first byte (e.g., unnecessary auth for public content).

Use conditional middleware or lazy loading techniques to streamline your response pipeline.

Monitoring and Continuous Testing

TTFB should be monitored continuously, especially when backend or hosting infrastructure changes.

Testdom.io provides a great way to:

  • Monitor TTFB across different pages and devices
  • Compare real-world data vs. lab audits (e.g., Lighthouse)
  • Trigger alerts when TTFB exceeds thresholds

For ongoing field tracking:

    

  1. import { onTTFB } from 'web-vitals';
    2. 

  2. onTTFB((ttfb) => {
    3. 

  3.   console.log('Live TTFB:', ttfb);
    4. 

  4. });
    5.

Combine this with CI/CD pipelines to detect regressions before deployment.

Fast server responses lay the foundation for smooth loading and higher user satisfaction — optimizing TTFB is often the most impactful first step.