What Are Core Web Vitals and How Do You Check Them?

Core Web Vitals are three measures of real page experience that Google uses as a ranking signal: Largest Contentful Paint, or LCP, measures how fast the main content appears and is good at 2.5 seconds or under; Interaction to Next Paint, or INP, measures how fast the page responds to taps and clicks and is good at 200 milliseconds or under; and Cumulative Layout Shift, or CLS, measures how much the layout jumps around as it loads and is good at 0.1 or under. A page passes the Core Web Vitals assessment when all three are good at the 75th percentile of real visits.

The tool recommended here — Asad Webs' free Core Web Vitals Checker — runs a live check on any public URL using Google's free PageSpeed Insights service, straight from your browser with no sign-up: a Lighthouse performance score, lab metrics, and real-user field data when Google has enough of it for the page.

The three vitals, in plain terms

Largest Contentful Paint is the moment the largest visible piece of content — usually a hero image, a headline block or a main section — finishes rendering. It is the visitor's answer to “has anything loaded yet?” A page whose main content appears in 1.8 seconds feels fast; a page that shows a blank shell for four seconds feels broken, even if everything eventually arrives. Google's threshold is 2.5 seconds or under for a Good rating, measured on real visits.

Interaction to Next Paint is the delay between a visitor doing something — tapping a button, clicking a link, typing in a field — and the page visibly responding. It is the answer to “does this page react, or does it ignore me?” Long JavaScript tasks that block the main thread are the usual cause: the page looks loaded but cannot respond while a script hogs the thread. Google's threshold is 200 milliseconds or under for Good.

Cumulative Layout Shift measures unexpected movement: the button that jumps down a line just as a finger lands on it, the headline that shoves the paragraph aside when a late font arrives, the ad slot that expands and pushes the article. CLS is a score, not a time, and Google's threshold is 0.1 or under for Good. A page can be fast and responsive and still fail on CLS if its layout keeps moving under the reader's eyes.

How to check any page, step by step

Open the Core Web Vitals Checker, paste the full URL of the page you want to test — a missing https:// is added for you, or just type the domain to test the homepage — and pick Mobile or Desktop. Check Mobile first: most web traffic is mobile, the mobile test uses a slower simulated phone and network, and Google indexes mobile-first. A page can score 95 on Desktop and 60 on Mobile, and the mobile number is the one your visitors feel.

Press Run check and wait. Google runs a real Lighthouse test on its own servers, which usually takes 10 to 40 seconds, and the Run button stays disabled with a timer running so you know it is still working. Read the performance score first, then the lab cards: each metric shows Google's own display value plus a Good / Needs work / Poor chip based on Google's published thresholds. Then read the field-data section next — if the page has real-user data, those 75th-percentile numbers are what count for the assessment; if it does not, the tool says so plainly instead of guessing.

Fix the worst metric first, publish, then re-run the check to confirm the lab numbers moved — and give field data a few weeks of traffic before judging it, because field data is a rolling 28-day window of real visits, not a single test run. The tool's own worked example shows the pattern: a shop owner tests a homepage on Mobile and gets a score of 92 with LCP at 1.8 seconds and CLS at 0.04 — both Good — but Total Blocking Time over 600 milliseconds would flag Poor, pointing straight at heavy JavaScript as the thing to fix before touching images or fonts.

Lab data vs field data: why the two numbers disagree

Lab data comes from a single simulated load on Google's tester: a controlled phone, a controlled network, no real visitors. It is repeatable and diagnostic — it tells you what is slow and why, in a form you can act on. Field data comes from the Chrome User Experience Report, the aggregated experience of real Chrome visitors over a rolling 28-day window, reported at the 75th percentile: the value that 75% of visits beat. Field data is what the Core Web Vitals assessment actually uses, because it describes what visitors felt, not what a simulator measured once.

The two disagree for honest reasons. A lab test runs from one location on one network; real visitors arrive on every phone, connection and continent at once. A lab test loads a page cold; real visitors may have cached assets. A lab test has no real interactions, which is exactly why it cannot measure INP directly: INP needs a real person tapping and clicking, and a lab test has no real person in it. That is why the lab section shows Total Blocking Time instead of INP — how long JavaScript blocks the main thread is the accepted lab stand-in, since pages with low blocking time almost always respond quickly in the field. When Google's response includes its experimental lab INP audit, the tool shows that too, clearly labelled as a lab estimate.

Field data also has an honest gap: the Chrome User Experience Report only publishes a page once enough Chrome users have visited it over the rolling 28-day window. New, low-traffic or recently-moved pages show an honest “not enough real-user data” state instead of invented numbers. If the page has no data but its site does, the tool shows the site-wide origin numbers and labels them as such — a useful fallback, but not a substitute for the page's own data once it has traffic.

What to fix first, by metric

If LCP is poor, the main content is arriving late: the usual causes are a slow server response, a hero image that is too large or loads too late, or render-blocking scripts and stylesheets that delay the first paint. If INP — or its lab proxy, Total Blocking Time — is poor, JavaScript is blocking responses: long tasks, heavy third-party scripts, and unbroken bundles are the usual suspects, and breaking work into smaller tasks or deferring non-essential scripts is the fix. If CLS is poor, something is moving after it first appears: images without dimensions, ads without reserved space, and fonts that swap late are the classic causes, and reserving space for every element before it loads is the cure.

The order matters because the metrics interact. Cutting JavaScript often improves both INP and LCP, since the browser can paint sooner when it is not busy executing scripts. Reserving image dimensions costs nothing in speed and fixes CLS outright. And a fast page that still shifts under the reader's finger will still fail the assessment, so layout stability is not a cosmetic extra — it is one of the three pass conditions, and the easiest of the three to fix completely.

For the surrounding speed work, the same discipline that governs the rest of a site applies: every megabyte is a delay someone feels, which is why How to Speed Up a WordPress Website and How to Reduce Your Website Bounce Rate both start from measurement before redesign. Core Web Vitals give that measurement a standard form: three numbers, three thresholds, one pass condition. Run the check, fix the worst metric, re-run, and repeat — and judge the result on field data once the page has enough real visits to earn it.

Frequently Asked Questions

Sources: Asad Webs Core Web Vitals Checker tool page (Google's published thresholds, lab vs field explanation, TBT-as-INP-proxy, worked homepage example with score 92, LCP 1.8s and CLS 0.04, quota figure — verified live 2026-11-04); Asad Webs speed-up and bounce-rate guides linked in the text. Chart percentages are the example values divided by their Good thresholds (1.8 ÷ 2.5 = 72%; 0.04 ÷ 0.1 = 40%).