Glossary

What is Time to First Byte (TTFB)? What is good and how to reduce it

Time to first byte is how long a browser waits from requesting a page until the first byte of the response arrives. What it includes, what a good TTFB is, and how to cut it.

Chen Yu Reviewed by Xu An Also called TTFB Last updated Nov 4, 2026 Glossary

Where to see it in TapCub

Performance report

Open the report Start free

Quick answer

Time to first byte (TTFB) is the time from the start of navigation until the first byte of the page’s response arrives. It includes redirects, DNS lookup, connection and TLS setup, and server processing. Good is 800 milliseconds or less.

Formula: TTFB = redirects + service worker start-up + DNS + connection and TLS + request and server processing

What is time to first byte?

Time to first byte (TTFB) is how long the browser waits, from the moment navigation starts, until the first byte of the HTML arrives. Nothing on the page can render before it, so it sets the floor for first contentful paint (FCP) and LCP.

Rating	TTFB
Good	800 ms or less
Needs improvement	800 ms–1.8 s
Poor	over 1.8 s

What is inside TTFB

Part	What adds time
Redirects	Each hop (http → https → www) is another round trip
DNS lookup	Resolving the domain
Connection and TLS	Opening the connection and the secure handshake
Server processing	Database queries, rendering, uncached pages

A sample breakdown

Sample data: a store's P75 TTFB is 1.4 s: 0.3 s for two redirects (an http:// ad link to https:// to www), 0.05 s DNS, 0.15 s connection and TLS, 0.9 s for the server to build an uncached category page.

Two fixes: point ad links at the final URL (redirects gone) and cache the category HTML at a CDN for a few minutes (server 0.9 → 0.2 s). New TTFB: 0.05 + 0.15 + 0.2 = 0.4 s.

How to reduce TTFB

Link to final URLs; remove redirect chains.
Cache HTML at the edge, even for short periods.
Use a CDN so connections open close to the visitor.
Profile slow server work: database queries and third-party API calls made while rendering.
Check TTFB by country and device; a fast home market can hide slow ones.

TTFB in TapCub

TapCub collects Web Vitals from real visits with the site script (sent once, when the first page is hidden; turn off with data-vitals="false"). In Web analytics › Monitoring › Performance, cards switch between P75, median, P95 and average, the breakdown splits by page, device, browser, country and operating system, and Slowest pages is sorted by P75 largest contentful paint. Details are in the performance docs. The load timing chart there also splits each load into back end (first byte), network transfer and front-end rendering.

Was this explanation clear?

We use your answers to fix and expand this page.

Chen Yu

Technical Engineer

Focuses on tracking code, SDKs, and API integrations, with practical guidance on implementation checks and troubleshooting.

FAQ

Questions people ask

Short answers to the follow-up questions that come up most.

Still have a question?

Chat with the team behind TapCub — we usually reply within a few hours on business days.

Chat with us Help center

What is a good TTFB?

800 milliseconds or less is good, over 1.8 seconds is poor, and in between needs improvement, at the 75th percentile of real visits.

Is TTFB a Core Web Vital?

No, but every other loading metric starts after it, so a slow TTFB makes a good LCP very hard.

Why is my TTFB slower for real users than in tests?

Tests often run from a data centre near your server. Real visitors are further away, on mobile networks, and their requests may miss the cache.

Do redirects count in TTFB?

Yes. Each redirect adds a full round trip before the final page is even requested.

See this number on your own site

Add one script tag for web and apps, and the first reports fill in within minutes.

Start free Open the report