A Search Console message says your Core Web Vitals are poor, or that some pages need improvement, and the first thought is whether Google just pushed you down the results. The message gives three short names, LCP, INP and CLS, and no plain explanation of what any of them measure. You may also be wondering whether this means a new website, and what that would cost. Take a breath, because the report is far more specific than the email makes it sound. Core Web Vitals are three numbers about how your pages load, respond and hold still, and the report tells you which group of pages missed which number. You can find that group yourself in about ten minutes, with free tools from Google. Once you know the failing number and the pages behind it, the fix is usually one image, one script or one part of a template, and you can judge whether a quote for anything bigger is fair.
Key Takeaways
LCP asks how soon the main content appears, INP asks how fast the page reacts to a tap or click, and CLS asks whether things jump around while you read.
Google's good numbers are LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of visits.
Google uses Core Web Vitals in its ranking systems as part of page experience, and says passing them does not guarantee top positions.
Open Experience, then Core Web Vitals in Search Console, choose Mobile, and write down the failing metric and the URL group.
One oversized image, one script or one template part can cause a whole group to fail, so name the cause before agreeing to a new site.
Core Web Vitals are three scores for loading, responsiveness and visual stability
Google defines Core Web Vitals as three measurements of what a visitor actually experiences on a page. Each one has a good number to reach, a poor number to avoid, and a middle band labeled needs improvement. Google publishes how it set those thresholds in its Core Web Vitals threshold guide, and describes how they appear in search in its Core Web Vitals and Search documentation.
- LCP, Largest Contentful Paint: how long it takes for the biggest visible piece of content, often a hero photo or a headline block, to show up. Think of it as "when does the page look ready?"
- INP, Interaction to Next Paint: how quickly the page responds when someone taps a menu, presses a button or types in a field. It looks across the visit's interactions, including clicks, taps and keyboard input.
- CLS, Cumulative Layout Shift: how much visible content moves without the visitor asking. It is the reason a person reaches for one button and hits another because an image loaded above it.
| Score | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | When the main content appears | 2.5 seconds or less | Between 2.5 and 4 seconds | Over 4 seconds |
| INP | How fast the page responds to interactions | 200 milliseconds or less | Between 200 and 500 milliseconds | Over 500 milliseconds |
| CLS | How much content shifts unexpectedly | 0.1 or less | Between 0.1 and 0.25 | Over 0.25 |
Google classifies each score at the 75th percentile of page visits. In practice, that means three out of four visits need to meet the good number. A page can feel quick to you on an office connection and still fail, because the report reflects the phones, networks and moments that real visitors had.
Google uses Core Web Vitals in ranking, as one part of page experience
Google says Core Web Vitals are used by its ranking systems, and that they are one piece of page experience rather than a standalone formula. Its page experience guidance puts the balance this way: "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." The same guidance says good Core Web Vitals "can contribute to success in Search" when plenty of helpful content competes for the same query.
For your site, that sets the order of work. Pages that answer the searcher's question still lead. When two pages are close in usefulness, a page that loads quickly, reacts quickly and stays steady has a better shot. Google also says that a passing report in Search Console or a third-party tool does not guarantee top rankings, and it recommends improving performance for visitors rather than chasing a perfect score for SEO alone.
A poor status does not mean every page on your site is slow or broken. It points to a group of similar pages and one or more of the three scores. If the group includes your service pages, contact page or booking form, fix it soon, because slow loading and jumpy layouts get in the way of the people about to call you. If it covers old blog posts nobody visits, it can wait behind more important work. For a wider view of what technical SEO covers, see what technical SEO is.
Open the mobile report in Search Console first
The email points at a report you can open right now. The steps below take about ten minutes and cost nothing.
- Open Search Console and pick your site: If you have not set it up yet, the Search Console setup walkthrough covers verification step by step.
- Go to Experience, then Core Web Vitals: Google's Core Web Vitals report help page describes the report.
- Choose Mobile and look at it separately from Desktop: The two reports can differ, and Google reviews them separately.
- Write down each row marked Poor or Needs improvement: Record the metric (LCP, INP or CLS), how many URLs are affected and an example URL.
- Note what kind of page the group holds: A service page, home page, blog post, product page or form page each call for a different level of urgency.
- Open one example URL and test it in PageSpeed Insights: Use PageSpeed Insights and record what it names as the largest element, the layout shifts and its top recommendation.
The report groups similar indexed pages together and gives each group the status of its worst metric. If a group fails on CLS only, a fix for LCP will not clear it. The data comes from real Chrome users over the previous 28 days, and it can show no data at all for a page without enough traffic. That is a gap in the report, not a sign that the page is fine or broken.
Search Console and PageSpeed Insights show different numbers because they measure different things
If you run a test and see a different result from Search Console, neither tool is wrong. They answer two separate questions.
Search Console reports field data: what real visitors experienced across grouped pages over the last 28 days. PageSpeed Insights shows field data when it has enough for the URL, and also runs a lab test, a single simulated load of one page right now, with recommendations attached. A lab test is good for finding a cause because it can be repeated. Field data is better for judging whether visitors have a problem because it comes from them.
So, a quick way to read the two together is:
- If the field data fails and the lab test names a cause, start with that cause.
- If the lab test looks fine and the field data fails, test on the mobile view again and check pages that load a chat tool, an ad or a map, since a single test can miss those.
- If a page has too little traffic for field data, treat the lab result as a rough guide and check the group's report again after more visits.
Keep a note of both results for each failing group, so that after a fix you can see whether the lab test and the real-visit data moved together.
Fix the largest image first, then the scripts, then the layout
Google's own guides list the common causes of each score. Match the cause to your failing metric, then start with the job that is smallest for the benefit it brings. Google does not publish a frequency ranking for small-site failures, so treat the order below as a place to start looking, and confirm it with your own report.
| Score | Common causes | What fixing it involves | Typical job size |
|---|---|---|---|
| LCP | An oversized hero image, a hero image that loads late, blocking CSS or scripts, a slow server response, redirects | Resize and compress the main image, avoid lazy-loading it, defer code that blocks the page, add caching | Small to medium, larger if the server or hosting needs work |
| CLS | Images, embeds, ads or banners with no reserved space, content injected late, web fonts | Add width and height to images, set aspect ratios, reserve space for ads and banners, load fonts steadily | Small to medium |
| INP | Long JavaScript tasks, large bundles, heavy page builders, sliders, chat tools and tracking scripts | Remove scripts you do not use, split code, simplify what runs on a tap | Medium to large when custom code or a page builder is involved |
Google's step-by-step guides for each score are optimize LCP, optimize INP and optimize CLS. A developer can work straight from them.
That order plays out like this for each score.
LCP: start with the main image
PageSpeed Insights tells you which element counted as the largest. If it is a photo, check its file size against the space it fills on a phone. A photo sized for a billboard and squeezed into a phone screen is a typical thing to find. Resize it, compress it, and do not lazy-load the main image, since it needs to appear first. The post on resizing and compressing images walks through that job. If the image is fine, look at what loads before it: blocking CSS, scripts and redirects.
CLS: reserve the space
Every image, video embed, banner and ad slot needs its space set before it loads, so nothing pushes the text down. Adding width and height attributes to images is a small change that can clear a CLS failure. Cookie notices and promotional bars that slide in after the page has loaded cause shifts too, so give them a fixed spot.
INP: look at what runs on a tap
INP failures tend to come from the scripts your site loads: chat widgets, analytics, tag managers, sliders and heavy page builders. List what is on the failing pages, and remove any tool nobody uses. Slow responses on a menu, a form field or a filter point to code that needs a developer's attention. That is a medium to large job, so confirm that INP is the failing metric before paying for it.
If the slowness is broader than these three scores, the post on a website that is slow to load covers testing, causes and a fix order for the whole page.
A repair is enough when one cause sits behind the failing group
A failing group can trace back to something narrow: an oversized image, missing dimensions, a third-party script, no caching or a single component reused across a template. In those cases a focused repair does the job, and the design stays as it is.
A larger project makes sense when the cause is built into how the site is made. Examples are a theme or page builder that keeps adding blocking work to every page, a content system that is no longer supported, server architecture that cannot meet the site's needs, or a business that already needs a redesign for content, conversion, accessibility or security. Google's guide to Core Web Vitals for business decision makers is a good reference when you are reading a proposal.
Before you approve any quote, ask for three things in writing: the failing group of pages, the metric, and the cause the person found. A fair proposal names all three and ties the work to them. If a group of old, low-traffic pages is the one failing, the better move may be to update, merge or remove those pages, as described in updating, merging or deleting old pages.
Fixes show up in the report after real visits pile up
After a fix goes live, Search Console does not update the same afternoon. Because the report draws on 28 days of real visits, the status changes as better visits replace the old ones. Plan to check the report again over the following weeks, and use PageSpeed Insights in the meantime to confirm the lab result moved in the right direction.
New scripts, banners and campaigns can undo a fix, which is why a quick look at the mobile report belongs in your routine whenever a page changes. The post on website maintenance cost explains what regular care typically involves.
Do you know what your Core Web Vitals report is telling you?
Pick an answer to begin.
1. Which score tells you how quickly a page reacts when a visitor taps a button?
2. What does Google say about passing Core Web Vitals and ranking?
3. Search Console and PageSpeed Insights show different numbers for one page. What is the most likely reason?
Frequently Asked Questions About core web vitals
What are Core Web Vitals?
They are three measurements of real visits to a page: LCP for loading, INP for responsiveness and CLS for visual stability. Google reports them in Search Console and PageSpeed Insights.
What is a good LCP, INP and CLS?
LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, each measured at the 75th percentile of page visits.
Do Core Web Vitals affect rankings?
Google says its ranking systems use them as part of page experience, and that good scores can contribute to success in Search when helpful content competes for the same query. Google also says passing does not guarantee top rankings.
Why does Search Console say my mobile pages are poor when PageSpeed Insights looks fine?
Search Console groups real-visit data from the last 28 days across similar pages, and PageSpeed Insights often tests a single URL with a lab load. Compare the field result in both, then work from the cause the lab test names.
Do I need a new website to pass Core Web Vitals?
Not always. A failure can come from an oversized image, missing image dimensions, a script or a single template part, and a targeted repair can clear them. A larger project is worth pricing when the cause is built into the theme, the page builder or the server.
How long until Search Console shows my fix?
The report uses real visits from the previous 28 days, so the status changes gradually after a fix goes live. Check it again over the following weeks.
Moving Forward
Core Web Vitals come down to three questions about a page: how soon the main content appears, how fast it reacts, and whether it holds still. Google's good targets are LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less, and the Search Console report shows which group of pages missed which one.
Your next step is small. Open the mobile report, write down the failing metric and the pages behind it, test one of those pages in PageSpeed Insights, and read what it names as the cause. If the cause is an image or a missing size, you may be able to fix it the same day. If it is a script or a template, you now have what you need to ask a developer for a specific repair rather than a rebuild.
If you would rather hand the diagnosis and the repair to someone else, Web Leveling can find which pages and scripts are behind the failing scores and fix them without a redesign when a repair is all the site needs. Our search engine optimization work includes the technical side of your site as it relates to Google. We work with small and medium businesses across the country and overseas. Send us your Search Console report, and we will go through it with you.
Terms
Core Web Vitals words in this post
Tap a term to see what it means.
Core Web Vitals. Google's three measurements of page experience: LCP for loading, INP for responsiveness and CLS for visual stability.
LCP. Largest Contentful Paint, the time it takes for the largest visible piece of content to appear.
INP. Interaction to Next Paint, how quickly a page responds to taps, clicks and key presses.
CLS. Cumulative Layout Shift, a score for how much visible content moves without the visitor asking.
Field data. Measurements collected from real visits to a page, such as the data in the Search Console report.
Lab data. Results from a single simulated test of one page, such as the test run in PageSpeed Insights.
75th percentile. The point that three out of four visits meet or beat, which Google uses to classify each score.
