Core Web Vitals are three measures of page experience: loading, responsiveness and visual stability. Start by finding which measure is weak, then investigate the element or interaction behind it.
A kitchen-appliance product page can show its main photo late, hesitate when someone selects a model, and move the buy button when a stock banner appears. These need different fixes.
What Are the Three Core Web Vitals?
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP Largest Contentful Paint | When the largest visible image or text block appears during loading | 2.5 seconds or less | Over 4 seconds |
| INP Interaction to Next Paint | Responsiveness from a click, tap or key press to the next screen update | 200 milliseconds or less | Over 500 milliseconds |
| CLS Cumulative Layout Shift | Unexpected movement of visible content; a unitless score | 0.1 or less | Over 0.25 |
Values above “good” but below the “poor” range need improvement. The assessment uses the 75th percentile of measured visits: at least three out of four must meet the good threshold for that metric. Mobile and desktop are assessed separately.
INP covers interactions throughout a visit, not just the first tap. It represents the slowest interactions, with an allowance for outliers. It measures when the browser can show feedback, not how long every background request takes to finish. INP replaced First Input Delay (FID), so older FID charts are no longer the current three-metric list.
Why Do Core Web Vitals Matter?
They make an experience problem easier to describe and test. A fast-loading page can still respond slowly to its filters, while a responsive page can still move content as someone reads.
Google uses Core Web Vitals in its ranking systems, but good values do not guarantee high positions. Relevant, useful content remains essential. Use the metrics to improve the visitor's task, rather than treating a green badge as a traffic forecast.
Why Do Speed Numbers Differ?
PageSpeed Insights presents field data from eligible Chrome users over a rolling 28-day period, and lab data from a controlled Lighthouse run. Field data describes recorded visits; a lab run helps reproduce and diagnose problems under particular test conditions.
Check whether the field result is for the URL or the whole origin. Origin data combines pages under the same address, such as https://shop.example.com, rather than describing only the page you entered. A page with too few samples may fall back to origin data; if that is also insufficient, no field result appears. A missing reading is unknown, not a pass.
In a mobile PageSpeed Insights check of SEOWithJack's homepage on 8 October 2026, Lighthouse Performance was 97, while the real-user section showed “No Data.” That report supported lab diagnosis but could not establish a Core Web Vitals field pass.
The usual Lighthouse loading test does not perform the shopper's interactions. Its Total Blocking Time (TBT) can point to responsiveness problems, but it is not INP.
Search Console complements these tests by grouping similar indexed URLs with enough field data. A group's status does not mean every page has an identical result.
Read the Three Signals on One Page
On the appliance page, the product photo may be the LCP element. Confirm that in the report before blaming the biggest image file. The slow model selector is an interaction to reproduce for INP. A stock banner that loads unexpectedly above the details may explain CLS. Movement immediately following a user action is not always counted, so inspect the recorded shift rather than treating every animation as CLS.
Keep the problem separate from its suspected cause. “The photo appears late” is an observation; “the file is too large” is a theory until you inspect its request and rendering. Our image guide covers delivery choices once you know an image needs work.
How Should You Check a Page?
- Choose the page and device. Use an important product, service or article page. Record its exact URL, device type and test date so later results are comparable.
- Read the field result first. In PageSpeed Insights, choose Mobile or Desktop. Under “Discover what your real users are experiencing,” record the data scope and each metric's status. Keep “No Data” separate from “Good.”
- Investigate loading. In the diagnostic section, open “LCP breakdown” to identify the element. For an image, distinguish server waiting time, the delay before its request starts, download time and rendering delay. This shows why compression alone may not solve a late image.
- Try the problem interaction. In Chrome, right-click the page and choose Inspect to open DevTools. Select Performance and use the page's model selector. Inspect the Interactions tab for timing and the affected element; use Layout shifts to find movement. These are local measurements, so reproduce the issue on a real phone where possible.
- Fix and verify. Change the confirmed cause, retest the same page and action, then check other pages using the affected template. After release, monitor field data and the relevant Search Console group. The rolling window still includes older visits.
What Should You Fix First?
Start with poor metrics on important pages or problems shared across many URLs. Use the measured cause to choose the change:
- LCP: if the main image request starts late because it is lazy-loaded, load that image promptly. If the request itself is slow, inspect image delivery; if the server response is slow, investigate the server. Different delays need different fixes.
- INP: identify the work delaying the next visual response. A developer may need to reduce or split long JavaScript tasks and expensive rendering.
- CLS: reserve space for images and late components. Check what caused the movement: the button that shifted may be the victim of a banner inserted above it.
For the stock-banner issue, a useful developer brief would be:
On the mobile product template, the stock message loads after the product details and pushes the buy button down without the shopper doing anything. Reserve space for that message before it loads. Retest the same product and a second product using the template, including different stock states. Confirm the button stays in place and product selection still works.
Save the test conditions, before-and-after readings and release date. Repeat comparable lab runs to check that a change is consistent. Confirm that the visitor can still complete the task, then look for improvement in subsequent field data.
Frequently Asked Questions
What Are LCP and CLS?
LCP measures loading of the largest visible content element; CLS measures unexpected layout movement. CLS is a score, not a duration. INP is the third metric and covers responsiveness to interactions.
How Do You Pass the Core Web Vitals Assessment?
When all three have sufficient field data, each 75th-percentile value must be good. PageSpeed Insights can assess LCP and CLS alone if INP data is insufficient. If either LCP or CLS lacks enough data, it cannot make the assessment.
How Do I Check Core Web Vitals?
Use PageSpeed Insights for available page or origin data and lab diagnosis. Use Search Console to find affected URL groups. If field data is missing, test real tasks locally while waiting for enough samples; do not label the page as passed.
What Causes Poor Core Web Vitals Scores?
Late content delivery can hurt LCP, work that blocks visual feedback can hurt INP, and unreserved space can cause CLS. Identify the element, interaction or shift before changing the template.