Auditite
Back to glossary
Performance

TTFB

Understand what Time to First Byte is, how server response time affects page speed and SEO, and how to reduce TTFB for better performance.

Time to First Byte (TTFB) measures the time between a browser sending an HTTP request and receiving the first byte of the response from the server. It includes DNS lookup time, TCP connection time, TLS negotiation time, and the time the server takes to process the request and begin sending data. TTFB reflects your server infrastructure’s responsiveness and is considered a foundational metric — everything else in the page loading process depends on the server responding quickly. A good TTFB is 800 milliseconds or less.

Why It Matters for SEO

TTFB directly impacts Largest Contentful Paint (LCP) because the browser cannot begin rendering any content until it receives the server’s response. A server that takes 2 seconds to respond makes it nearly impossible to achieve a good LCP score (under 2.5 seconds), regardless of how well-optimized the front-end code is. Since LCP is a Core Web Vitals ranking factor, poor TTFB has a cascading negative effect on search rankings.

High TTFB also reduces crawl budget efficiency. When Googlebot encounters slow server responses, it reduces its crawl rate to avoid overloading your server. This means fewer pages get crawled per day, which is particularly problematic for large sites that rely on frequent crawling to index new and updated content.

How to Reduce TTFB

Use a CDN to serve content from edge servers geographically close to your users, reducing network latency. Implement server-side caching — cache fully rendered HTML pages, database query results, and API responses so the server does not regenerate the same content for every request. For dynamic pages, use stale-while-revalidate caching strategies that serve cached content immediately while refreshing it in the background.

Optimize your application code and database queries. Slow database queries are one of the most common causes of high TTFB. Index frequently queried columns, reduce unnecessary joins, and implement connection pooling. Upgrade server hardware or hosting tier if your server is CPU or memory constrained during traffic spikes.

Consider static site generation (SSG) for content that does not change frequently. Pre-rendered HTML files served from a CDN can achieve TTFB under 100ms because there is no server-side processing involved.

Common Mistakes

  • Blaming the front end for slow LCP: If TTFB is over 1 second, front-end optimizations alone cannot fix LCP. Always check server response time first — it sets the floor for all other performance metrics.
  • Not using a CDN: Serving all requests from a single origin server means users on the other side of the world experience hundreds of milliseconds of network latency before your server even begins processing.
  • Ignoring caching: Generating the same page from scratch for every visitor is wasteful. Implement page-level, fragment, and database query caching appropriate to your content freshness requirements.
  • Over-relying on shared hosting: Shared hosting environments allocate limited resources and can have inconsistent TTFB depending on what other sites on the same server are doing. Use dedicated or managed hosting for production sites.
  • Not monitoring TTFB in production: Lab tests from your local network may show excellent TTFB. Use real user monitoring (RUM) and synthetic monitoring from multiple geographic locations to identify regional performance issues.

TTFB is the starting point of every page load and sets the performance ceiling for all downstream metrics, making it one of the first things to audit when diagnosing slow page speed.

See it in action

Learn how Auditite puts ttfb into practice.

Explore Core Web Vitals

See how Auditite handles this

Get started and see the platform in action.

Get started

Get insights delivered weekly

Join teams who get actionable playbooks, benchmarks, and product updates every week.