What Are Core Web Vitals? – Definition and How It Works

Learn what LCP, INP, and CLS measure, their thresholds, and why field data differs from a lab score.

Core Web Vitals are a small set of user-experience metrics that Google treats as page-experience signals: loading, interactivity, and visual stability.

1. The Three Metrics

INP replaced First Input Delay, measuring the full latency of interactions across the page's life rather than only the first one.

2. What Each Actually Captures

LCP is the render time of the largest element in the viewport — usually a hero image, a video poster, or a large text block. It approximates "when did the page become useful".

INP measures the delay from an interaction to the next frame being painted. It captures main-thread blocking, which is usually caused by JavaScript execution.

CLS sums layout shifts not caused by user input. The familiar cause is an image without dimensions, or an advert inserting itself above content already being read.

3. Field Data Versus Lab Data

The distinction that resolves most confusion about conflicting scores.

Field data — real users' measurements, aggregated at the 75th percentile, across real devices and networks. This is what counts as a ranking signal.

Lab data — a synthetic run in a controlled environment. Reproducible, useful for diagnosis, and not the ranking input.

A page can score well in a lab test on a fast machine and poorly in the field, because real users are on slower devices and worse networks. When the two disagree, field data is the one that matters.

4. Measuring Them Yourself

new PerformanceObserver(list => {
  for (const e of list.getEntries()) console.log(e.name, e.startTime, e.value ?? '');
}).observe({type: 'largest-contentful-paint', buffered: true});

new PerformanceObserver(list => {
  for (const e of list.getEntries()) if (!e.hadRecentInput) console.log('CLS', e.value);
}).observe({type: 'layout-shift', buffered: true});

In a browser-automation context these are collectable at scale — which makes an interesting use case: measuring Core Web Vitals across many pages, or across competitors, as a dataset rather than a one-off audit.

5. Why This Is Relevant to Collection Work

Two directions, both practical.

As data to collect. Vitals measured across a set of sites is a genuine competitive dataset. It requires a real browser and realistic throttling to be meaningful — measurements from an unthrottled datacenter connection do not represent anything a user experiences.

As a property of your own collection. The same conditions that produce poor vitals produce poor scraping: heavy JavaScript, slow rendering, and layout shifts mean longer waits, more timeouts, and extraction that runs before content settles.

CLS in particular has a direct consequence: a page still shifting is a page whose coordinates are unstable, which is one reason coordinate-based clicking is unreliable and element-based interaction is preferred.

6. Common Causes and Fixes

7. Measuring Them Fairly

If you collect vitals as data, the methodology decides whether the numbers mean anything:

1. Throttle CPU and network to represent real devices.
2. Use a consistent viewport and device profile.
3. Measure repeatedly and report a percentile, not one run.
4. Record the conditions with the measurement.
5. Do not compare numbers taken under different conditions.
6. Prefer field data where a public dataset provides it.

8. Summary

Core Web Vitals are LCP for loading, INP for interactivity, and CLS for visual stability, with defined good and poor thresholds and a 75th-percentile field measurement as the ranking input.

Lab and field numbers diverge because real users have slower devices, so field data wins when they disagree — and for collection work the same conditions that produce poor vitals also produce timeouts and unstable coordinates, which is why element-based interaction beats coordinate clicking on shifting pages.

Potential Related Glossary

• Headless Browser
• Web Crawling
• Concurrency vs Parallelism
• Parsing