TTFB (time to first byte): what it is, what is good and how to fix it

TTFB (time to first byte) is the time between the browser asking for a page and the first byte of the answer arriving from your server. It is the silence before the page: the visitor tapped, and for this long nothing at all has come back. Google rates a TTFB of 800 ms or less as good for real visitors; under 200 ms it is invisible, and over a second it is the "is this loading?" pause that pushes back every other metric. This guide explains what TTFB includes, what a good value is, how to measure it the way a visitor experiences it, and which part of the wait is yours to fix, with links to the detailed guides on hosting, caching and CDNs.

Quick answer

• TTFB meaning: the time from the request until the first byte of the response. It includes redirects, DNS lookup, the connection and TLS handshake, and the time the server spends building the page.
• Good: 0.8 s or less at the 75th percentile of real visitors (Google's threshold on web.dev); poor above 1.8 s. A cached page on decent hosting answers in 100-300 ms from nearby.
• For CMS sites, page caching turns 1-2 s into around 100-300 ms: the server sends a saved copy instead of running PHP and database queries.
• Redirect chains add a full round trip per hop; removing them is free.
• Distance adds a round trip per step of the connection; a CDN brings the answer closer.
• Run the free TTFB test for your number and the redirect hops, and the hosting speed check to see whether your host or your site is the limit.

What is TTFB?

TTFB is the first number in every page load. Google's definition on web.dev counts everything from the moment the navigation starts until the first byte of the response arrives:

1. Redirects, if the URL you requested sends you elsewhere first.
2. Service worker start-up, if the site has one.
3. DNS lookup: turning the domain name into an IP address.
4. Connection and TLS negotiation: the TCP handshake and the encryption handshake.
5. The request, and the time the server takes to build and start sending the answer.

In the browser's Navigation Timing API, that is the responseStart value of the page. Only the last step is "the server" in the narrow sense; everything before it is where the server sits and how it is reached. That is why the same site can have a good TTFB for a visitor in the next city and a poor one for a visitor on another continent.

TTFB is measured for the HTML document, but every other file has a first byte too. When people say "TTFB" without qualification they mean the page itself, because nothing else can start before it.

TTFB vs server response time

The terms get mixed up, and tools label them differently:

So a Lighthouse server response time of 300 ms and a field TTFB of 1.1 s are not a contradiction: the difference is the network, the handshakes and any redirects. Lighthouse flags the server's own share when it is over 600 ms.

What does "Waiting for server response" mean in DevTools?

Open Chrome's developer tools, go to the Network tab, reload, click the page's own request and open Timing. The bar labelled "Waiting for server response" (older versions said "Waiting (TTFB)") is the time between the request being sent and the first byte coming back. The rows above it (DNS lookup, initial connection, SSL) are the network part. A long green "waiting" bar on a fast connection is server time: an uncached page, a slow query or an overloaded host.

What is a good TTFB?

Google's guidance on web.dev measures TTFB at the 75th percentile of real visits, network included:

In practice, a cached page on decent hosting answers in 100-300 ms from a nearby location. An uncached WordPress or shop page in 400-800 ms is normal, and anything over a second is worth fixing. TTFB is not a Core Web Vital itself, but it is the start of Largest Contentful Paint, so a slow TTFB makes a good LCP hard.

Why TTFB matters

Nothing renders until the first bytes arrive: not the HTML, not the CSS it references, not the hero image it will discover in the HTML. A page that takes 1.5 s to start and then needs 1 s to show its main content has an LCP of 2.5 s, which is Google's limit for good. Cutting TTFB is the one fix that moves every other metric: First Contentful Paint, LCP and Speed Index all start after it. The Core Web Vitals guide explains how LCP is assessed, and the page speed guide shows where the server sits among the other causes of a slow page.

It also compounds across a visit. Every page click waits for TTFB again, and so does every uncached request the page makes to your own server. A slow server feels slow everywhere, whereas a large image only hurts once.

Where the time goes

A visitor in Zagreb reaching a server in Frankfurt pays roughly 30 ms per round trip; the same visitor reaching Oregon pays about 150 ms per round trip, and there are three or four of them before the server even starts working. That is what a CDN fixes: the round trips happen to a nearby edge, and cached pages never reach the origin at all. HTTP/3 shortens the handshake too, because QUIC sets up the connection and encryption together; the HTTP/2 and HTTP/3 guide explains how.

How to measure TTFB

The TTFB test measures from our test location in Frankfurt with a fresh connection, the way a first-time visitor arrives, and lists every redirect hop separately. Next to it you get Lighthouse's server response time and, where Google has enough visits, the field TTFB from real Chrome users. That last number is the one Google's thresholds apply to, and it covers visitors wherever they are.

A few rules make any measurement trustworthy:

• Run it three times. Consistent 200 ms is fine. Consistent 1,200 ms is the server. 200 ms, 1,800 ms, 250 ms means the first request after a quiet period is slow: a cache that expired or a PHP process that had to start.
• Test logged out. Caches bypass logged-in users, so testing from your CMS session measures the slowest path.
• Test a cached and an uncached page. The home page is usually cached; the cart, search results or a URL with ?nocache=1 are not. The difference is what caching is saving you.

From a terminal, curl breaks the same number into its parts:

curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}\n" https://example.com/

