TTFB Inconsistency

88 views
Skip to first unread message

Adam Dridi

unread,
Aug 2, 2022, 8:19:09 AM8/2/22
to Chrome UX Report (Discussions)
Hi,

It appears that there is some inconsistency for the thresholds for a 'good' TTFB score.

A recent update suggests -
"The new thresholds in the API and on BigQuery are 800ms and 1800ms." 
Which was updated on the web.dev page accordingly as well as the insights docs itself.

However, Lighthouse Performance audit TTFB page states - 
"This audit fails when the browser waits more than 600 ms..."

As well as the tooltip on the CrUX dashboard itself, when hovering over the Green/Good displays Good as  < 0.5s.

Out of curiosity it would be good to understand how the 800ms good threshold was formed, as has quite significantly increased since the 200ms days . As well as confirmation around the consistency across certain docs.

Thanks!

Rick Viscomi

unread,
Aug 2, 2022, 4:01:15 PM8/2/22
to Adam Dridi, Chrome UX Report (Discussions)
Hi Adam,

Could you share a screenshot of the CrUX Dashboard showing TTFB good as < 0.5s? It's 0.8 in the latest version so what might be happening is that you're using a copy of an older version. If you don't need an editable dashboard, you can always see the latest version by using the CrUX dash launcher to create a permalink.

Thanks for flagging the discrepancy with Lighthouse. They're measuring something slightly different, server response time, despite using the TTFB name. Still, I agree it'd be good to try to standardize on the same metrics and thresholds across tools. I've filed this issue to track the request.

Out of curiosity it would be good to understand how the 800ms good threshold was formed, as has quite significantly increased since the 200ms days .

Good find! We settled on 800ms after looking at how most sites were performing across the web. We wanted to pick a threshold that was generally achievable and also not likely to conflict with the main Core Web Vitals metrics, particularly LCP. For example, if LCP is good we don't necessarily want to distract developers by flagging a slow TTFB as being a high priority issue.


Rick

--
You received this message because you are subscribed to the Google Groups "Chrome UX Report (Discussions)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chrome-ux-repo...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chrome-ux-report/484ba247-c270-4ac4-ab96-b3abbcbf9482n%40chromium.org.
Reply all
Reply to author
Forward
0 new messages