Chrome UX Report: Core Web Vitals Lookup by Origin
Pricing
from $3.00 / 1,000 origin or page checkeds
Chrome UX Report: Core Web Vitals Lookup by Origin
Real-user Core Web Vitals for any site from the Chrome UX Report API: LCP, INP and CLS at the 75th percentile, good/poor shares, by device. Bring your own free Google API key. Check a prospect list, benchmark competitors, export to Sheets.
Pricing
from $3.00 / 1,000 origin or page checkeds
Rating
0.0
(0)
Developer
Adriana Voss
Maintained by CommunityActor stats
0
Bookmarked
3
Total users
2
Monthly active users
12 days ago
Last modified
Categories
Features
Share
Real-user Core Web Vitals for any website or page, straight from Google's Chrome UX Report: LCP, INP and CLS at the 75th percentile, the good / needs-improvement / poor share of visits, and a pass-or-fail verdict, by device. Paste a list of domains or page URLs and get one flat row each. This is the field data Google itself uses for the page-experience ranking signal, not a one-off lab test, so it is the right column to add to a prospect list, a competitor benchmark or an SEO report.
Bring your own free Google API key. Google only answers Chrome UX Report requests that carry a key, and this actor never ships or stores one. Creating your own takes a few minutes and no billing (steps below). Run it without a key and every row comes back as NEEDS_KEY with the signup steps; nothing is fetched and nothing is charged.
Related actors: for a lab test of one page (Lighthouse score, on demand) use PageSpeed Checker. This actor reports what real Chrome users experienced over the last 28 days.
Who uses it
- SEO and web agencies scoring a prospect list on Core Web Vitals before outreach ("your mobile LCP is 4.1 s, here is the fix").
- Growth and sales teams adding a performance column to a Clay, n8n or Make table.
- Product and engineering teams benchmarking their own origin against competitors, phone and desktop side by side.
- Reporting pipelines that pull the numbers into Sheets or BigQuery on a schedule.
How to use
- In the Apify Console. Open the actor page and click Start — the
originsfield is already pre-filled with a working example. Results land in the run's dataset as soon as each item is found. - Via the API. Call it directly with a POST request — no Console needed once you have an API token:
curl "https://api.apify.com/v2/acts/accountable_eel~crux-core-web-vitals-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \-X POST \-H "Content-Type: application/json" \-d '{"origins":["https://web.dev","https://developer.chrome.com"]}'
- On a schedule. Save this actor as an Apify Task with the input you want, then add a Schedule (hourly, daily, weekly) so it runs on its own — no server of your own required.
Get your free Google API key
- Open console.cloud.google.com and create a project, or pick an existing one.
- Under APIs & Services > Library, search "Chrome UX Report API" and press Enable.
- Under APIs & Services > Credentials, press Create credentials > API key and copy it.
- Paste it into the Your free Google API key field. It is masked and used only for this run's requests.
The key is yours and so is its quota: Google allows 150 queries per minute per project, free, and does not sell more. This actor stays under that by default (3 requests in flight, and a short pause and retry if Google answers 429).
Input
{"origins": ["https://web.dev","https://developer.chrome.com"]}
One per line. A bare domain or origin ("nytimes.com", "https://www.nytimes.com") returns the whole site's real-user Core Web Vitals; a full page URL ("https://web.dev/articles/vitals") returns that single page's, when Google has enough traffic on it. Accepted formats: nytimes.com (domain, checked as the origin https://nytimes.com), https://www.nytimes.com (origin), https://web.dev/articles/vitals (one page; needs enough Chrome traffic).
Set Device to PHONE, DESKTOP or TABLET to split by device (the default is all devices combined). A bare domain is checked as the whole origin; a path or query makes it a single-page lookup.
Output
One row per origin or page, for example:
{"query": "https://web.dev","found": true,"status": "OK","scope": "origin","formFactor": "PHONE","passesCoreWebVitals": false,"lcpP75Ms": 3078,"lcpRating": "needs-improvement","lcpGoodShare": 0.655,"lcpNeedsImprovementShare": 0.1957,"lcpPoorShare": 0.1493,"inpP75Ms": 202,"inpRating": "needs-improvement","inpGoodShare": 0.7443,"inpNeedsImprovementShare": 0.1934,"inpPoorShare": 0.0623,"clsP75": 0.05,"clsRating": "good","clsGoodShare": 0.7981,"clsNeedsImprovementShare": 0.1095,"clsPoorShare": 0.0923,"fcpP75Ms": 2973,"ttfbP75Ms": 1932,"collectionPeriodStart": "2026-09-12","collectionPeriodEnd": "2026-10-09","source": "chrome-ux-report-api (your Google API key)","sourceUrl": "https://chromeuxreport.googleapis.com/v1/records:queryRecord","scrapedAt": "2026-10-11T22:47:49.186Z"}
A real row (web.dev, phones, data window ending 9 October 2026). Columns Google has no data for (INP on a low-traffic site, for instance) are null, never 0. passesCoreWebVitals is true when LCP is 2.5 s or less, INP is 200 ms or less and CLS is 0.1 or less at p75, false when any of the three misses, and null when one of the three is unknown.
| query | found | status | scope | formFactor | passesCoreWebVitals | lcpP75Ms | lcpRating | lcpGoodShare | lcpNeedsImprovementShare | lcpPoorShare | inpP75Ms | inpRating | inpGoodShare | inpNeedsImprovementShare | inpPoorShare | clsP75 | clsRating | clsGoodShare | clsNeedsImprovementShare | clsPoorShare | fcpP75Ms | ttfbP75Ms | collectionPeriodStart | collectionPeriodEnd | source | sourceUrl | scrapedAt |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| https://web.dev | true | OK | <looked up as (origin or url)> | <device (all, phone, desktop, tablet)> | <passes core web vitals (lcp, inp and cls all good at p75)> | <largest contentful paint p75 (ms)> | <lcp rating (good, needs-improvement, poor)> | <lcp good share of visits (0-1)> | <lcp needs-improvement share (0-1)> | <lcp poor share (0-1)> | <interaction to next paint p75 (ms)> | <inp rating (good, needs-improvement, poor)> | <inp good share of visits (0-1)> | <inp needs-improvement share (0-1)> | <inp poor share (0-1)> | <cls rating (good, needs-improvement, poor)> | <cls good share of visits (0-1)> | <cls needs-improvement share (0-1)> | <cls poor share (0-1)> | <first contentful paint p75 (ms)> | <time to first byte p75 (ms)> | 1970-01-01T00:00:00.000Z |
A miss comes back as a row with "found": false and a status that says why, and is never charged: NEEDS_KEY (no key supplied), NOT_FOUND (Google has no record: too little Chrome traffic), BLOCKED (key rejected, API not enabled on the key's project, or over quota), BAD_FORMAT (not an origin or URL).
Pricing
- Origin checked: $6 per 1,000 origins or pages (cheaper on higher Apify plans)
Plus a $0.0015 start fee per run. Each event above is billed independently, only when it actually returns data. Misses (found:false), NEEDS_KEY rows and bad inputs are never charged.
Example runs
Paste any of these into the Input tab and press Start. They return rows once your own free Google API key is in the key field; with no key they return NEEDS_KEY rows at no charge, so you can see the shape first.
Two well-known origins, all devices. The default shape.
{"origins": ["https://web.dev", "https://developer.chrome.com"]}
A competitor list on phones, the device Google's ranking signal leans on.
{"origins": ["nytimes.com", "theguardian.com", "bbc.com"],"formFactor": "PHONE"}
One page against its whole origin, desktop.
{"origins": ["https://web.dev", "https://web.dev/articles/vitals"],"formFactor": "DESKTOP"}
FAQ
Why do I need my own key? Google gives no key-free access to the Chrome UX Report API. A key you create is free, has its own 150-per-minute quota, and keeps the cost of your lookups with you rather than a shared account.
Why did a row come back NOT_FOUND? Google only publishes origins and pages with enough real Chrome visitors, and a small site may have data for all devices combined but not for phones on their own. Try the origin instead of a page, or set Device to all devices.
Where does the data come from, and how fresh is it? From Google's Chrome UX Report, aggregated over a rolling 28-day window. collectionPeriodStart and collectionPeriodEnd on each row give the exact dates.
Is the key stored or returned? No. It is sent only as a request header to Google for this run, never put in a URL, a log line or an output row.
This actor runs synchronously over plain HTTP — call it directly from a script, a workflow tool, or an AI agent, no Apify Console needed once you have an API token.
curl "https://api.apify.com/v2/acts/accountable_eel~crux-core-web-vitals-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \-X POST \-H "Content-Type: application/json" \-d '{"origins":["https://web.dev","https://developer.chrome.com"]}'
n8n. Add an HTTP Request node: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~crux-core-web-vitals-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body Content Type JSON, JSON Body {"origins":["https://web.dev","https://developer.chrome.com"]} (swap in an expression from an earlier node for a real value).
Clay. Add an "HTTP API" column: Method POST, URL https://api.apify.com/v2/acts/accountable_eel~crux-core-web-vitals-lookup/run-sync-get-dataset-items?token=<YOUR_TOKEN>, Body {"origins":["{{origin or page}}"]}, mapping the row's origin or page into the origins array.
MCP. In Claude, Cursor, or any MCP client with the Apify MCP server, ask for "chrome ux report core web vitals api" — the agent will find and run this actor.