Each value is cumulative seconds from the start. ttfb minus tls is roughly the server's own time. Run it from a server in the region your visitors are in, not from the web server itself.

For developers, a Server-Timing response header (a W3C standard) can name where the server's time went, for example Server-Timing: db;dur=412, app;dur=96. Chrome's developer tools show it in the Timing tab, which turns "the server is slow" into "this query is slow".

Is it the host or the site?

"Why is my website slow?" has two different answers, and TTFB tells you which one to chase:

The hosting speed check names the network or managed host behind the site and compares your first byte with the anonymous median of other sites we checked on the same host, once that host has 50 sites. Slower than most of them means the host is not the limit and something on your site is. Behind a CDN the origin host is hidden, and the check says so rather than compare unfairly.

How to reduce TTFB

The fixes, in the order that pays off. The guide on how to reduce TTFB and server response time has each one in full, including what works on cheap shared hosting before you pay for an upgrade.

1. Remove redirect hops. Each is a full round trip, plus a new connection when it crosses from http:// to https:// or to another hostname. Redirect straight to the final URL: http://www.example.com/page → https://example.com/page/ in one 301. See redirects without chains.
2. Turn on full-page caching. On WordPress, Joomla, Drupal and most shop systems, an uncached page starts PHP, loads every plugin and runs dozens of database queries for every visitor. A page cache saves the rendered HTML and serves it in milliseconds. Use your host's cache if it has one, or a single caching plugin; exclude cart, checkout and account pages. Keep the lifetime long (12-24 h) with purge on publish, so most pages stay warm.
3. Keep the server warm. Shared hosting often stops PHP processes after a few idle minutes, and the next request pays 300-800 ms to start one. On your own server, pm = static in PHP-FPM, or pm = ondemand with a longer pm.process_idle_timeout, keeps workers ready.
4. Find the slow query. An uncached page with a 2 s TTFB is usually one slow database query or one plugin calling an external API. Query Monitor on WordPress shows the queries per page and their time; an object cache (Redis or Memcached) keeps repeated results in memory.
5. Use a supported PHP version and enough memory. Old versions no longer get security fixes, many plugins run slower on them, and the upgrade is often a dropdown in the hosting panel. Test on staging first.
6. Put a CDN in front for visitors far from your server (next section).
7. Then look at the hosting plan. If all of the above is done and cached pages still answer slower than 600 ms, the server is overloaded or far away.

Hosting: when the server is the limit

Hosting sets the floor for TTFB. On cheap shared hosting, hundreds of sites share one machine, and your page waits whenever a neighbour is busy. A small VPS or a managed WordPress plan with a server-side cache and dedicated PHP workers usually lands cached pages well under 300 ms. The price difference is often a few euros a month; the real cost is that a VPS needs someone to maintain it.

Do not choose a host by its marketing or by review sites. How to choose a web host by measured TTFB shows how to compare hosts with your own numbers: test the same pages on the old and new host, at different times of day, cached and uncached, and compare the medians. The hosting speed check's peer comparison gives you a starting point for hosts that already have enough sites in it.

Signs the plan is too small rather than the site too heavy: a first byte that is fine at quiet times and slow at busy ones, 503 or 508 errors at traffic peaks, and a host that throttles CPU when you exceed a limit.

CDNs: bringing the first byte closer

A content delivery network keeps copies of your files, and optionally your pages, at edges around the world. For cached content the visitor's handshakes happen with a nearby edge, and the request never reaches your origin. For a site with visitors on several continents it is the only way to get a good TTFB everywhere; for a local site on a nearby server the gain is smaller.

The catch is that a CDN only helps what it caches. Most CDNs cache images, CSS and JavaScript by default but not HTML; caching pages needs a rule, with exclusions for logged-in visitors, carts and checkouts. Anything uncached still waits for your origin, so a CDN in front of a slow server hides the problem on cached pages only. CDN basics: what it fixes and what it does not covers the setup and the traps, and a CDN is really a rented reverse proxy: that guide explains the self-hosted kind in front of your own app, and the forwarding headers that keep it honest.

Slow server response on WordPress

WordPress builds every page with PHP and MySQL, so without a page cache its TTFB depends on every plugin you have installed. The common causes, in the order to check them: no page cache or two caching plugins fighting, visitors bypassing the cache (logged-in users, WooCommerce session cookies, query strings, over-broad exclusions), a plugin running slow queries or calling external services, oversized autoloaded options, WooCommerce's cart fragments request on every page view, and wp-cron running scheduled tasks during a visitor's request.

The guide on how to reduce initial server response time on WordPress walks through that order: checking that the cache is really hit, profiling uncached pages with Query Monitor, trimming autoloaded options, moving background work out of visits, and PHP workers and object caching, before judging the host. These cover the individual parts: why two caching plugins break things, WP-Cron and scheduled tasks, WooCommerce caching for cart, checkout and account pages and why your WordPress site is slow.

