Repository navigation
Lantern: Investigate unthrottled "fast-finish" request over-inclusion in LCP graph #17436
Description
Summary
When evaluating the 2026 Lantern golden trace dataset (#17411), unthrottled traces recorded on fast connections can cause Lantern's LCP graph to include unrelated network requests that finished before observedLcp only because the unthrottled network was near-instantaneous.
Problem
- Example outlier:
http://sfbay.craigslist.org/(wpt3gLCP1.2svs. Lantern simulated LCP5.2s). - Cause:
FirstContentfulPaint.getFirstPaintBasedGraph(used byLargestContentfulPaint.getOptimisticGraphandLargestContentfulPaint.getPessimisticGraph) includes any network request whose unthrottledendTime <= cutoffTimestamp(observedLcp), unless it is a low-priority image or a script whoseEvaluateScripttask ran aftercutoffTimestamp. - On a fast unthrottled VM (e.g. 10 Gbps), non-blocking resources, async fetches, or secondary assets often finish downloading before
observedLcp. When simulated under Slow 4G / 3G throttling, all of those requests are treated as prerequisites for LCP, significantly inflating the simulated LCP.
Investigation Ideas
- Explore tighter dependency pruning for
LargestContentfulPaint(e.g., tracing initiator/dependency chains from the actual LCP element/resource when known, or excluding non-render-blocking subresources that have no causal link to the LCP layout/paint). - Evaluate the impact on LCP accuracy across the 2026 golden dataset (
core/scripts/lantern/).
Activity
ChristopherPHolder commentedon Oct 27, 2026
For what it's worth I did some research on the lantern dataset and as far as i understand the issue and this is what i found.
Lighthouse loads the page once on a fast connection, then predicts how slow it would be on a slow phone network. It doesn’t reload the page. It takes the recording, slows every download and every bit of JavaScript down on paper, and reads off new timings.
To guess when LCP would appear on the slow network, Lantern considers all request that complete before LCP, assuming all of that was needed for LCP. Then it replays just those things on the slow network, and whatever finishes last is the predicted LCP.
On a very fast connection almost everything downloads instantly, so lots of unrelated requests finish before LCP just by luck: analytics pings, chat widgets, cookie-banner scripts, ad trackers. Lantern can’t tell those apart from the things LCP really needed, so it counts all of them. On the slow network they take much longer. If one of them happens to finish last, it becomes the predicted LCP, even though the image on screen showed up long before.
A better example that craigslist is ESPN
I guess will need to check older datasets to better understand if that is true or not and keep doing research. Also do i understand correctly that the dataset before this one was from 2019 so its a 7 year update