core(interactive): also use LCP as bounds in observed metric #16173
Conversation
|
@adamraine please look again - I updated the PR since I noticed |
connorjclark
changed the title
connorjclark
changed the title
| const minTime = processedNavigation.timestamps.largestContentfulPaint !== undefined ? | ||
| processedNavigation.timestamps.largestContentfulPaint / 1000 : | ||
| processedNavigation.timestamps.firstContentfulPaint / 1000; |
There was a problem hiding this comment.
Not sure if it matters since this is TTI we're talking about (but that applies to making any changes at all, so... :), but seems bad to have this fallback? Makes the metric harder to reason about, discontinuous for an otherwise identical trace depending on if LCP was captured or not, and diverges from the lantern version, which throws if there was no LCP.
There was a problem hiding this comment.
I agree that the fallback in TTI can introduce inconsistencies. While it might seem like a minor detail, the discontinuity can complicate analysis and make it difficult to accurately compare performance across different scenarios. Perhaps we could explore alternative approaches, such as using a default value: If LCP is not captured, we could set TTI to a default value (e.g., the maximum possible value) to indicate that the metric is incomplete or even introducing a new metric: We might consider creating a separate metric that specifically measures time to first interaction without relying on LCP.
There was a problem hiding this comment.
So alternatively, we can throw if there's no LCP
and ignore this FCP fallback
#16046 changed this audit to use LCP instead of FMP, but incorrectly referred to FCP in a non-user facing doc comment.
Thanks to @csswizardry for pointing this out.
Also updates
findOverlappingQuietPeriods, used in the observed metric computation, which was still using FCP as the bounds. Now uses LCP to match Lantern (but I allowed for a fallback to FCP to still get something in the case LCP is missing).