TTFB: What Is Time to First Byte?

Q: Does TTFB directly affect SEO?

Yes, indirectly but meaningfully. TTFB contributes to the Largest Contentful Paint (LCP), which is a Core Web Vital with direct weight in Google's ranking algorithm. A high TTFB delays the start of visible loading and makes it nearly impossible to achieve a good LCP score.

Q: What's the difference between TTFB and FCP?

TTFB measures when the first byte of the response arrives — the server has started responding, but the browser hasn't painted anything yet. FCP (First Contentful Paint) measures when the browser paints the first visible text or image. FCP always happens after TTFB.

TTFB (Time to First Byte) is the time that elapses from when the browser sends an HTTP request to when it receives the first byte of the server's response. Put simply: it measures how quickly your server starts to answer. A low TTFB means the server reacts fast; a high one signals that something in the backend, the network, or the configuration is creating a bottleneck.

This article breaks down exactly what goes into TTFB, what values are considered good, which factors drive it up, and how to diagnose and fix it.

What TTFB Actually Measures

TTFB is not just "server time." Three distinct phases accumulate inside that single number:

Connection time: DNS resolution, TCP connection establishment, and the TLS handshake (if the site uses HTTPS).
Server processing time: how long the server takes to generate the response — database queries, business logic, template rendering, etc.
Network round-trip time: the physical latency between the server and the user's browser.

The browser cannot paint anything on screen until that first byte arrives. That makes TTFB the gateway to the entire loading experience.

What TTFB Values Are Considered Good

Google defines the thresholds for this metric as follows:

Rating	TTFB
Good	Under 800 ms
Needs improvement	800 ms – 1,800 ms
Poor	Over 1,800 ms

For modern, well-optimized sites, a TTFB below 200 ms is entirely achievable when the user is geographically close to the server or CDN node serving the content.

What Factors Drive TTFB Up

A high TTFB almost always has an identifiable cause. The most common are:

Hosting quality

This is the single biggest factor. An overloaded shared hosting plan — with dozens of sites competing for the same CPU and memory resources — can produce a TTFB of 1–3 seconds purely from resource contention. Migrating to a VPS or a plan with dedicated resources is often the fastest improvement available.

Slow database queries

Every time a dynamic page (WordPress, Joomla, custom apps) needs data, it runs SQL queries. If those queries lack proper indexes, scan millions of rows, or chain without optimization, the server can't respond until they finish. The result: TTFB spikes.

No full-page caching

Without caching, every request forces the server to rebuild the page from scratch — PHP, database, template — for every visitor. With full-page caching enabled, the server serves a pre-generated static HTML file in milliseconds, without touching the database at all.

Physical distance between server and user

Light travels fast, but not instantaneously. A user in one continent reaching a server on another adds 100–200 ms of latency through physics alone. A Content Delivery Network (CDN) solves this by placing copies of your content on servers closer to each region.

Slow or unoptimized TLS handshake

HTTPS requires a negotiation process (handshake) that adds one or two network round trips before data starts flowing. Outdated TLS versions (1.0/1.1), poorly chained certificates, or missing session resumption can unnecessarily inflate this time.

How to Measure Your Site's TTFB

Several tools give you the number:

Chrome DevTools: Network tab → click any resource → Timing section. The "Waiting (TTFB)" value is exactly what you need.
Google PageSpeed Insights: reports it in the diagnostics section under "Initial server response time."
WebPageTest: shows TTFB per resource and lets you test from different geographic locations — great for separating network latency from processing time.
Search Console (CrUX): the Core Web Vitals report includes real TTFB data from your actual users, not simulations.

For an accurate picture, test from at least two locations — one near your server and one far — and at different times of day to catch load spikes.

How to Reduce TTFB Step by Step

Once you've identified the cause, the most effective solutions are:

Enable full-page caching. On WordPress, plugins like WP Rocket or W3 Total Cache (disk-based) serve pages in under 50 ms. On custom apps, Varnish or Nginx FastCGI cache do the same job.
Optimize database queries. Use EXPLAIN in MySQL/MariaDB to find slow queries. Add indexes on columns used in WHERE clauses and avoid unnecessary SELECT * statements.
Use a CDN. For geographically dispersed users, a CDN can reduce perceived TTFB from 800 ms to under 100 ms by serving from the nearest node.
Upgrade to TLS 1.3. It reduces the handshake to a single network round trip compared to two for TLS 1.2. Most modern servers support it with a configuration change.
Scale your hosting. If the server is CPU- or memory-saturated, no code optimization will fix the root cause. A higher-capacity plan or dedicated server may be the necessary next step.

For deeper coverage of related metrics and techniques, browse the web performance article archive for guides on LCP, CLS, and caching explained step by step.

If you'd prefer an expert to diagnose your site's TTFB and hand you a concrete action plan, the team at elenlace.com delivers performance audits with recommendations prioritized by business impact.

Key Takeaways

TTFB measures the time between the browser's request and the first byte of the server's response.
It's composed of three phases: network connection, server processing, and network latency.
Google considers TTFB under 800 ms "good"; under 200 ms is excellent.
The most common causes are overloaded hosting, slow queries, missing caching, and server distance.
Full-page caching and a CDN are the two highest-leverage fixes available.

Is your TTFB above 800 ms and you're not sure where to start? Reach out to elenlace.com for a technical review and get actionable recommendations tailored to your stack.

FAQ

Does TTFB directly affect SEO?

Yes, indirectly but meaningfully. TTFB contributes to the Largest Contentful Paint (LCP), which is a Core Web Vital with direct weight in Google's ranking algorithm. A high TTFB delays the start of visible loading and makes it nearly impossible to achieve a good LCP score.

Can I improve TTFB without changing hosting providers?

In many cases, yes. Enabling full-page caching, optimizing slow database queries, and adding a CDN can significantly reduce TTFB without migrating servers. If the underlying issue is resource saturation on your current plan, a hosting upgrade will eventually be unavoidable.

What's the difference between TTFB and FCP?

TTFB measures when the first byte of the response arrives — the server has started responding, but the browser hasn't painted anything yet. FCP (First Contentful Paint) measures when the browser paints the first visible text or image. FCP always happens after TTFB.

Is a TTFB of 800 ms bad for every site?

Not equally. For a user with a server in the same region, 800 ms clearly signals a backend problem. For a user on the other side of the world with no CDN, part of that time is unavoidable network latency. That's why it's worth testing from multiple locations before concluding where the problem actually lives.

Useful resources

Other providers and guides worth comparing: