Time to First Byte (TTFB)

Time to First Byte, or TTFB, measures how long it takes from the moment a visitor starts navigating to your page until the first byte of the HTML response reaches their browser. Nothing can be parsed, discovered or painted before that byte arrives, so TTFB sets the starting point for every loading metric that follows.

From PerfDelta's measurements: In real-user field data (mobile, 75th percentile), 62% of 4,149 websites have a good Time to First Byte and 5% a poor one. The median is 684 ms, with the middle half between 492 ms and 983 ms. More in the data section below.

TTFB phases: from navigation start to the first byte

TTFB is often described as "server response time", but the field metric covers more than the server. It adds up every phase between the start of the navigation and the arrival of the first response byte for the main document:

• Redirects. Each redirect, for example from http:// to https:// or from the bare domain to www, costs a full extra request before the real page is even requested.
• Service worker startup. If your site registers a service worker, the time it needs to start counts toward TTFB.
• DNS lookup. The browser resolves your domain to an IP address.
• Connection and TLS negotiation. The TCP connection is opened and the encrypted HTTPS session is set up, which takes several round trips on a new connection.
• The request and the server's work. The request travels to the server, the server builds the response, and the first byte travels back.

A high TTFB can come from slow application code, but just as often from a redirect chain or from the distance between visitor and server. Measuring the phases separately tells you where to look.

Good TTFB: 0.8 seconds at the 75th percentile

Google publishes the following thresholds for TTFB, assessed at the 75th percentile of real page loads:

Rating	TTFB at p75
Good	0.8 seconds or less
Needs improvement	between 0.8 and 1.8 seconds
Poor	more than 1.8 seconds

The 75th percentile means that three out of four visits should reach the value. The thresholds are guidance: a site that builds most of its content in the browser with JavaScript needs a faster first byte than one that delivers a complete server-rendered page.

TTFB is not a Core Web Vital, but it moves FCP and LCP

TTFB is not one of the three Core Web Vitals, so it is not assessed as a separate ranking signal. It is a diagnostic metric that sits underneath the loading metrics that do count. Every millisecond of TTFB is also a millisecond of First Contentful Paint and Largest Contentful Paint, because the browser cannot start rendering before it has the HTML. With an LCP budget of 2.5 seconds, a TTFB of 1.5 seconds leaves only one second for loading CSS, fonts and the hero image. When LCP fails despite a well-optimized front end, check TTFB first.

TTFB in lab and field data

Field TTFB from the Chrome UX Report

The Chrome UX Report (CrUX) collects TTFB from real Chrome users over a trailing 28-day window. PageSpeed Insights shows it in the field data section. It includes all the phases listed above. When a single URL has too little traffic, the data is reported for the whole origin instead.

Lab audit: Reduce initial server response time

Lighthouse has no TTFB metric in its performance score. Instead, the audit Reduce initial server response time (server-response-time) checks how long the browser waits for the server to answer the main document request, and flags it when that wait exceeds 600 milliseconds. It looks at a narrower slice than field TTFB, since redirects and connection setup are handled by other audits, and it comes from a single test run from one location. A page can pass the lab audit and still show a poor field TTFB because visitors are far away, arrive through redirects or hit uncached pages.

Common causes of a slow TTFB

• Redirect chains. Ad links, old URLs and protocol or host redirects stack up. Two redirects on a mobile connection can cost more than the server's entire processing time.
• Slow server processing. Too much code runs per request, such as many plugins or calls to external APIs while the page is built.
• Database queries. Missing indexes, repeated queries per list item or large unfiltered queries hold up the response.
• No page cache. Without full-page caching, every request builds the HTML from scratch, even when the content has not changed.
• Distance and no CDN. If your server is in one country and your visitors are on another continent, each round trip adds up across DNS, connection, TLS and the request itself.
• Cold starts and cache misses. Serverless functions and sleeping instances need time to start, and the first request after a deployment or cache purge has to rebuild everything.

How to reduce server response time and TTFB

Lighthouse reports a slow first byte as "Reduce initial server response time" (in newer versions "Document request latency"). The fixes below apply to both, in the order in which they usually pay off.

1. Cache the finished page

Full-page caching stores the rendered HTML and serves it without running application code. For content that changes rarely, this is the largest single improvement. Combine it with an efficient cache policy for static assets.

2. Use a CDN that also caches HTML

