| Code-Review | +1 |
painted image instead of largest pending image. This does not affect
UKM/metrics. This matches the behavior agreed upon by the WebPerfIs this meant to be "yet" or "by design"? IIUC because UKM only reports the final largest, and because we don't report if we still have a pending, it might not matter for UKM?
(Though I still would like to see more eager reporting.)
// Frame 1: paint three divs, with one being the largerst . This should producenit: largest
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
painted image instead of largest pending image. This does not affect
UKM/metrics. This matches the behavior agreed upon by the WebPerfIs this meant to be "yet" or "by design"? IIUC because UKM only reports the final largest, and because we don't report if we still have a pending, it might not matter for UKM?
(Though I still would like to see more eager reporting.)
By design / just noting that this isn't a behavior change for UKM and this won't affect metrics.
Right. Previously we would suppress emission of candidates that were smaller than the largest pending image but larger than the last emitted candidate. UKM knows about the largest pending image, so it's already up-to-date (but ahead of reality), and if the page unloads before getting presentation time for largest pending image, we don't report metrics.
---
Though I still would like to see more eager reporting.
I think we'd need to determine the benefit vs. work involved. There certainly may be some improvements we can make, but being able to clean up the web API without changing UKM was a pleasant surprise in terms of impact vs. work (though it was kind of a slog getting to this point...).
// Frame 1: paint three divs, with one being the largerst . This should produceScott Haseleynit: largest
I dunno, largerst sounds cool :P.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Exportable changes to web-platform-tests were detected in this CL and a pull request in the upstream repo has been made: https://github.com/web-platform-tests/wpt/pull/57210.
When this CL lands, the bot will automatically merge the PR on GitHub if the required GitHub checks pass; otherwise, ecosystem-infra@ team will triage the failures and may contact you.
WPT Export docs:
https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md#Automatic-export-process
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The exported PR, https://github.com/web-platform-tests/wpt/pull/57210, has failed the following check(s) on GitHub:
wpt-firefox-nightly-stability (https://github.com/web-platform-tests/wpt/runs/60607234407)
These failures will block the export. They may represent new or existing problems; please take a look at the output and see if it can be fixed. Unresolved failures will be looked at by the Ecosystem-Infra sheriff after this CL has been landed in Chromium; if you need earlier help please contact blin...@chromium.org.
Any suggestions to improve this service are welcome; crbug.com/1027618.
Gerrit CL SHA: 49a3ad1d521773a469b1facd52ef32fb8ac15dc9
Patchset Number: 7
| Commit-Queue | +2 |
I'm going land this now that the spec change landed. I'll send out a PSA next week.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
6 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: third_party/blink/web_tests/external/wpt/largest-contentful-paint/performance-entry-sequence.tentative.html
Insertions: 1, Deletions: 1.
@@ -26,7 +26,7 @@
window.LargestContentfulPaint, "LargestContentfulPaint is not implemented");
requestAnimationFrame(() => {
- // Frame 1: paint three divs, with one being the largerst . This should produce
+ // Frame 1: paint three divs, with one being the largest. This should produce
// a LargestContentfulPaint entry for text2.
container.appendChild(createDivWithText('text1', 'AB'));
container.appendChild(createDivWithText('text2', 'ABC'));
```
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
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |