Skip to content

Reland "LCP: Use largest painted image for web-exposed entry"#57666

Open
chromium-wpt-export-bot wants to merge 1 commit intomasterfrom
chromium-export-cl-7558997
Open

Reland "LCP: Use largest painted image for web-exposed entry"#57666
chromium-wpt-export-bot wants to merge 1 commit intomasterfrom
chromium-export-cl-7558997

Conversation

@chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented Feb 9, 2026

This is a reland of commit ec442fbb8bd40671c7094470747c870468191800.
The reland updates the html for the failing tests to wrap each image in
a div to prevent <body> from being an LCP candidate due to aggregated
whitespace (crbug.com/466437443), which breaks test assumptions.

Original change's description:

LCP: Use largest painted image for web-exposed entry

We track both a largest painted image and largest pending image for LCP.
The largest painted image corresponds to the largest image we have
presentation time for. The largest pending image is the largest image
we've encountered but don't yet have presentation time for, i.e. because
it's still loading.

The pending/painted distinction is used to prevent recording metrics for
pages that haven't finished loaded, but it also determines what gets
emitted to performance timeline (we test largest based on pending, not
painted). This causes us to suppress emitting new LCP candidates that
are smaller than the largest pending image, but larger than anything
presented so far, which is not specced behavior.

This CL changes it so that we emit candidates based on the largest
painted image instead of largest pending image. This does not affect
UKM/metrics. This matches the behavior agreed upon by the WebPerf
Working Group at TPAC '25.

Note: more changes are required for soft navs to match this behavior
since candidates can be overwritten during rendering/paint. This isn't
a problem for hard LCP since candidates are updated during presentation
callbacks, which are based on frame index.

Chromestatus: https://chromestatus.com/feature/5167930847395840

Bug: 454067883
Change-Id: I5275906769b07aca6c671c846756070333f2b09c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7269039
Reviewed-by: Michal Mocny <mmocny@chromium.org>
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1581252}

Bug: 454067883
Change-Id: Ib49860a2578c070a4ecd504b677d4c7ba02c847b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7558997
Reviewed-by: Michal Mocny <mmocny@chromium.org>
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1582017}

This is a reland of commit ec442fbb8bd40671c7094470747c870468191800.
The reland updates the html for the failing tests to wrap each image in
a div to prevent <body> from being an LCP candidate due to aggregated
whitespace (crbug.com/466437443), which breaks test assumptions.

Original change's description:
> LCP: Use largest painted image for web-exposed entry
>
> We track both a largest painted image and largest pending image for LCP.
> The largest painted image corresponds to the largest image we have
> presentation time for. The largest pending image is the largest image
> we've encountered but don't yet have presentation time for, i.e. because
> it's still loading.
>
> The pending/painted distinction is used to prevent recording metrics for
> pages that haven't finished loaded, but it also determines what gets
> emitted to performance timeline (we test largest based on pending, not
> painted). This causes us to suppress emitting new LCP candidates that
> are smaller than the largest pending image, but larger than anything
> presented so far, which is not specced behavior.
>
> This CL changes it so that we emit candidates based on the largest
> painted image instead of largest pending image. This does not affect
> UKM/metrics. This matches the behavior agreed upon by the WebPerf
> Working Group at TPAC '25.
>
> Note: more changes are required for soft navs to match this behavior
> since candidates can be overwritten during rendering/paint. This isn't
> a problem for hard LCP since candidates are updated during presentation
> callbacks, which are based on frame index.
>
> Chromestatus: https://chromestatus.com/feature/5167930847395840
>
> Bug: 454067883
> Change-Id: I5275906769b07aca6c671c846756070333f2b09c
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7269039
> Reviewed-by: Michal Mocny <mmocny@chromium.org>
> Commit-Queue: Scott Haseley <shaseley@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1581252}

Bug: 454067883
Change-Id: Ib49860a2578c070a4ecd504b677d4c7ba02c847b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7558997
Reviewed-by: Michal Mocny <mmocny@chromium.org>
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1582017}
Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The review process for this patch is being conducted in the Chromium project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants