[CrUX Announce] Important updates to the CrUX Dashboard

Today we released a big update to the CrUX Dashboard . It's a tool that helps you monitor real-user UX trends with no code/queries required, making it great for developers, execs, and SEOs alike.

To give it a try, visit  g.co/chromeuxdash . If you need any help getting set up, this (now outdated)  guide  has a still-relevant walkthrough to get you up and running.

Here's what included in today's update:

+ first-class support for Core Web Vitals

+ ability to drill down into desktop/phone experiences

+ many UX improvements

Important note for existing CrUX Dash users:  your older dashboards will continue to work but the densities might not add up to 100% for some charts. If you haven't made any major customizations to your dashboard, start over from g.co/chromeuxdash to generate a new dashboard with the latest features and UI.

Or if you'd prefer to keep your old dashboards, there's a workaround. In the editor, select the chart and for each Fast/Average/Slow metric click the pencil over "MAX" to change the aggregation function from MAX to SUM .  Voila!

If you have any feedback or issues with the new or old dashboards, please let us know in the discussion forum  or reach us on Twitter at @ChromeUXReport . We'd love to hear what you think!

Cheers,

Rick

One question thoug: Any chance you're gonna add P75's for all available metrics? Just seems somehow incomplete if they're only available for the core web vitals. 

Cheers 

Aaron

That's a great question. We initially wanted folks to focus on and optimize the Core Web Vitals, so those metrics were prioritized with P75s. Each of the CWV metric docs on web.dev have explicit percentile recommendations (for example, see LCP ), but this isn't the case yet for other metrics like DCL, OL, FP, or TTFB. The FCP docs  do recommend optimizing for the 75th percentile, so that might be a good candidate to get the P75 stat added.

Rick

Thanks for the response, makes perfect sense. I'd love to see P75 for FCP as we're using it as a supplemental metric to the Core Web Vitals to gain a bit more insight into the visual loading progression of our sites.

Looking forward to the next update :)

Cheers 

Hi Rick

You folks are doing a great job to align performance tools and metrics across RUM and synthetic. I just wanted some clarification on how up-to-date the pages were at https://web.dev/lighthouse-performance/ . It’s just that if you look at https://web.dev/interactive/ the target RAG rating does not match that of the lighthouse Scoring Calculator at https://googlechrome.github.io/lighthouse/scorecalc/ .

For example the document on TTI specifies that green (Fast) is for 5.2 sec and below. But the calulator goes green at around 3.8 sec. 

Kind regards,

It seems the TTI doc hasn't been updated yet with the v6 grade scale. I'll pass this on to the Lighthouse team.

Thanks Joe! Looks like that's been a typo for a long time now. I've submitted a fix in  https://github.com/GoogleChrome/web.dev/pull/3141

Brendan

I have a question about Notifications permission section in new dashboards... If a PWA is submitted as a app using Trusted Web Activity in play store, how does this report counts notification permission for those app users? As in TWA, users are auto enrolled in push notifications (that's my understanding)

Thanks,

Rockey

There is also a key discrepancy between the thresholds for FCP in PageSpeed Insights and Lighthouse.  The documentation at https://developers.google.com/speed/docs/insights/v5/about sets out the thresholds for FCP and Core Web Vitals. For FCP to be classified as good it has to be within 1 second.

When using PageSpeed Insights, if I hover over each of the measurements results for both lab and field after running a test, the message text that appears shows that the thresholds for each of the metrics matches the documentation at https://developers.google.com/speed/docs/insights/v5/about

However, looking at the scoring calculator, at https://googlechrome.github.io/lighthouse/scorecalc/ the classification of ‘good”, “green” actually applies to FCP within 2,360 ms, not 1 second. The ‘good” threshold for CLS and LCP in the lighthouse scoring calculator match the spec set out at ttps:// developers.google.com/speed/docs/insights/v5/about

Which is correct? Is the threshold for FCP 1 sec or 2.3 sec?

Documentation at https://web.dev/first-contentful-paint/ specifies 2 sec. I presume this page just needs to be updated. 

No progress to report just yet, but the right people are aware of this issue.

Thank you for staying on top of it.

Rick

That's correct, this is a known limitation in the CrUX Dashboard. If you want to drill down into device-specific p75 values I'd suggest querying the dataset on BigQuery. For example:

(This query processes under 100 MB.)

Hope that helps.

Rick

The data sources for the PSI and CrUX APIs are not updated at specific times, but rather as soon as the daily aggregations are ready, which could fluctuate day-to-day. So there is no definitive answer to which API is updated first.

Hi Rick