What Is TTFB (Time to First Byte)?
Updated 6 October 2026
Jump to section
Time to First Byte (TTFB) measures how long the first byte of a page's response takes to arrive, counted from the moment a visitor starts navigating to it. It reflects connection setup and server response. It is not one of the Core Web Vitals, but a slow TTFB drags down loading too. web.dev rates a TTFB of 0.8 seconds or less as good, and treats anything over 1.8 seconds as poor.
What does TTFB actually measure?
TTFB measures the gap between a visitor starting to navigate to a page and the first byte of the server's response arriving. web.dev defines it as "the time between starting navigating to a page and when the first byte of a response begins to arrive."
Everything that happens before your content can begin downloading sits inside that number. That includes any redirects, the DNS lookup, opening the connection, and the time your server spends building the page.
The reason it matters is simple: nothing else can start until the first byte lands. A browser cannot paint a heading or download an image while it is still waiting to hear back from the server.
What counts as a good TTFB?
A good TTFB is 0.8 seconds or less, and web.dev treats anything over 1.8 seconds as poor. The band in between needs improvement.
| Rating | TTFB |
|---|---|
| Good | 0.8 seconds or less |
| Needs improvement | 0.8 to 1.8 seconds |
| Poor | Over 1.8 seconds |
Source: web.dev, Time to First Byte (TTFB) (Google, 2026).
Most sites should aim to stay under the good line, because every millisecond spent here is time the visitor waits before anything appears.
Is TTFB a Core Web Vital?
No. TTFB is not one of the three Core Web Vitals, the metrics Google says its ranking systems use. web.dev says it is "not absolutely necessary that sites meet the 'good' TTFB threshold", because TTFB is not a Core Web Vitals metric.
It adds one condition: a slow TTFB must not stop a page scoring well on the metrics that do count. TTFB is the foundation Largest Contentful Paint is built on, so a slow first byte quietly makes a good LCP much harder to reach. Fixing TTFB is not a ranking fix on its own, but it often unblocks LCP, which is a Core Web Vital.
Why is my TTFB slow?
A slow TTFB usually points back to the server and the path to it, not to anything on the page itself. The visitor's browser is simply waiting.
- Slow or overloaded hosting. Budget shared hosting markets on speed but has a low ceiling, and it slows under real traffic.
- No caching. Rebuilding every page from scratch on each visit is slow; caching serves a ready-made copy instead.
- A server far from your visitors. A site hosted overseas answers a Malaysian visitor slowly; a CDN serves them from a closer location.
- A heavy backend. Slow database queries and bloated plugins add time before the first byte leaves.
- Redirect chains. Each extra hop is another round trip to the server before the real response begins.
In our experience maintaining Malaysian SME sites, the quiet cause is low-cost hosting that tested fine at launch. It then slows as the business and its traffic grow, because budget shared plans cap out under load.
Frequently asked questions
Is TTFB a ranking factor?
Not directly. Google says its ranking systems use Core Web Vitals, and web.dev states TTFB is not one of them. It matters because it feeds Largest Contentful Paint, which is a Core Web Vital. A slow first byte makes that metric harder to pass, so TTFB can affect Search indirectly rather than on its own.
What is a good TTFB?
A good TTFB is 0.8 seconds or less, and over 1.8 seconds is poor. The range in between needs improvement. Because TTFB sits ahead of everything the visitor sees, aim comfortably under the good line so the rest of the page has room to load fast.
How is TTFB different from LCP?
TTFB times when the first byte of the response arrives; LCP times when the largest visible element finishes painting. TTFB happens first and sits inside LCP, so a slow TTFB delays LCP by definition. You can have a fast TTFB and still fail LCP, but you cannot pass LCP comfortably with a very slow TTFB.
Can a CDN improve my TTFB?
Yes, often a lot. A content delivery network stores copies of your site in many locations and answers each visitor from a nearby one, which cuts the distance the request travels. For a Malaysian site with overseas hosting, that shorter round trip is often one of the bigger TTFB wins.
Why is my TTFB fine for me but slow for others?
You are probably close to the server, or testing at a quiet time. A visitor far from the host, or one arriving during a traffic spike, waits longer for the same first byte. Field data from real visits captures those slower cases that your own quick test misses.
Where TTFB fits your site
Storming Solutions builds and maintains websites for Malaysian businesses from Kuala Lumpur. Server response is one of the first things we test when a site feels slow before the content even appears. TTFB is often the honest starting point, because no amount of image work speeds up a page the server is still holding back.
Want to know how long your server keeps visitors waiting? Ask us on WhatsApp and we will check it as part of a free website review, then tell you whether the fix is hosting, caching, or a closer server.