Understanding TTFB: How to Spot It on Your Site.

Few days ago, I came across a tweet that talked about performance and how poor performance can often be due to poor API design.

He basically said that performance issues are not usually caused by the frontend, but by the backend. I agreed, and I replied that one way to track and confirm this is by looking at a metric called TTFB (Time to First Byte). That reply quickly gained traction with a good number of bookmarks, and I saw the need to write this short article.

In this article, I’ll cover the WHAT, WHY, and HOW of TTFB.

WHAT

Time to First Byte (TTFB) is the time it takes for a browser to receive the first byte of response from the server after making a request.

A common misconception is that TTFB is just “server response time.” In reality, it’s more than that. It includes several steps that happen before the browser sees the first byte:

1. DNS Lookup – If DNS resolution is slow, it adds delay.
2. TCP Connection – Establishing the connection takes time.
3. TLS/SSL Negotiation – Secure connections add extra handshakes.
4. Server Processing – If the backend or database is slow, response is delayed.
5. First Byte Sent – Only after all the above does the browser get the first byte.

This is why slowdowns can come from many places and not just the server itself. A slow DNS, network latency, redirects, or heavy server processing all add up and increase TTFB.

In the image above, the green bar represents TTFB, while the blue bar shows the time it took for the browser to download the contents.

WHY

Why measure TTFB?

As we mentioned, server response time only measures how quickly the server processes and responds to a request. TTFB, on the other hand, captures the entire journey, from DNS lookup to response.

This matters because TTFB varies for every user, depending on their network conditions, location, and the server setup. It’s a very handy metric for understanding how users actually perceive the speed of your site.

By analyzing TTFB, you can:

• Identify where delays occur (DNS, network, server, etc.).
• Optimize accordingly to deliver faster web pages.
• Improve user satisfaction and reduce bounce rates.

It’s also worth noting that slow TTFB negatively affects SEO rankings. For those who prioritize discoverability, this makes TTFB even more important.

HOW

Using Chrome DevTools

You can easily measure TTFB with Chrome DevTools.

1. Visit the site.
2. Right-click and select Inspect.
3. Navigate to the Network tab.

Click on any file to see it's TTFB(shown as (waiting for server response))

⚠️ Note: Chrome DevTools results depend on your local network conditions and location. So, while useful, they don’t fully reflect the experience of all your users.

Using WebPageTest
For a broader, location-based perspective, tools like WebPageTest are more reliable.

1. Go to the site and enter your URL.
2. Once the test resolves, you can view the TTFB from the results:
3. For deeper insights, click on the waterfall chart.
4. This gives you a detailed breakdown of TTFB for individual files.

CONCLUSION

According to Google, websites should aim for a TTFB of 800ms or less.

• 0–800ms → Good
• 800–1800ms → Fair (needs improvement)
• 1800ms+ → Poor (users are likely to bounce)

There’s much more to say about how to improve TTFB (like caching, CDNs, server optimization, etc.), but since this is an introduction, we’ll keep it simple for now.

The key takeaway: TTFB is critical for site performance, and it directly affects metrics like LCP (Largest Contentful Paint) and FCP (First Contentful Paint), which we’ll cover in a future article.