TTFB higher than LCP

[Joao Pedro]

I may know this is possible, but I want to ensure this is a real case. Does also may mean that the server had many rejections due to large TTFB(didn't even manage to load LCP) but had good ones, and the LCP was good in those.

Archived Pagespeed URL:https://pagespeed.web.dev/analysis/https-saltylemonkites-com-de-kite-abos/twz6r3aosw?hl=en&form_factor=mobile 

[Barry Pollard]

That's one possible explanation.

The other is that non-standard navigations are the cause of this. TTFB is currently marked as "experimental" (see the little beaker icon in your screenshot?) as it currently does not measure TTFB for some page loads, notably: bfcache navigations and prerenders. If you have enough of these, your LCP and FCP metrics might accurately reflect the fact that these are typically faster FCP and LCP (often instant!) and so bringing down the p75 value, while TTFB will only be the slower, full page loads.

This is noted in our documentation:

"TTFB is only collected on full page loads, unlike other timers (such as LCP) which are also collected on back-forward navigations and pre-rendering. As such, the sample size of TTFB can be smaller than other metrics and may not necessarily be compared directly with them."

It's arguable whether TTFB even makes sense for those page loads, but in my opinion it should record a 0-TTFB (this is what web-vitals.js does) so these metrics can more directly be correlated like you thought they would be. We would be interested to hear the community feedback on this, so we can prioritise the work for this, and hopefully then move TTFB out of experimental. Note, even after dropping the experimental label, this would still be a diagnostic metric - like FCP. There is no intention of making TTFB a Core Web Vital (it doesn't meet the criteria of directly measuring a fact of user experience, and LCP is a better loading metric), but it is a useful diagnostic metric from LCP.