GoogleChrome
Show unthrottled LCP phase values when using simulated throttling
FAQ
- [x] Yes, my issue is not about variability or throttling.
- [x] Yes, my issue is not about a specific accessibility audit (file with axe-core instead).
- [x] Yes, my issue is not answered by other FAQs.
URL
https://tamethebots.com/
What happened?
When running a pagespeed insights test, it seems that the TTFB in the phase section under the LCP report has a floor of 600ms, and it's impossible to get a lower value:
Other examples
-
https://pagespeed.web.dev/analysis/https-www-industrialempathy-com/mhdl1wnti2?form_factor=mobile
-
https://pagespeed.web.dev/analysis/https-www-scalemates-com/f0cihflwe7?form_factor=mobile
What did you expect?
An accurate representation of the TTFB value
What have you tried?
No response
How were you running Lighthouse?
PageSpeed Insights
Lighthouse Version
12.2.3
Chrome Version
No response
Node Version
No response
OS
No response
Relevant log output
I think this is the result of Lighthouse using simulated throttling by default. The throttling is interpolated and so we apply some base level RTT to the initial network request.
Your bug report does indicate that this is method of generating LCP phases is less than useful. Unfortunately, the alternative is to show LCP phases for the LCP value before throttling is applied, which means the LCP phases won't match with the LCP value. For accuracy reasons we should consider this.
In the meantime, you can use DevTools throttling (as opposed to simulated throttling) which shouldn't have this problem.
Hey @adamraine!
Thanks! I realised that I didn't explain in the ticket well that this is purely a pagespeed insights thing, it is possible to observe TTFB under 600ms in devtools or a node test, although I guess the throttling could be skewing that anyway?
Hmm yeah it's possible that the PSI environment also just has a more consistently slow TTFB. I have other accuracy concerns with the LCP phases though so I think we should consider showing the unthrottled values.