chrome://ukm metrics, are these what go to CrUX

[Dave Smart]

Hi Folks

Not sure if this is even the right place to ask, but are the metrics you can see in chrome://ukm the ones that would make their way to CrUX, if applicable by the inclusion criteria?

[Annie Sullivan]

On Wed, Jul 27, 2022 at 11:38 AM Dave Smart <dsmart...@gmail.com> wrote:

Hi Folks

Not sure if this is even the right place to ask, but are the metrics you can see in chrome://ukm the ones that would make their way to CrUX, if applicable by the inclusion criteria?

Yes, that's correct. Note that:

a) Often metrics for a page load don't show up there until the page is unloaded

b) Initial navigations are logged in the "PageLoad" event and bfcache under the "HistoryNavigation" event, and these are blended in CrUX.

 

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/86dfbfc0-2871-4829-aba2-ab8e7fcc2a50n%40googlegroups.com.

[Dave Smart]

Thank you for the very quick reply, and the heads up for points a) & b), much appreciated!

Would it be expected that sometimes the LCP figures are different for some sites (a bit higher) than what you'd see in the PerformanceObserver API? It seems to be service worker related? 

An example would be for https://tamethebots.com, the PerformanceObserver reported 229.3.

After unloading the page, UKM reported 378


Perhaps I'm misunderstanding the figures though?

[Michal Mocny]

There are some reasons why the web perf API may not match:

• Images inside iframes
• Images which are Cross-origin and do not have Timing-Allow-Origin, and so are assigned a loadTime but not a renderTime

I just quickly tested the site you linked and found that Perf API, DevTools LCP timings, and UKM report, all matched no matter what I did.

-Michal

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/50929713-c6b2-49d0-826a-5ca2ef4c2882n%40googlegroups.com.

[Dave Smart]

Thanks so much for taking some time to look into this!

I see UKM / Devtools performance match, but I do still see a disparity between the Perf API and the UKM data , chrome  Version 106.0.5204.0 (Official Build) canary (64-bit), windows 10 

For example, the Web-Vitals extension output:  

The UKM for same load

Perhaps a canary / windows thing?

[Michal Mocny]

Could you compare which node was selected for LCP?

Since UKM and DevTools match, DevTools will highlight the element, and the perf API returns the `element`.

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/b6e3396c-8289-49b7-a6a7-477badb50878n%40googlegroups.com.

[Dave Smart]

Same both times, the headshot image

[Dave Smart]

Did a little more digging.

If the service worker is active, renderTime in the perf API is always 0. If you Bypass for network, it reports it again and therefore matched ukm figures.

So it appears that's the difference, and that UKM is "right" but the perf api only gets loadtime to work from.

I can recreate this behaviour on sites I've tried where the LCP is an image controlled by a service worker.

[Michal Mocny]

Thanks for helping identify this!  Filed https://bugs.chromium.org/p/chromium/issues/detail?id=1348001 to track fixing it.

(I confirmed that this image is failing TAO check when served from SW cache even though it should not.  I don't know enough about how SW network handlers work to know if this is specific to your SW implementation, or if it would always happen.)

Separately, Philip Walton noticed that in this case LCP == FCP, and we already have an issue to investigate cases like that specifically: https://bugs.chromium.org/p/chromium/issues/detail?id=1345948.

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/000cacc6-a02a-4dd1-bdd9-e1ef48fc82aan%40googlegroups.com.

[Dave Smart]

Thanks for the update and info, and filing the bugs!

I assume TAO is Timing-Allowed-Origin?

[Michal Mocny]

Yes, sorry, lingo :P

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/2c1a2454-2c87-4f71-994a-472365a60970n%40googlegroups.com.

[Dave Smart]

Very cool to see this is fixed in Canary!