Use web.dev/fcp thresholds

[josephscott]

In May there were changes to the TTFB and FCP thresholds - https://groups.google.com/a/chromium.org/g/chrome-ux-report-announce/c/6soDVEEacPM/m/Ny6Z9hwgAgAJ

I'm unsure why the FCP values that were mentioned in there are being used:

FCP
fast: 1500ms (previously 1000ms)
slow: 2500ms (previously 3000ms)

Looking at https://web.dev/fcp/ the "good/fast" breakdown is 1,800 ms or less. Why the the 300 ms difference here?

[rviscomi]

Is the suggestion to change the slow TTFB threshold from 1500 to 1800?

[josephscott]

Perhaps I'm not seeing how https://ismyhostfastyet.com/ is related to the FCP changes. Based on the announcement post I'm trying to figure out what there are different thresholds for what constitutes a "good/fast" FCP number.

[rviscomi]

Generally, having a good TTFB makes it easier to achieve fast FCP/LCP. FYI the CrUX post you linked is from 2020 and has since been superseded by this update.

[styfle]

How about adding a toggle to switch between TTFB/FCP/LCP?

[rviscomi]

I think TTFB is the only metric that can be directly attributed to hosts. FCP/LCP are more measures of front-end performance, so it wouldn't necessarily be reflective of the hosts' back-end performance.

[styfle]

Maybe this section should be updated then because it still says "we plan to add more metrics"

[rviscomi]

Yeah good point. I think that section could be updated/removed. I think there is a very limited set of metrics that are relevant to attribute at the host level, and TTFB strikes me as the only metric that is both relevant to hosts and available in the CrUX dataset. If there are new metrics that we could add to CrUX that would enable better host-level insights, I'd love to see those suggestions in the CrUX discussion forum.