Non-reliable CrUX API responses: on every query different data missed

[E. O.]

I query 100 URLs, one by one, and in batch. On querying, not depending of how i query, i get  sporadically 404 errors, and on each query on some URLs are missed metrics data - but on each query there are different data missed.

Is the API non-reliable? What can i do to get reliable data?

[Rick Viscomi]

It's normal if the API responds with "code: 404" if there is no data for the given URL. For example:

CrUXApiUtil.batch([{url: 'https://httparchive.org/'}, {url: 'https://www.example.com/'}]).then(console.log)

[

    {

        "error": {

            "code": 404,

            "message": "chrome ux report data not found",

            "status": "NOT_FOUND"

        }

    },

    {

        "record": {

            "key": {

                "url": "https://www.example.com/"

            },

            "metrics": { ... }

        }

    }

]

Because the URL https://httparchive.org/ doesn't currently have sufficient data, an error object is returned instead. We can verify this by running the URL through PSI: https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fhttparchive.org%2F

"Field Data: The Chrome User Experience Report does not have sufficient real-world speed data for this page."

You could test a few failing URLs individually to verify that it's an insufficient data issue.

As for some results missing metrics, this can happen for various reasons. FID depends on a user interaction so it is especially prone to having insufficient data at the metric level. In other words, most page views will have an LCP event, but only a subset of them also have a FID, because users don't necessarily interact on every page view.

Other metrics like LCP or CLS could be missing due to some users being on older versions of Chrome before these metrics were supported, or users abandoning the page early. While usually rare, these factors could make the difference between having data or not for pages/origins that are right on the sufficient data threshold. If you're testing hundreds of URLs, you may be more likely to run into edge cases like these.

Hope that helps.

Rick

[E. O.]

Yes, it helps, thank you.