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.