Your agency sends a screenshot of a green circle with a score of 94 and writes, “The site is faster now.” A month later, Search Console still lists some pages as “Need improvement,” and your sales team hears from customers that the order button “jumps” on their phones. All three can be true at once, because they describe different pages, devices, and data sources.
Core Web Vitals are three metrics: LCP, INP, and CLS. Each one needs four pieces of context: which page, which device, where the data comes from, and what period it covers. Together they help you check whether visitors see the main content quickly, whether the page responds quickly when they tap or click, and whether the layout stays put while they use the page. On their own, they don’t prove that sales were lost or gained.
This article explains how to read the report, brief your developer, and sign off on the fix.
What LCP, INP, and CLS measure
Core Web Vitals is Google’s name for three metrics. Each describes a different part of the visitor experience: how the main content loads, how the page responds to input, and how stable the layout is. They don’t add up to a single “overall speed.” A page can show its content quickly and still respond slowly to taps.
LCP: when the largest element appears
LCP (Largest Contentful Paint) shows when the largest element counted by the metric was rendered on screen. The clock starts when the visitor begins navigating to the page. The metric counts images, video poster frames, background images loaded through CSS, and blocks of text. On a product page, for example, that element is often the main photo or a hero banner.
LCP doesn’t mean “when the price appeared” or “when the button became usable.” If the largest element is a photo, the metric describes the photo.
Example: on a mobile category page, the menu and filters appear first, and the large promo banner shows up a few seconds later. The visitor stares at an empty space where the banner should be.
INP: how quickly the page responds
INP (Interaction to Next Paint) measures the delay between a visitor’s action and the next screen update that shows a response. It counts mouse clicks, taps, and key presses; scrolling and hovering don’t count. While the page is open, the browser records the delay for every such interaction, and the result is the longest one. On pages with many interactions, the single longest delay is dropped for every 50 interactions, so one outlier doesn’t define the score.
INP measurement ends as soon as the screen first changes in response to the action. It doesn’t measure how long the server took to process an order. If a loading spinner appears right after a click but the operation takes three seconds, INP can still be good even though the customer waits. Those are two separate problems.
Example: a visitor taps “Add to cart,” nothing happens for half a second, they tap again, and two items end up in the cart.
INP replaced FID as a Core Web Vital in March 2024. If your agency’s report still relies on FID, it uses an outdated set of metrics.
CLS: whether elements shift unexpectedly
CLS (Cumulative Layout Shift) scores unexpected movement of page elements. It’s a unitless number: for each shift, the metric considers how much of the screen moved and how far elements traveled. Shifts that happen close together are grouped, and the score reflects the largest group. Movement within half a second of the visitor’s tap, such as a list expanding, isn’t counted.
Example: on a mobile product page, the photo loads without reserved space, everything below it shifts down, and a finger reaching for “Buy” lands on “Shipping.”
Thresholds
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP, seconds | LCP ≤ 2.5 | 2.5 < LCP ≤ 4 | LCP > 4 |
| INP, milliseconds | INP ≤ 200 | 200 < INP ≤ 500 | INP > 500 |
| CLS, unitless | CLS ≤ 0.1 | 0.1 < CLS ≤ 0.25 | CLS > 0.25 |
These thresholds follow the Web Vitals overview and PageSpeed Insights. They apply to the 75th percentile of page loads, measured separately for mobile and desktop. Search Console labels the middle range “Need improvement.”
Where to find the metrics and what data you’re looking at
Two Google tools are enough for a business owner: PageSpeed Insights for a single page and the Core Web Vitals report in Search Console for groups of pages.
PageSpeed Insights: field data and a lab test
A PageSpeed Insights report has two parts that people often mix up.
The top part shows field data from real visits. It comes from CrUX (the Chrome User Experience Report): anonymized measurements from Chrome users on desktop and Android who have opted in to sharing usage statistics. Visits from iPhones and other browsers aren’t included. The data covers the last 28 days and updates daily as a rolling window. This is where you find INP and the overall Core Web Vitals assessment.
The bottom part is a Lighthouse lab test. It’s a single page load on a Google server that simulates a mid-range phone on a mobile network or a desktop computer on a wired connection. The test helps pinpoint causes and quickly re-check after changes, but it doesn’t describe your visitors and has no real interactions, so it doesn’t report INP.
Mobile and desktop results are separate. Start with whichever one most of your visitors use.
A single page or the whole origin
If CrUX doesn’t have enough visits to a specific page, PageSpeed Insights may show data for the origin instead. An origin is the combination of protocol, domain, and port, such as https://shop.example.com. Origin data combines visits to every page within those boundaries. https://example.com and https://shop.example.com are different origins, and so are the http and https versions.
When the data covers the whole origin, the report you receive should say so plainly: “data for the whole site; this page wasn’t assessed on its own.” A good origin result doesn’t prove that your checkout page performs well.
If there’s no field data
An empty field data section means no field data is available for this page. The reason may be too few visits, or the page may not meet the CrUX eligibility criteria, for example because it’s blocked from indexing or not publicly accessible. The absence of data says nothing about speed. You still have the lab test and your own measurements, if the site collects performance data from visitors’ browsers through a monitoring tool.
The Core Web Vitals report in Search Console
The Core Web Vitals report uses the same field data but groups similar pages together. For a site with hundreds of product pages, that’s easier than checking URLs one by one. Mobile and desktop data are reported separately. A group’s status is determined by its worst metric: if LCP is “Good” and CLS is “Poor,” the group is rated “Poor.” If LCP or CLS doesn’t have enough data, the group is left out of the report, and its absence isn’t a rating either.
How to read the score without jumping to conclusions
What the 75th percentile means
Imagine lining up every load of a page over 28 days, from the fastest LCP to the slowest. The 75th percentile is the value three-quarters of the way along that line. An LCP of 2.3 seconds means that in 75% of page loads the largest element appeared within 2.3 seconds, and in the rest it took longer. An average could hide slow loads behind fast ones.
According to PageSpeed Insights, a page passes the Core Web Vitals assessment when all three metrics are “Good” at the 75th percentile. If even one metric falls outside that range, the assessment fails. The exception is INP: if there isn’t enough interaction data, good LCP and CLS are enough to pass, but in that case nobody has assessed how the page responds to input.
A Lighthouse score isn’t a Core Web Vitals assessment
The number from 0 to 100 inside the circle is the lab test’s performance score; green means 90 or higher. The score is calculated from several lab metrics, including LCP and CLS but not INP. A score of 94 means one test load under set conditions went well.
The Core Web Vitals assessment is based on real visits, so the two can disagree in either direction. The lab score can be high while field data is poor, for example when visitors’ phones are slower than the simulated device, or when scripts that didn’t run during the test fire for real visitors. The reverse also happens. Either way, the cause needs its own investigation.
The lab report also includes TBT (Total Blocking Time), which measures the total time long tasks block the browser’s main thread: for each task longer than 50 milliseconds, the time beyond those 50 milliseconds is counted. TBT helps track down the causes of poor INP, but it’s a different metric and shouldn’t be labeled as INP.
Illustrative example: one report, two conclusions
Illustrative example. The figures are hypothetical, for illustration only.
| What the report shows | Value | Correct reading |
|---|---|---|
| Lab performance score, mobile | 94 | The test load went well |
| Field LCP, mobile, 75th percentile | 3.6 s | “Needs improvement” range |
| Field INP, mobile | 180 ms | “Good” range |
| Field CLS, mobile | 0.05 | “Good” range |
| Source of field data | Origin | The whole site was assessed, not this page |
The mobile Core Web Vitals assessment fails because of LCP, and that result applies to the whole origin. “We scored 94” doesn’t change that. The next step is to find out which page types have slow LCP.
Common mistakes: comparing a “before” lab result with “after” field data; judging the mobile experience by the desktop result; treating origin data as page data; drawing conclusions about sales from a change in a single metric.
Which pages to check first
The homepage isn’t always the most important page. Visitors from search and ads often land directly on a category, product, or service page; leads come in through forms, and orders through the cart. We recommend prioritizing by four factors:
- Role in the customer journey: pages on the path to a lead or order, such as landing pages, categories, product pages, service pages, the cart, and forms.
- Template: a problem in a template repeats across many pages, and a fix can help all of them; the groups in Search Console make this visible.
- Observed problem: field data outside the “Good” range, customer complaints, or a session recording that shows a shift or delay.
- Share of traffic, based on your analytics.
Start with key pages that already show a problem; template and share of traffic help you choose among them. These factors organize the work, but they don’t estimate how much revenue each fix will bring in.
How to turn a report into a developer task
A red metric is a symptom, not a cause. Slow LCP can come from a slow server response, a heavy image, a late-loading hero photo, render-blocking styles, or a page built by scripts in the browser. Poor INP can come from a third-party widget, a chat tool, a tracking tag, or the site’s own code. Your developer should confirm the actual cause before changing anything.
That’s why the task should let the developer reproduce the problem and let you verify the result:
| Task field | What to include |
|---|---|
| Symptom for the visitor | What happens on the page from a person’s point of view |
| Page or template | An example URL and the page type |
| Conditions and source | Device, data source, date, metric value |
| Suspected cause | Marked as a hypothesis |
| How to confirm the cause | What to check before making changes |
| Owner | Who does the work and who signs off |
| Acceptance criteria | What shows the task is done |
Illustrative example. A completed task:
Symptom: on the mobile product page, the “Buy” button shifts down after the photo loads; the visitor may tap the wrong spot.
Template: product page; example:
/products/water-heater-50-gal/.Conditions and source: mobile; the product page group in the Search Console Core Web Vitals report is rated “Need improvement” for CLS; data as of the date the task was created.
Suspected cause: no dimensions or aspect ratio are set for the main photo.
How to confirm: reproduce the load on a simulated phone with a slow connection and record the shifts in Chrome DevTools.
Owner: the developer does the work; the SEO specialist checks the metrics; the project manager signs off.
Acceptance criteria: on three sample product pages, the button doesn’t move after the photo loads; the “select option → add to cart” flow works; the changes are live and the release date is recorded.
If the check points to a different cause, the developer documents what they found and what exactly they changed. When the fix involves template code, server settings, or third-party scripts, bring in our development team.
How to sign off on a fix
Sign-off has two separate parts. You can sign off on the technical fix right after it’s checked. Field data gets reviewed later as a separate task, because its 28-day window fills with post-release visits only gradually.
Technical sign-off, right after the changes go live:
- a lab check under the same conditions: the same URL, mobile mode, and several runs, since results vary between runs; we recommend comparing the typical value rather than the single best run and checking several pages that use the same template;
- the user flow: search and filters, option selection, cart, form, payment, leads arriving in the CRM, and analytics events;
- no regressions: fixing one metric didn’t make the other two worse or break other templates.
Field data review, as a separate task with a date and an owner. About 28 days after release, the 28-day window will contain only post-release visits. In Search Console, you can also click Validate fix for the group; Google then monitors it for 28 days. If the metrics improve and the change log shows no other edits that could have affected them, the result is consistent with the fix. If they don’t improve, check whether the changes reached every page in the group. The speed report won’t tell you whether your cost per lead changed; that takes a separate analysis with spend and lead data.
Record the result on a sign-off form. Your agency fills it out, and you or your project manager makes sure no field is left blank.
Sign-off form: technical fix
Illustrative example. This form is filled out for illustration and doesn’t reflect a real project.
| Form field | Value |
|---|---|
| Page or template | Product page, mobile version |
| Visitor problem | After the photo loads, the “Buy” button shifts and people may tap the wrong spot |
| Metric | CLS |
| Source and conditions | Search Console, product page group, mobile, rated “Need improvement” as of the date the task was created; lab check on three product pages |
| What changed | An aspect ratio is set for the main photo, so space is reserved before it loads |
| Check result | Technical fix signed off: no button shift on three product pages; the “select option → cart → checkout” flow works; cart events are recorded. Not yet known: how CLS changes in field data |
| Next step | Review the group’s status in Search Console 28 days after release; owner: SEO specialist |
Before you sign off on the work or approve the invoice, ask your agency four questions the form only partly answers:
- How exactly did you confirm the cause of the problem?
- How many pages using this template did you test, and on which devices?
- Where do the numbers come from: page-level field data, origin data, or a lab test, and as of what date?
- What remains unfixed or unknown, and why?
Next steps
- You or your head of marketing picks a few pages or templates using the factors above.
- The SEO specialist records field and lab data for them, with the date, and notes where origin data is shown or where field data is missing.
- The developer confirms the cause, makes the changes, and fills out the sign-off form.
- The project manager signs off on the technical fix and creates a separate task, with a date and owner, to review the field data.
The work is complete when the sign-off form records the technical fix as signed off and the field data review is scheduled. The outcome of that review goes on the form when it’s done, whatever it shows.
Let’s talk about which of your pages to check first and how to sign off on fixes.