Many CDNs only cache images, CSS and JavaScript by default. Configure edge caching for HTML as well, so the first byte comes from a location near the visitor instead of your origin server.

3. Remove redirects

Link directly to the final URL in navigation, sitemaps, canonical tags and campaigns. Where a redirect has to stay, make it a single hop to the final destination.

4. Update PHP and add an object cache

Run a current PHP version with OPcache, add a persistent object cache for database results and check whether your plan has enough headroom.

5. Optimize the database and application code

Slow queries are a common culprit on uncached requests. Add indexes for the columns you filter on, remove N+1 query patterns and profile the slowest requests. A slow query log and EXPLAIN show whether a query uses an index or scans the whole table.

6. Right-size the hosting

The hosting class sets a floor that no software can go below. Shared hosting is cheap but gives fluctuating response times once neighbours generate load. A VPS or dedicated server reserves resources, managed hosting ships page and object caching preconfigured, and edge platforms serve prerendered responses close to the visitor. If a page keeps a high TTFB after clean caching and a tuned database, moving up a hosting class is often the most effective single step.

7. Use the waiting time with 103 Early Hints

If your server or CDN supports it, a 103 Early Hints response lets the browser start loading critical resources while the server is still building the page. It does not make the server faster, but it puts the waiting time to use.

TTFB on WordPress, Shopify and Next.js

On WordPress, a high TTFB usually means pages are built on every request. A caching plugin with full-page caching, a persistent object cache and fewer plugins that run on every page load are the main fixes. Logged-in users and WooCommerce cart pages often bypass the page cache, so test those separately.

On Shopify, the server and CDN are managed by the platform, so your control over TTFB is limited. Focus on avoiding redirects, for example from outdated links or market and language redirects that could point directly to the final URL.

On Next.js and other React frameworks, the rendering mode decides TTFB. Static generation serves prebuilt HTML quickly. Server-side rendering on every request adds rendering and data fetching to the wait. Streaming lets the server send the page shell early while slower parts follow.

Measuring TTFB with DevTools, curl and field data

In Chrome DevTools, open the Network panel, reload the page, click the document request and open the Timing tab. It separates DNS lookup, initial connection, SSL and Waiting for server response, so you can see which phase dominates.

On the command line, curl reports the same phases. The values are cumulative from the start of the request:

curl -o /dev/null -s -w "DNS:     %{time_namelookup}s\nConnect: %{time_connect}s\nTLS:     %{time_appconnect}s\nTTFB:    %{time_starttransfer}s\nTotal:   %{time_total}s\n" https://example.com/

Run it several times, since the first request may hit a cold cache. Without -L, curl does not follow redirects, so also test the URLs people actually arrive on. In the browser console you can read the TTFB of the current page from the Navigation Timing API:

const [nav] = performance.getEntriesByType('navigation');
console.log('TTFB:', Math.round(nav.responseStart), 'ms');

PerfDelta tests several pages on mobile and desktop and shows lab and field data side by side, so you can compare the lab server response with the real-user TTFB. How the tool rates these values is described in the methodology. After a fix, lab values react immediately, while field TTFB in CrUX follows over its trailing 28-day window.

Frequently asked questions

What is a good TTFB?

A TTFB of 0.8 seconds or less at the 75th percentile of real page loads is good. Between 0.8 and 1.8 seconds needs improvement, and more than 1.8 seconds is poor.

What is the difference between TTFB and server response time?

Field TTFB covers everything from the start of the navigation to the first response byte: redirects, service worker startup, DNS lookup, connection and TLS setup, and the server's work. Server response time, as in the Lighthouse audit, looks only at how long the server takes to answer the main document request.

Does TTFB affect SEO?

TTFB is not a Core Web Vital and not a separate ranking signal. It affects SEO indirectly, because a slow first byte delays First Contentful Paint and Largest Contentful Paint, and LCP is a Core Web Vital.

Why is TTFB high on WordPress?

Usually because WordPress builds each page on every request. Missing full-page caching, many plugins running on each load, slow database queries and underpowered shared hosting are the most common reasons.

What is the difference between TTFB and latency?

Latency is the time a single round trip takes between browser and server. TTFB includes several round trips for DNS, connection and TLS setup, plus redirects and the time the server needs to build the response.

Why does my TTFB differ between lab and field data?

A lab test measures one request from one location. Field data from the Chrome UX Report reflects real visitors on different networks and in different places over 28 days, including redirects and uncached pages.