Someone runs a speed test on your site, gets a score of 54 and tells you it is slow. Another tool says 91. Neither number tells you what your visitors actually experience, and that is what Google uses.
Core Web Vitals are three measurements taken from real visits to your site. They are worth understanding because they describe problems people feel: waiting for the page, tapping a button that does not respond, and content jumping while it loads.
The three measurements
Largest Contentful Paint (LCP): how long until the main content, usually the biggest image or heading, appears. Good is 2.5 seconds or less.
Interaction to Next Paint (INP): how quickly the page responds when someone taps, clicks or types. Good is 200 milliseconds or less. It replaced First Input Delay in 2024.
Cumulative Layout Shift (CLS): how much the layout moves unexpectedly while people use it. Good is 0.1 or less.
A page passes when at least 75% of visits meet the good threshold for all three, measured separately for phones and desktops. The thresholds come from Google’s Web Vitals guidance.
Lab scores and real visits are different things
A speed score from a tool like Lighthouse is a lab test: one simulated visit on one device and connection. It is useful for finding causes, but it changes from run to run and does not represent your audience.
Field data comes from real Chrome users who visit your site, collected in the Chrome UX Report over a rolling 28-day window. It reflects their phones, networks and locations. When you want to know whether customers have a slow experience, field data is the answer.
What usually causes poor results
Slow LCP
Large images that are not resized for phones, slow server responses, fonts or scripts that block the page, and main images that load late because JavaScript adds them.
Poor INP
Too much JavaScript running at once, often from chat widgets, tracking tags and heavy page builders. The page looks ready but is busy and cannot respond to a tap.
High CLS
Images and embeds without reserved space, banners that push content down, and web fonts that change the size of text when they load.
Watch the trend, not one day
Because field data covers 28 days, a fix shows up gradually. A single bad week can also come from a campaign, a new plugin or a third-party script. Looking at the history week by week shows whether a change helped and catches slow regressions before they become a problem.
My free real-user speed history reads the Chrome UX Report History API and charts LCP, INP, CLS, FCP and TTFB for your site and a specific page, by device, with Google’s thresholds marked and the share of good visits each week. Sites with too little Chrome traffic have no public data, and the tool says so instead of guessing.
Is it worth fixing?
Core Web Vitals are one of many signals in Google Search, and they rarely outweigh relevant content. The stronger reason to fix them is your customers: a checkout that responds instantly and a page that does not jump under their thumb are simply easier to use.
If a metric is in the red, start with the pages that bring in money or leads. Measure, change one cause, and check the trend over the following weeks.
Getting help
Speed problems usually have two or three main causes rather than dozens. If your history shows poor results, send me the site and the pages that matter. I can find the causes, tell you which are worth fixing and make the changes.