---
title: "Time to First Byte (Help Center / Glossary / Metrics)"
canonical: "https://www.rumvision.com/help-center/glossary/metrics/time-to-first-byte/"
---

Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > [Help Center](https://www.rumvision.com/help-center/?format=md) > [Glossary](https://www.rumvision.com/help-center/glossary/?format=md) > [Metrics](https://www.rumvision.com/help-center/glossary/metrics/?format=md) > Time to First Byte

# Time to First Byte

Time to First Byte (TTFB) aims to measure the time between the start of a navigation (usually initiated by a user click) and when the first byte of the response was received by the browser.

> This metric is available in [RUM](https://www.rumvision.com/help-center/glossary/monitoring/real-user-monitoring/?format=md) & [synthetic monitoring](https://www.rumvision.com/help-center/glossary/monitoring/synthetic-monitoring/?format=md), but not in [soft navigations](https://www.rumvision.com/help-center/glossary/browser/soft-navigations/?format=md).

## Nuances of the Time to First Byte metric

It's sometimes thought that TTFB is limited to tracking the actual response time of the server. But there's more to it:

- **TTFB breakdown**  
     [See below](#ttfb-breakdown)
- **server side redirects included**  
     Even (server side) redirects are included in the TTFB, and (when it comes to Core Web Vitals) attributed to the TTFB of your pages;
- **client side redirects exclued**  
     When a client side redirect (via either JavaScript or meta refresh tags) is happening, the TTFB starts over again. [Twitter's way of (re)directing](https://www.rumvision.com/blog/does-twitter-tco-redirects-affect-your-ttfb/?format=md) users when clicking on an external link is an example here.
- **Single Page Applications**  
     If your site is a Single Page Application, there are [exceptions when it comes to tracking Core Web Vitals](https://www.rumvision.com/help-center/glossary/other/single-page-application/?format=md#core-web-vitals) across all page navigations.
 
### TTFB breakdown

The TTFB exists of multiple phases or components. By using the [attribution build](https://github.com/GoogleChrome/web-vitals#ttfbattribution) of the web-vitals JS library or a tool like RUMvision, you'll be able to see a breakdown of the TTFB metric.

The TTFB breakdown includes:

- `waitingDuration` (mostly redirects)  
     our thresholds: 120ms & 210ms
- `cacheDuration` (HTTP Cache and Service Worker mostly)
- `dnsDuration` (time to resolve the DNS for the requested domain)  
     our thresholds: 40ms & 70ms
- `connectionDuration` (time to create the connection to the requested domain)  
     our thresholds: 80ms & 140ms
- `requestDuration` (mostly time spent on the server a.k.a. server response time, see below)  
     our thresholds: 560ms & 980ms
 
These thresholds per sub-part are based on overal RUMvision data: 15% - 5% - 10% - 70% of the total TTFB.

### TTFB and server response time

In reality, site owners should expect most time to be spend at server side redirects and server response time. RUMvision data of our users is illustrating this as well. When it comes to server side redirects in combination with ads, [parallel tracking](https://www.rumvision.com/use-cases/making-sure-paid-traffic-has-the-best-page-speed-possible/?format=md) should be considered. When it comes to the server response time, we often notice blind spots in server side caching strategies of sites and shops.

Site owners can setup and [collect server timing](https://www.rumvision.com/help-center/monitoring/settings/custom-performance-timing/?format=md#server-timing) to easily debug your platform's time spent in running queries to your database, templating process, running plugins et cetera.

## Continue reading about Time to First Byte

Want to learn more about TTFB? Check the [web.dev TTFB](https://web.dev/articles/ttfb) article or continue reading over at [our blog](https://www.rumvision.com/blog/?tag=ttfb&format=md).