What Is TTFB and Why Does It Matter for Your Page Speed Score?

July 14, 2026 8 min read by Chunky Munster

TTFB stands for Time to First Byte, which is the delay between a browser asking for a page and receiving the first byte of the response. It matters because a slow first response can make the whole site feel laggy, even before the browser starts rendering anything useful. If you want to check yours fast, try our free TTFB checker.

What TTFB actually measures

TTFB is not just “server speed.” It includes several steps: DNS lookup, connection setup, the server processing the request, and the time until the first response byte is sent. Depending on the setup, it can also reflect redirects, TLS handshake overhead, cache misses, and backend work like database queries or template rendering.

That makes TTFB useful, but easy to misread. A CDN can improve it by serving cached HTML near the user, but if the origin is slow or cold, the number will still drift upward. On the other hand, a low TTFB does not guarantee a fast page, because JavaScript, images, fonts, and layout work still need to happen after the first byte arrives.

Think of it as the “how quickly did the stack wake up” metric. If the first byte arrives late, everything downstream starts late too.

Why page speed tools care so much

Page speed audits care about TTFB because it sits at the front of the waterfall. If that first block is slow, the browser cannot begin parsing HTML, discovering subresources, or painting anything on screen. In lab tools, that delay often shows up as a bigger gap before First Contentful Paint and Largest Contentful Paint.

Search and performance teams also watch it because it is one of the few timing signals that touches the full delivery chain. It can point to slow application code, overloaded infrastructure, cache misses, or a regional problem between the user and your server. When the number jumps, it is often the first clue that something under the hood is off.

For developers, the useful question is not “is TTFB bad?” It is “where is the wait coming from?” That is the part you can actually fix.

Common causes of high TTFB

High TTFB usually comes from one of a few places. The request may spend too long in DNS or connection setup, especially on cold visits. Or the backend may be doing heavy work before it can return HTML, like running database queries, building a large template, calling third-party APIs, or waiting on a slow auth check.

Serverless and container-based deployments can add their own flavor of delay. A cold start means the runtime has to wake up before it can do anything useful. That can be fine for low-traffic tools, but it is painful on a page that needs a fast first paint.

Caching changes the picture fast. If the HTML is cached at the edge, the browser gets a response sooner. If the cache is bypassed by cookies, headers, or personalization logic, the request falls back to origin and TTFB gets longer again.

Slow DNS: users resolve your domain slowly, especially on first visit.
Connection overhead: TCP and TLS setup add extra round trips.
Cold starts: serverless functions need time to spin up.
Database delay: one expensive query can hold the whole response.
Cache miss: the edge cannot serve a ready-made response.

How to read a TTFB number without fooling yourself

TTFB is useful only when you know what kind of request you measured. A homepage with cached HTML will behave differently from a logged-in dashboard that renders personalized data on every request. A nearby test server will also give you a different number from a real user on mobile in another region.

Use the number as a clue, not a verdict. If the checker reports 120 ms on one run and 480 ms on another, that can mean network variance, cache warming, or a backend that is only sometimes under pressure. Repeated tests from the same location are usually more helpful than one dramatic result.

It also helps to separate network time from server time mentally, even though the browser only exposes a single number. If the response starts quickly but the full page still feels slow, your issue is probably not TTFB. If the delay happens before any HTML shows up, then TTFB deserves your attention.

How to lower TTFB in real systems

The fix depends on where the delay lives. If the issue is transport overhead, move traffic closer to users with a CDN and keep connections warm. If the issue is backend work, reduce the amount of work needed before the first byte is sent.

Practical moves usually look like this: cache rendered HTML, cache expensive API results, trim redirect chains, simplify middleware, and avoid blocking on work that can happen later. For example, a page that waits for analytics, recommendations, and cross-service profile data before returning the shell is paying a tax it does not need to pay.

For server-rendered apps, stream what you can. Send the initial HTML shell first, then fill in slower parts after. Even a modest improvement here can make the page feel much sharper, because the browser gets something to chew on earlier.

