Feature request: provide full CRuX data in API

[Matt Zeunert]

Hi there,

It would be nice if the CrUX API supported more metrics and more granular histogram data.

For example, the BigQuery CrUX origin dataset includes metric data for onload, dom_content_loaded, first_paint, and ttfb (there's already a feature request for TTFB here https://groups.google.com/a/chromium.org/g/chrome-ux-report/c/TDUL1vy6Zhg/m/HLc2KIfcAQAJ).

BigQuery also breaks down e.g. FCP into 100ms buckets, showing a more detailed histogram than the current good/ok/poor breakdown.

Currently this data isn't available for individual URLs, and for origins it's only available through expensive BigQuery queries.

Regards,

Matt

[Rick Viscomi]

Thanks Matt, this is useful feedback.

To help with prioritization, is there any more you could say about how these features would be valuable to you if added to the API?

I also want to acknowledge that when we released the CrUX API in June 2020 we said we'd be looking into closing some of these BigQuery/API feature gaps. While it's taken longer than expected, feedback like this is helpful to remind us of the value to developers.

Thank you (and all other CrUX developers) for your patience and support!

Rick

[Matt Zeunert]

Thanks Rick,

I missed the "What's next?" section before.

While I'm asking for lots of new stuff, being able to access historical data would also be nice (though less important for me).

Use cases for the API features

1. Using histograms to understand amount of improvement needed and identify systematic differences

We have a "Good" LCP of 2.4s, but 12% of experiences are "Poor". We want to know how much work we'd need to do to improve those user's experiences.

"Poor" experiences might be easy to move to "Ok" if that means a 4.1s LCP, but if some users wait 15s for the LCP that likely requires more work. It could also point to systematic differences between experiences, like different LCP elements. Granular histogram data can provide insight into how easy an issue is to fix, and separate peaks could point to systematic variations in user experience.

2. Using histograms to track improvements within a Good/Ok/Poor bucket 

Histograms would also help estimate the impact of performance optimizations being rolled out, as well as assessing gradual improvements e.g. from a p90 LCP of 6s to 4s.

3. Using additional metrics to discern what's causing slow Web Vitals 

More metrics can also help understand the Web Vitals and what could work to improve them. TTFB would tell us whether slow FCP is due to server response time or render-blocking scripts. Fast FP but slow FCP could suggest that fonts or images are blocking content from rendering.

Or say we have LCP issues and are wondering whether it's caused by a slow image or by a cookie banner. The onload event could indicate whether our image is loaded. Or, if we know that certain code only runs after onload, that would tell is if this code might be causing the problems.

4. Using additional metrics + histograms to learn about user devices and networks

This is more of a personal idea I've had, and a bit more speculative.

A general problem with lab data is that we don't know what device settings to use to simulate a realistic user experience. It would be nice to have a distribution of device and network speeds we can use for testing, e.g. what kind of settings usually lead to p75 Web Vitals.

Additional metrics could help estimate things like network speed, e.g. if we know how much data has to be downloaded before the onload event then we can use that to put a lower bound on bandwidth.

[Rick Viscomi]

Hey Matt,

Thank you for the detailed feedback, this is super helpful and I'll forward it along to the team :)

Rick