What do real users experience on your site?

Core Web Vitals are measured from real Chrome users, not a lab. This reads Google's Chrome UX Report for your origin and reports the p75 of LCP, CLS and INP: the field data Google actually uses.

Queries Google's Chrome UX Report for your origin. No page is fetched and nothing is stored.

How this check works

Shipwork asks Google's Chrome UX Report API for the field metrics of your origin: the 75th percentile of Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint, measured from real Chrome users over the last 28 days. It reports which metric is failing and by how much. Origins with too little traffic have no CrUX data, and the check says so rather than guessing.

What the Core Web Vitals check measures

The check reads Google Chrome UX Report field data for the site origin when that data is available. It reports the 75th-percentile values for Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS), plus the field-data period and device mix when returned. These metrics summarize real Chrome user experiences over a collection period; they are not a measurement from one visit you just made.

A separate Lighthouse lab run may also be requested and shown. Lab results are a controlled diagnostic snapshot and are not the same dataset as CrUX field data. If field data is unavailable, the report can say that traffic is insufficient and use a lab result when available. A missing metric is not proof that the page is slow.

LCP: time until the largest visible content element renders.
INP: responsiveness of user interactions.
CLS: unexpected visual movement during loading and use.
Field percentiles and, when available, separate mobile or desktop lab information.

How to interpret Core Web Vitals results

Read the value and status for each metric, not only the overall label. The displayed thresholds are Good below 2.5 seconds for LCP, below 200 milliseconds for INP and below 0.1 for CLS. Values beyond the good line need work; higher values can be poor. Google’s field assessments use page experience distributions and status categories, so a single lab run may disagree with the field report.

Field data reflects real users across a collection window and may combine page experiences at the origin level when page-level data is not available. Device mix and traffic patterns matter. When the report has no CrUX data, use the lab result to find likely causes but do not treat it as a replacement for the missing real-user measurement.

Prioritize the metric labeled poor or needs work, then examine its diagnostics.
LCP often points to the largest image, server response or render-blocking resources.
INP points to delayed interactions and long-running main-thread work.
CLS points to elements that move because space was not reserved.

Improve the metric that is actually failing

For LCP, identify the largest visible element and make it available sooner. A large hero image may need appropriate dimensions and compression; server response time and render-blocking resources can also delay it. For INP, inspect scripts that occupy the main thread during clicks or input, and break up or defer work that does not need to happen immediately. For CLS, reserve space for images, embeds and other content that loads after the initial layout.

Change one likely cause at a time and measure again. Lab opportunities can point to code or assets to inspect, but the change should be checked against field data when enough real-user data exists. A performance change that improves a synthetic run may affect mobile users differently from desktop visitors.

Example image dimensions: <img src="/hero.webp" width="1200" height="800" alt=""> reserves layout space; use accurate intrinsic dimensions.
Avoid lazy-loading the primary above-the-fold image when it is the LCP element.
Review third-party scripts and long tasks for interaction delays.
Use the image weight check to find oversized or inefficient images.

Field data, lab data and no-data results

Field data is collected from eligible Chrome users and summarizes what they experienced. It can take time for changes to appear and may not exist for low-traffic sites or individual URLs. The check may show origin-level information even when the exact URL has no published record. Treat the period and device mix as context for interpreting the numbers.

A Lighthouse lab test loads a page under controlled conditions and can provide actionable diagnostics even when field data is missing. It is a different environment and run, so values are not interchangeable. Use lab results to investigate; use field data to understand the real-user experience when available.

Site audit: includes vitals with broader technical checks.
Rendered check: browser-based rendering and page output.
Core Web Vitals on Shopify: platform-specific improvement context.

Questions

What is the difference between field and lab data?

Lab data (Lighthouse) is a single synthetic run. Field data (CrUX) is what real users experienced over 28 days, which is what Google uses for ranking.

Why does it say no data?

Google only publishes CrUX data for origins with enough real traffic. A new or low-traffic site has none yet.

What are good numbers?

LCP under 2.5s, CLS under 0.1 and INP under 200ms, at the 75th percentile, are the thresholds Google treats as "good".

What are good Core Web Vitals scores?

The common good thresholds are LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. These metrics describe loading, interaction responsiveness and visual stability. Read them with their field or lab context: real-user data summarizes a distribution over time, while a lab run is a controlled snapshot. Passing does not guarantee rankings.

Why does my Core Web Vitals checker show no data?

Chrome UX Report field data is available only when Google has enough eligible real-user measurements for the origin or page. Low traffic or limited Chrome usage can leave a site without published values. A missing record is not evidence that the site is slow. Use a Lighthouse lab run for diagnostics where available, then monitor field data as it accumulates.

What is the difference between Core Web Vitals field data and Lighthouse?

Field data summarizes real users’ experiences collected through Chrome over a period. Lighthouse lab data comes from a controlled test of a page and can expose likely performance causes. They answer different questions and can disagree because devices, networks, page state and user behavior differ. Use lab diagnostics to investigate and field data to understand actual user distributions.

Does Core Web Vitals use mobile or desktop data?

The report can include device mix or separate lab strategy information depending on what data is available. Field metrics represent collected user experiences, and the available dataset may not provide a complete device breakdown. Lab tests can run for mobile or desktop as controlled scenarios. Check the report’s context before comparing values between devices or runs.

How do I improve LCP, INP and CLS?

For LCP, investigate the largest visible element, server response and render-blocking resources. For INP, look for scripts and tasks that delay response to user input. For CLS, reserve dimensions for images, ads and embeds before they load. Use lab diagnostics to locate candidates, make measured changes, and check field results later because real-user data updates on its own collection schedule.

Keep reading

What this reads

Reads public pages from outside your network, the way a crawler does.
No signup, and nothing is stored on the free checks.
One of 83 checks across discovery, content, markup, trust and catalogue data.

83checks

0signups needed

0stored on free checks

Cool, just ran an audit and got some insights! Let’s see if I can fix them :)

Tenta Dev, @DevTenta

Whoah! this site is crazy, nothing to roast at all

Ainreek, @AinreekAI

cool as heck, tried it on my blog and the insights it gave are helpful and not bluff.

Refaat 🍉 (Mouse), @1Mouse__