// Example: return the base HTML first, fetch slower data later
app.get('/dashboard', async (req, res) => {
  const critical = await getUserShell(req.user.id);
  res.setHeader('Content-Type', 'text/html');
  res.write(renderShell(critical));

  const stats = await getDashboardStats(req.user.id);
  res.end(renderRest(stats));
});

That pattern is not always the right answer, but it shows the idea: stop making the first byte wait on everything. The earlier the browser gets HTML, the earlier it can start parsing and rendering.

If you are also trying to understand how the browser turns a request into a loaded page, our guide on what happens when you type a URL into your browser connects the dots nicely.

Where TTFB fits in a modern performance checklist

TTFB is one piece of the puzzle, not the whole thing. You still need to care about image size, script execution, font loading, CSS blocking, and layout stability. A page can have a decent TTFB and still feel clunky if it ships a mountain of JavaScript.

That said, it is a good early checkpoint. If your page feels slow and TTFB is high, you have already found a likely bottleneck in the request path. Fixing it often gives you a cleaner win than shaving a few kilobytes off a script bundle that loads later anyway.

It is also a handy metric when you compare environments. Production versus staging, cached versus uncached, edge versus origin, mobile versus desktop, same region versus distant region — those comparisons can show you whether the problem is the app, the infrastructure, or the route between them.

Real-World Example

Here is a simple before-and-after example for a server-rendered page. The app starts with a product page that waits on the database, inventory service, and recommendation service before it sends any HTML.

Before
------
Request:  /products/alpha-42
DNS:      18 ms
Connect:  32 ms
TLS:      41 ms
Backend:  612 ms
TTFB:     703 ms

What happened:
- product query hit a cold database cache
- inventory service timed out once and retried
- recommendations blocked the response
- the browser saw nothing until all of that finished

Now the page is rewritten to send the product shell immediately, render inventory from a cached value, and load recommendations after the first paint.

After
-----
Request:  /products/alpha-42
DNS:      16 ms
Connect:  29 ms
TLS:      38 ms
Backend:  94 ms
TTFB:     177 ms

What changed:
- product core data is cached for 60 seconds
- recommendations load asynchronously
- slow inventory lookups no longer block HTML output
- the first byte reaches the browser much earlier

The page is still doing work after the response starts, but the user gets something visible sooner. That is the practical goal: shorten the wait before the browser can begin.

Frequently Asked Questions

What is a good TTFB?

There is no universal magic number, but lower is better. For most normal pages, you want the first byte to arrive quickly enough that the page starts rendering without a noticeable pause. Treat anything that regularly creeps into the hundreds of milliseconds as worth investigating, especially on cached or otherwise simple pages.

Is TTFB the same as page load time?

No. TTFB only measures how long it takes to receive the first byte of the response. Full page load time includes everything after that: HTML parsing, CSS, JavaScript, images, fonts, and any extra requests the page makes.

Does a CDN improve TTFB?

It can, especially when the CDN serves cached HTML or static content close to the user. But if the CDN has to fetch from a slow origin, or if the page bypasses cache, the improvement may be small. A CDN helps most when the cache hit rate is high and the response is actually cacheable.

How do I test TTFB from my browser?

You can use a checker that measures the response timing for a URL and reports the first-byte delay. That gives you a quick read on whether the request is starting fast or getting stuck in the early part of the chain. For a simple check, use the Chunky Munster TTFB checker and compare a few runs.

The Bottom Line

TTFB tells you how long the browser waits before the server starts talking. It is not the whole performance story, but it is a sharp signal for backend latency, cache behavior, and network overhead. When it is high, the page has already lost time before rendering even begins.

If you are tuning a site, start by checking whether the response is cacheable, whether the backend is doing too much before the first byte, and whether the request path is adding avoidable latency. Then measure again. Small changes here often have a bigger feel-good effect than you expect.

When you want a quick read on a URL, give the TTFB checker a spin and see where the wait is coming from.

// try the tool

try our free TTFB checker →

// related reading

HTML Minifier: Reduce File Size for Faster Page Loads Speed Converter: mph, km/h, Knots, and Metres per Second Speed Calculator: Calculate Speed, Distance, and Time Instantly

← all posts