The CrUX Dashboard looks at origin-level data only.
Google Search Console (GSC) attempts to group pages into "page groupings".
So take for example a site and say it has the following page views:
- / (i.e. the home page) - 10,000 page views with passing CLS
- /blog/page1 - 5 page views with failing CLS
- /blog/page2 - 5 page views with failing CLS
- /blog/page3 - 1 page view with passing CLS
- /other - 1 page view with failing CLS.
In that case, the CrUX dashboard may show the CLS as passing because those 10,000 home page views are the vast majority of the whole origin.
However, GSC may show the following:
- Group 1 - 10,000 page views, including the home page with page-level data and /other without page-level data (as insufficient traffic). This group is passing CLS overall.
- Group 2 - the 3 blog pages with 3 example pages, all without page-level data (as insufficient traffic). There may also be 500 blog pages in total in those group but 497 of those aren't visited at all. This group is failing CLS overall.
Note, the CrUX team (of which I'm part) don't work on GSC and don't have any additional visibility into how it groups pages, so take the above (extreme!) example as just an example of our understanding of how they display this data.
So The CrUX Dashboard makes it look like everything is good, but GSC says one group is passing, one is failing, and that 500 our of 502 pages (99.6% of pages) on your site are failing (as 500 pages are in the failing group) and only 2 are passing. As I say, this is an extreme example with one page so heavily outweighing the others.
GSC is only available to site-owners that have verified their ownership, whereas the CrUX Dashboard is based on public data, and hence shows less detail.
By grouping pages into "groups", GSC is trying to be helpful to show you pages that likely have similar root causes so you can tackle them separately. For example, maybe it's your /blog pages that all can be fixed with one common fix to that page template to address the issue for all pages in that group. In my experience this usually works pretty well for well-trafficked sites.
However GSC's page grouping is also prone to confusing people too. For example, the following scenarios can be confusing:
- This (extreme) example, where CrUX and PageSpeed Insights says all is fine at an overall origin-level, but GSC says 99.99% of pages are not fine. Both are "correct" based on their view of the data, but it can seem contradictory and so confusing.
- When the example pages with sufficient traffic to have page-level data are passing, but the group overall is failing (as it's being dragged down by the long tail of other, slower, pages). Then the example pages aren't actually that helpful to diagnose issues!
- When the pages in a group are actually as similarly fast as other pages that are passing when tested, but they are just visited so infrequently they often are not cached on infrastructure and so take a bit longer to show to real users (compared to cached pages which display quicker for most users).
- When the pages in a group are actually as similarly fast as other pages that are passing when tested, but just so happen to be visited by users on slower connections/devices (e.g. if the blog article is for "the top cheapest mobile phones", then it might appeal to those currently using slower devices and hence the page does load slower for those readers).
I hope that helps and note all GSC questions will need to be directed at Search. Again, above is my understanding based on public documentation of how this works and my own experience.