In each animation frame, after presentation, the LCP algorithm will emit a new candidate (at most one) to the performance timeline if a new largest text or image was painted in that frame. But Chromium also tracks the "largest pending image" (the largest image still loading) and uses that image's size to determine if the new candidate is the largest. This means a slow-loading large image can prevent the emission of intermediate LCP candidates, and developers often find such candidates useful for understanding the loading progression. This behavior came up during Interop 2025 as a difference with other engines, and there was agreement to align on emitting at most one candidate per frame based on the set of painted image/text elements for that frame.Blink component
Blink>PerformanceAPIsWeb Feature ID
largest-contentful-paintRisks
Interoperability and Compatibility
No information providedGecko: No signal
WebKit: No signal
Web developers: No signals
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
No information providedDebuggability
No information providedWill this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
NoYeshttps://github.com/web-platform-tests/wpt/blob/master/largest-contentful-paint/performance-entry-sequence.htmlTracking bug
https://issues.chromium.org/issues/482261053Estimated milestones
| Shipping on desktop | 146 |
| Shipping on Android | 146 |
| Shipping on WebView | 146 |
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5167930847395840