The API's frustratingly inconsistent, isn't it? that's because every call spins up a fresh Lighthouse instance - a single lab test subject to whatever server load that particular VM is dealing with at that moment. The web UI runs the same underlying tool, but Google's infrastructure tends to balance the request more gracefully, so you get fewer wild outliers.
A 57-second LCP screams timeout or throttling on the API test instance, not anything your actual page is doing. I've seen this happen repeatedly when the API backend is under heavy use, the test just stalls before it even finishes rendering.
The median-of-three approach that someone suggested isn't terrible as a quick workaround, but I'd argue you're better off ignoring the Lighthouse lab data entirely and pulling the CrUX field from the API response instead. CrUX gives you real-user metrics aggregated over 28 days - that's far more reliable than any single synthetic run. check if your API response includes the loadingExperience object, that's your CrUX data.
If you need a more systematic approach, I'd do this:
- call the API a few times (say 5-10) and throw out obvious timeouts.
- Compare the median of those remaining runs against the CrUX
LCP value.
- If the lab median is still way off, it's probably a throttling/network simulation mismatch - adjust the API's
strategy parameter or test from a different region.
That's how i handle it in my workflows, and it's saved me chasing ghosts.
