Core Web Vitals: CrUX field + Lighthouse lab

Core Web Vitals come in two flavours, and conflating them is how agencies end up arguing with clients about numbers. Crawl Cove keeps them separate and labels each honestly: lab data is synthetic and on-demand, field data is real users from the Chrome UX Report. Both live on the Pages / URL inspector, per exact URL, the workflow behind the Core Web Vitals Checker.

Lab vs field: what each actually tells you

Lighthouse lab (synthetic). A single controlled run against one URL, on demand. You click the lab button on the Pages inspector and Crawl Cove runs Lighthouse in a clean browser profile, separate from your everyday browsing. It is never run during a crawl, so it never slows an audit or skews politeness. Lab data is great for diagnosing why a page is slow and for testing a fix before it has enough traffic to show up in field data.

CrUX field (real-user). Aggregated, anonymised measurements from real Chrome users over the trailing 28 days, served by Google's Chrome UX Report API. This is what Google actually experiences, and what feeds page-experience signals. Low-traffic URLs simply won't have a CrUX record, and Crawl Cove caches that honest "no data" answer rather than inventing a green score.

What the Lighthouse lab needs (a browser you probably already have)

There is nothing to install for most people, and no terminal. The lab drives a Chromium-family browser already on the machine, in this order:

1. the Playwright chromium, if you happen to have one (Crawl Cove never installs it);
2. Google Chrome;
3. Microsoft Edge.

Edge is present on a stock Windows install, so on Windows the lab generally works out of the box. On macOS, install Chrome or Edge if you have neither.

With none of the three, the lab panel shows "Lighthouse skipped — no supported browser found" and offers the one-line fix: install Google Chrome or Microsoft Edge, then run the check again. Nothing crashes, and the crawl still completes on Tier-1 data. The lab button then runs Lighthouse against that exact URL on demand.

Enabling CrUX field data (free API key)

Field data needs a Chrome UX Report API key. It's agency-global and separate from Search Console: one key serves every client. Exact steps:

1. In Google Cloud Console, create a project (or select any existing one). Go to APIs & Services → Library and enable the Chrome UX Report API. From Crawl Cove 1.0.0 Search Console connects with one click and no project of your own, so unless you set one up for an older release, you will not have a project waiting here.
2. Go to Credentials → Create Credentials → API key. Then restrict the key to the Chrome UX Report API so it can't be misused elsewhere.
3. In Crawl Cove open Settings and paste the CrUX API key. It's stored encrypted via safeStorage.

Field data caches for 24 hours per (URL, form factor), with desktop and mobile tracked separately, so repeated inspections don't re-hit the API. Until the key is set, the field panel reads "CrUX API key not set" and, again, everything else on the page works normally.

Reading the two panels on a client call

Open the Pages inspector for the URL in question. The CrUX field panel shows the real-user verdict (or an honest "no data"), and the lab button gives you a fresh synthetic run to dig into. Because both sit beside the page's findings, GSC metrics, and index status, you can answer "why is this page slow, and is it costing us traffic?" live, in one place, using only free data sources.

Next

• Inspecting a URL: the Pages inspector where both CWV panels live, alongside findings, queries, and index status.
• Running your first audit: the Tier-2 rendered crawl pass, which since version 1.0.0 resolves a browser exactly as the lab does.
• Core Web Vitals explained: what LCP, INP and CLS actually measure, and the fixes that move each one.