Does web hosting affect SEO?

Indirectly. Google does not rank a site lower because its server is in another country; to target a country, use your domain, language and hreflang. Server location matters for speed instead: every round trip to a far-away server adds delay, which a CDN removes for cached pages.

What hosting does affect is speed and availability. A slow first byte delays LCP, which is part of Core Web Vitals, and a server that times out or returns errors at peaks makes Googlebot crawl less; pages that stay unreachable for long can drop out of the index. For planned maintenance, a 503 with Retry-After tells Google the outage is temporary.

The guide does web hosting affect SEO? covers what Google says about server location, how speed and uptime reach rankings, the hosting worries that do not matter (shared IP addresses, the host's brand), and how to tell whether your host is holding the site back.

Platform notes

• WordPress: page cache, object cache and no redirect chains cover most cases. See the section above.
• Shopify, Wix, Squarespace: TTFB is the platform's; you cannot change it, only the redirects in front of the page and the page weight after it.
• Static sites and headless front ends: the HTML is already a file, so TTFB is mostly network. A CDN in front and long cache lifetimes on hashed files keep it low; see browser caching and Cache-Control.
• Custom applications: measure the database and every outbound API call made during the request. A 400 ms call to a third-party API on every page is a 400 ms TTFB floor.

Verify

• Three runs of the TTFB test within 100 ms of each other, and under 300 ms for a cached page.
• The redirect finding shows zero hops from the URL people use.
• The response headers show the cache working on the second request: x-cache: HIT, x-litespeed-cache: hit, cf-cache-status: HIT or your plugin's own header.
• Field TTFB (the CrUX row) under 800 ms at the 75th percentile after four weeks.

Common mistakes

• Testing while logged in. Caches bypass logged-in users; test in a private window or with a tool.
• Measuring from the server itself or from the same data centre. The visitor's distance is part of the number.
• Comparing Lighthouse's server response time with field TTFB. One excludes the network, the other includes it.
• Caching the cart page. Visitors see each other's carts. Use the plugin's default exclusions.
• Blaming the theme for a hosting problem. A 1.5 s TTFB on a cached page is the host, not the CSS.
• Adding a CDN before fixing redirects. The CDN caches the redirect too; the chain stays.

Questions people ask

What does TTFB mean?

TTFB stands for time to first byte: how long it takes from the moment the browser requests a page until the first byte of the response arrives. It includes the DNS lookup, the connection and TLS handshake, any redirects and the time the server spends building the page. Nothing can appear on screen before it, so a slow TTFB delays First Contentful Paint and Largest Contentful Paint by the same amount.

What causes a high TTFB?

Usually one of four things: no page cache, so the server builds every page from scratch; a slow database query or a plugin calling an external service during the request; redirect hops in front of the page; or distance between the visitor and the server. An overloaded shared server adds random spikes on top. The step-by-step guide to reducing TTFB goes through them in the order that pays off.

Is a TTFB of 1 second bad?

For real visitors, yes: Google rates TTFB good at 800 ms or less at the 75th percentile, so 1 s is in the "needs improvement" band, and it leaves little room for an LCP under 2.5 s. For a single lab test from far away it may be mostly distance. Check whether cached pages from a nearby location answer in under 300 ms; if they do, a CDN is the fix, not the server.

What is "Waiting (TTFB)" in Chrome DevTools?

It is the time between Chrome sending the request and receiving the first byte of the response, shown in the Network tab under Timing. Newer Chrome versions label it "Waiting for server response". It excludes the DNS lookup and the connection, which appear as separate rows above it, so it is mostly your server's own time. A long waiting bar on a fast connection points to an uncached page, a slow query or an overloaded host.

Is TTFB the same as server response time?

Not quite. TTFB, as Google defines it, runs from the start of the navigation to the first byte and includes redirects, DNS, the connection and TLS. Server response time, as Lighthouse reports it, is only the server's share for the main document. That is why a 300 ms server response time can sit next to a 1.1 s field TTFB: the rest is network and redirects. Fix the server share with caching, the rest with a CDN.

How do I test TTFB?

Run a TTFB test on the page three times and compare the numbers, because one run can hit a cold cache. Test from a clean browser session or a tool, not while logged in to your CMS, which bypasses the cache. For what real visitors get, look at the field TTFB from Chrome users in the speed report; it includes their distance from your server and is the number Google's thresholds apply to.

How do I find out what makes my server slow?

Compare a cached page with an uncached one, such as the cart or search results. If only uncached pages are slow, the time goes into building pages: look at plugins, database queries and the PHP version, with a profiler such as Query Monitor on WordPress. If even cached pages are slow, the cause is the host, the distance to it or a missing CDN.

Does a CDN reduce TTFB?

Yes for cached content, often dramatically: a page or file served from an edge near the visitor skips the long round trips to your origin and the server's processing time. No for anything the CDN cannot cache, such as the cart, checkout, search results and logged-in pages; those still wait for your origin. A CDN in front of a slow server hides the problem on cached pages only. What a CDN fixes covers the setup.