Does anyone understand how GSC, Lighthouse, cruxvis calculate CLS, INP?

[Đào Hùng]

I am new to SEO, I am trying to fix the issues that GSC reported about my website.

After a lot of effort, 2 months of fixing, many times of expectation, the CLS, INP indexes have decreased but not significantly, it is still at yellow or red. (on mobile)

When I check with lighthouse, the indexes are very good, all are green. But the average index that google collects is still red or yellow (I guess this is the index collected from real user sessions)

What I am curious about is:

- Will google collect CLS during the entire session or just the page load time like lighthouse?

- What about INP index? it will be collected for the entire session / 1 certain time...

- how do i know which screens the index that google reports in GSC, cruxvis is a synthesis of? (this is necessary for me to continue troubleshooting the problem), because as of now, it only reports problems on the root page, I have worked a lot with the root page, and it seems to be fine, checking with lighthouse shows it is green, CLS and INP in the performance tab also shows no problems during use.

(the number of affected urls decreased, I think it's because the number of indexed urls of the site decreased, not because the problem was fixed, because recently, the number of indexed urls of the site decreased from 50k to 19k)


- my site has 2 domains, custom domain and default domain provided by azure, CLS, INP problems are only reported on the custom domain, on GSC of the default domain, there are no problems reported, all are green with thousands of green pages. what is going on?

default domain

custom domain

[Barry Pollard]

Quite a lot to unpack here!

- Will google collect CLS during the entire session or just the page load time like lighthouse?

CLS is collected during the entire lifecycle of a page but takes the worst burst of CLS as the metric score (so if you have a set of CLS that adds up to 0.2 during page load, and then much later another burst of CLS that adds up to 0.5 then your CLS score is 0.5 and not 0.9). Lighthouse therefore only captures that "load CLS" (0.2 in this examples). Pinning down post-load CLS can be trickier but there are some techniques to do so. In my experience scroll or hover effects are usually the cause of post-load CLS, especially when late loaded content is added without reserving space (for example scrolling down and lazy-loaded images load, or ads pop in).

- What about INP index? it will be collected for the entire session / 1 certain time...

INP is also measured throughout the life of the page and the longest Interaction to Next Paint is taken as the INP score (with some caveats on extreme outliers on really long lived pages). INP can definitely be trickiers to pin down, but again there are techniques to help with that.

For both measuring these in the field and logging the elements that shifted or were interacted with is really the best way. The Google tools like Google Search Console and CrUX Vis can only give so much information here, but RUM solutions (including using our own web-vitals library) takes the guesswork.

- how do i know which screens the index that google reports in GSC, cruxvis is a synthesis of? (this is necessary for me to continue troubleshooting the problem), because as of now, it only reports problems on the root page, I have worked a lot with the root page, and it seems to be fine, checking with lighthouse shows it is green, CLS and INP in the performance tab also shows no problems during use.

So the different tools present the Chrome User Experience Report data in different ways. PageSpeed Insights (PSI) and CrUX Vis give you URL-level data and origin-level data where available. We have various eligibility criteria, below which we cannot provide the data, but for origin level data we aggregate all page views. For example, you might have enough experiences to list your home page at URL-level but not your /blog or /help page. The original-level data would be all pages in the origin—so home page, and /blog, and /help pages and whatever other pages might be seen (including no-indexed pages that might otherwise be excluded from various other Search considerations and tools).

I can't authoritatively speak to Google Search Console (GSC) as that's managed by the Search team, but my understanding is they take a slightly different approach and group pages into Page Groupings. Page Groupings are calculated in a similar way to origin but with an attempt to classify them better to give a lower-level breakdown. To continue the above example, /home might be in one group, /blog might be in another (including pages like /blog/post1, /blog/post2...etc.) and so on. Again individual pages in a group may have individual data made available (and GSC links to PSI when that is the case) as well as be included in the group.

Origins and groups are weighted based on page views. So if /blog/post1 goes viral and gets a lot of page views and it is really slow, then it may weigh down your over all origin or group score compared to the other blog pages. Similarly if you have a lot of long-tail posts that are slow to load (e.g. because they are often not cached as they are visited infrequently), then they bring down your origin-level/group-level score because they all add up to a large portion of that origin/group's page views in aggregate compared to the faster pages.

Ultimately the aim is to represent how users experienced the site.

(the number of affected urls decreased, I think it's because the number of indexed urls of the site decreased, not because the problem was fixed, because recently, the number of indexed urls of the site decreased from 50k to 19k)

Sorry, this is outside of my area of expertise. But maybe my previous explanations will help explain it?

- my site has 2 domains, custom domain and default domain provided by azure, CLS, INP problems are only reported on the custom domain, on GSC of the default domain, there are no problems reported, all are green with thousands of green pages. what is going on?

I can't really answer further without further details. Are you saying both are built on the same technology and so you'd expect both to have similar Core Web Vitals scores? That would generally be the case, but do check they are the same. And the other big difference is that Core Web Vitals are a measure of what your users experienced. Say for example that your custom domain is visited primarily by a certain type of user that veers towards fast experiences. For example if you have intranet.example.com that's visited by your team on fast, desktop devices, with typically broadband connections, and then if you have customers.example.com that are visited by customers on all sorts of devices and network connections, then you would expect them to report different Core Web Vitals even if they were the exact same site.

And the important point is the aim is to represent how users experienced the site, and in this case the two different sites had two very different user bases and they ultimately had two different experiences of using the site.

Hope that helps explain some of what is going on here, and helps you narrow down potential reasons for the poor performance. If you have any more specific questions then let me know!

--
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 visit https://groups.google.com/d/msgid/web-vitals-feedback/66bdcc4e-8a72-4030-a9c1-66902024bf1en%40googlegroups.com.

[Đào Hùng]

Thank you for the answer

so, to investigate the issue related to CLS, INP, should I add https://web.dev/articles/debug-performance-in-the-field?hl=vi#usage-with-web-vitals-js to the source code so that it sends data to google analytics, then I can access google analytics to see the report in "Events"?

also, I have many questions about GSC, SEO, where can I ask it? I tried to find the related group but couldn't find it?

Vào lúc 16:07:21 UTC+7 ngày Thứ Năm, 15 tháng 5, 2025, barryp...@google.com đã viết:

[Barry Pollard]

so, to investigate the issue related to CLS, INP, should I add https://web.dev/articles/debug-performance-in-the-field?hl=vi#usage-with-web-vitals-js to the source code so that it sends data to google analytics, then I can access google analytics to see the report in "Events"?

Yes collecting field data is the best way in our opinion. Especially if you're struggling to understand your Core Web Vitals. The web-vitals library is one way to do that. There are also plenty of paid RUM solutions that do similar (and more) with user friendly dashboards and the like. But there's a cost associated with those, so if comfortable "rolling your own" by using the web-vitals library and looking at the data in Google Analytics or similar then that's a good option too.

also, I have many questions about GSC, SEO, where can I ask it? I tried to find the related group but couldn't find it?

I believe this is the best place to direct those questions:

https://support.google.com/webmasters/community?hl=en&sjid=10448356413288200697-EU

To view this discussion visit https://groups.google.com/d/msgid/web-vitals-feedback/adc73920-bef7-4d40-a0d9-ac1105f31274n%40googlegroups.com.

[Đào Hùng]

@Barry

is there any way i can collect event data grom Google Analytics?
currently in google analytics i can only see total number of events, total statistics, based on that it is very difficult to determine the real problem
i will need something like this to determine where the real problem lies
event_target | event_value

div..                |    0.02

span...           |    0.0004

Vào lúc 16:22:49 UTC+7 ngày Thứ Sáu, 16 tháng 5, 2025, barryp...@google.com đã viết: