TTFB - misunderstanding about its measurement

[Bohdan Kladkovyi]

Hello guys! 
Could you help me please with one confusing piece of information that I got some time ago about TTFB measurement flow? 
in this article, you can find info TTFB applies to all requests, not just navigation requests.  

And now I am shocked because at the beginning of the article, you can find the next sentences:
Because TTFB precedes user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP), it's recommended that your server responds to navigation requests quickly enough so that the 75th percentile of users experience an FCP within the "good" threshold. As a rough guide, most sites should strive to have Time To First Byte of 0.8 seconds or less.

https://web.dev/ttfb/#measuring-resource-requests 

So, how I can understand that? 

TTFB is really measured throughout the page lifecycle? Or I got it the wrong way.

Thanks in advance! 

[Aymen Loukil]

Hello Bohdan,

TTFB (like other metrics) should be monitored both on domain-level and on page-level. TTFB is for the first HTML request. 

what matters the most is to monitor TTFB in the field (real users data). Here is how I do it, hope it will be useful:

1- I monitor the domain-name TTFB over time (monthly progress) for each device

 

In the above screenshot, Amazon.com domain TTFB progress on mobile.

2- I monitor the 75th percentile of my domain TTFB and how it is evolving

In the screenshot above we see Vinted.com P75th percentile increasing for mobile users.

3- Sort my top internal pages by TTFB so be able to prioritize the less performing ones

We see that the Amazon Music page has the worst TTFB distribution compared to other ones.

Screenshots are from Speetals. A tool I'm building to monitor users web performance : https://app.speetals.com/demo/project 

Aymen,

[Bohdan Kladkovyi]

Aymen Hello! 

Thanks a lot for your quick response :) 
Now I am not confused about TTFB measurement) 
Have a nice day!

Bohdan!

[Barry Pollard]

TTFB is quite an overloaded term and it can be confusing.

In terms of the CrUX data, TTFB refers to the TTFB of the original document request (including any redirects). This of this as page-level TTFB and it's an important metric as, until you get the page, you can't meet the other metrics, or load any other resources needed for them (CSS, Scripts, Images...etc.).

TTFB can also be measured on each resource - how long from the request of that resource until you get the first byte of that resource back. This can be useful to measure any latency in individual resources. For example if your LCP element is an image and you see it's slow despite the page having a fast TTFB and the LCP element being discoverable in that, then maybe it's due to a slow TTFB of that resource (which could be due to being on another domain, like an image CDN and thus requiring a new TCP/TLS connection).

But in general, when discussing TTFB in terms of web performance, it refers to the first bytes of the HTML document.

[Nilanjan Siromani]

Speaking from experience :

On our pursuit to reduce TTFB, we ended up doing a lot of things, until
we realised that our incoming traffic is going through 4 levels of ad server redirections.

The interesting thing is the calculation starts from the point users click on your link(in some page)
now if that link takes you via click tracking servers which sends 302, the latency of all those responses are all added up to TTFB
and also to FCP and LCP

Reducing 2 such click tracking servers helped up gain about 800ms on TTFB , LCP and FCP

[Tony “Tiggerito” McCreath]

103 early hints (supported by at least Cloudflare) have also muddied the water of TTFB. If their cache hits, they will return a very quick 103 that triggers the TTFB, but no HTML is returned at that time. I don't believe there is a way to track the true HTML response time when 103s are involved.

Because of this, and a few other solutions that cause good TTFBs without improving total HTML load time, I no longer focus on TTFB. 

It would be nice to have an HTML load completion time (does it have a name?), but I don't know how to get that, so I focus on FCP when analysing if server response times are an issue.