SEO

What Are Core Web Vitals? What They Measure and What Fixes Them

Core Web Vitals are three measures Google uses to judge how a page feels to real visitors: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness and Cumulative Layout Shift for visual stability. A page counts as good at 2.5 seconds, 200 milliseconds and 0.1 respectively, judged across real visits.

Prabhu SolutionsPublished 8 October 2026Last reviewed 8 October 202611 min read

On this page

What are Core Web Vitals?
What are the three Core Web Vitals, and what counts as good?
Is First Input Delay still a Core Web Vital?
What is the difference between field data and lab data?
How do you read the Core Web Vitals report in Search Console?
What fixes a slow Largest Contentful Paint?
What fixes a poor Interaction to Next Paint?
What fixes layout shift (CLS)?
How much do Core Web Vitals affect rankings?
How do you know a fix has worked?
When should you not worry about Core Web Vitals?
Who should fix Core Web Vitals problems?

What are Core Web Vitals?

Core Web Vitals are Google's three measures of how a page behaves for real visitors: how quickly the main content appears, how quickly the page responds when someone taps or clicks, and whether the layout jumps about while it loads. Each has a published threshold, and Google reports them in Search Console.

They sit inside what Google calls page experience. The measurements come from real Chrome users visiting your pages, not from a test someone runs on a laptop, which is why a site can feel fine to its owner and still fail. The owner is usually on a fast connection and a recent device; many visitors are not.

They are not a score out of 100. The performance score you see in some testing tools is a separate, lab-based number built from several measurements, and it is possible to have a high score there and still fail in the field, or the reverse. If you are handing the problem to technical SEO work, ask which of the two numbers the supplier is quoting.

The point
If you are handing the problem to technical SEO work, ask which of the two numbers the supplier is quoting.

What are the three Core Web Vitals, and what counts as good?

Largest Contentful Paint (LCP) measures loading, Interaction to Next Paint (INP) measures responsiveness and Cumulative Layout Shift (CLS) measures visual stability. Google judges each at the 75th percentile of visits, separately for mobile and desktop, and a page passes only when all three are in the good range.

Metric	What it measures	Good	Needs improvement	Poor
Largest Contentful Paint (LCP)	How long the largest visible element, usually a hero image or a block of headline text, takes to appear	2.5 seconds or less	Up to 4 seconds	More than 4 seconds
Interaction to Next Paint (INP)	How long the page takes to show a visible response after a tap, click or key press, across the whole visit	200 milliseconds or less	Up to 500 milliseconds	More than 500 milliseconds
Cumulative Layout Shift (CLS)	How much visible content moves unexpectedly while the page loads and is used	0.1 or less	Up to 0.25	More than 0.25

Is First Input Delay still a Core Web Vital?

No. Interaction to Next Paint replaced First Input Delay and became a stable Core Web Vital in 2024. First Input Delay only looked at the wait before the first interaction was handled. INP reflects how the slowest interactions of a whole visit felt, which is a much harder test to pass.

That matters because plenty of older advice still tells you to fix FID. If a report, a plugin dashboard or a blog post leads with First Input Delay, check its date. A site that passed the old measure comfortably can fail the new one, because a page that loads quickly but runs heavy scripts when someone opens a menu or adds an item to a basket now gets caught.

The point
If a report, a plugin dashboard or a blog post leads with First Input Delay, check its date.

What is the difference between field data and lab data?

Field data records what real visitors experienced; lab data comes from one controlled test run on a simulated device and connection. Google's report is built on field data, so that decides whether you pass. Lab data is for finding causes and checking a fix before it ships, and the two often disagree.

Question	Field data	Lab data
Where does it come from?	Real visits by Chrome users, collected in the Chrome User Experience Report.	A controlled test with fixed device and network settings, usually run with Lighthouse.
What does it show?	A spread of experiences. Tools usually report the 75th percentile, so most visitors did at least this well.	One repeatable result for one setup.
Where do you see it?	The Core Web Vitals report in Search Console, and the field section of PageSpeed Insights.	Lighthouse in the browser, and the lab section of PageSpeed Insights.
How does it handle INP?	Measured from real taps, clicks and key presses.	A lab test cannot predict when a person will interact, so it relies on a stand-in measure that can disagree with the real figure.
What is its weakness?	Needs enough traffic, and reflects past visits, so it lags behind a fix.	May not resemble real devices and connections, and does not model caching or the back and forward cache.
What is it best for?	Deciding which pages and which metric to prioritise.	Debugging, and confirming a change did something before it goes live.

How do you read the Core Web Vitals report in Search Console?

Open the Core Web Vitals report, choose mobile or desktop, and read the groups of URLs marked Poor or Need improvement. Each group takes the status of its worst metric. The report tells you which group of pages and which metric is failing, but not why; for the why, test a sample URL.

Check the data source first. The report is built from real-visitor data in the Chrome User Experience Report, not from a crawl of your site, so it can only describe pages that enough people have visited.
Read mobile and desktop separately. Each has its own tables, and a site can be fine on one and failing on the other. Start with mobile if most of your visitors arrive on phones.
Look at the groups, not individual pages. Search Console bundles pages with a similar experience, such as all product pages, so a single failing group often points to one template. Fix the template and every page in the group benefits.
Note the worst metric. A group's status is the slowest status among its metrics, so one failing measure holds the whole group at Poor or Need improvement, however well the other two do.
Expect “No data available” on small or new sites. It usually means there are too few real visits to report on. That is not a fault, and it is covered in the section on when not to worry.
Test a sample URL from the group. The report links through to PageSpeed Insights, which shows field data beside a lab run and lists likely causes. This is where an SEO audit earns its keep: it ties each failing group to a cause and a fix a developer can act on.
Press Start Tracking after a fix. Search Console then monitors the data for 28 days and marks the issue fixed only if it no longer appears on any URL in that time, so do not expect the report to turn green overnight.

What fixes a slow Largest Contentful Paint?

Find which part of the load is slow before changing anything. LCP splits into four parts: the server's first response, the delay before the main image or text starts loading, the time to download it, and the delay before it is drawn. Common culprits are a slow server response and a hero image that is discovered late.

Shorten the server response. Cut the redirects a visitor waits through, and make sure pages that can be cached are served from a cache or a content delivery network rather than rebuilt on every request.
Make the main image discoverable. Put its address in the HTML the server sends, so the browser finds it straight away. An image that only appears once a stylesheet or a script has run is found late, and every stage that follows waits for it.
Prioritise that one image. Marking the likely LCP image as high priority tells the browser to fetch it early. Use it on one or two images at most, because marking everything as important means nothing is.
Never lazy-load the LCP image. Lazy loading is right for pictures further down the page and wrong for the one the visitor sees first. It adds delay for no gain, and it is a common side effect of a plugin applying lazy loading to every image.
Send the right file. A hero image saved at four times the size the layout needs, in an uncompressed format, takes longer to download than it should. Resize it to the displayed size and compress it.
Stop blocking the first paint. Large stylesheets and scripts placed in the head of the page can hold back the drawing of the main element. Trim unused styles, inline the small ones that matter, and avoid synchronous scripts there.
Treat the four parts as proportions, not budgets. As a guide, roughly 40 percent of the time goes on the server response, 40 percent on downloading the resource and under 10 percent each on the two delays. If one of the small parts is large, that is where the problem is.

What fixes a poor Interaction to Next Paint?

INP is poor when the page is busy running JavaScript at the moment someone taps. Reduce and split the script work on the main thread, keep event handlers short and let the browser paint between tasks. An interaction has three parts, input delay, processing time and presentation delay, and each points to a different fix.

Break up long tasks. The main thread handles one task at a time, and any task over 50 milliseconds counts as long. While it runs, the browser cannot respond to a tap, so the visitor feels lag.
Yield to the browser. Split the work an event triggers so the visible update happens first and everything else, such as saving or tracking, waits its turn. Yielding at all is better than not yielding.
Do less in each handler. The simplest fix is usually removing work: fewer calculations on every click, fewer things triggered by one action.
Reduce the scripts that load with the page. Parsing and running large scripts at start-up creates long tasks right when people begin to interact. On sites run through a content management system, much of that weight comes from themes and plugins, so removing or replacing what you do not use is often the biggest saving. Whether WordPress or a custom build suits the site is a fair question once the plugin list is long.
Look at third-party tags as a possible contributor. Chat widgets, analytics and advertising tags all run on the same main thread. They are not the only cause, so measure before blaming them, but they are worth testing with each one switched off in turn.
Keep the page structure lean. A very large page structure makes every update slower, both at load and after an interaction. Simplifying it, and deferring content that is off screen, shortens the presentation delay.

What fixes layout shift (CLS)?

Layout shift happens when something loads late and pushes content that is already on screen. Reserve space for everything that arrives later: images, video, embeds, adverts, banners and fonts. Many fixes are small template changes, which is why a failing group of pages often turns out to be one template.

Give every image and video a width and a height. The browser then reserves the right amount of space before the file arrives, so nothing below it moves when it does.
Hold space for late content. Adverts, embedded maps, social posts and cookie banners should sit in a box with a fixed minimum height or aspect ratio. Do not collapse that box if nothing arrives, because removing reserved space shifts the layout just as inserting content does.
Do not push content down after the page has started to display. A banner that appears above the headline two seconds in is the classic cause. Overlay it, or reserve its space from the first paint.
Control how fonts swap in. A web font that loads late and has different proportions to the fallback reflows the text. Choose a fallback with similar proportions, preload the fonts that matter and set the font-display behaviour deliberately.
Animate with transforms. Moving an element by changing its top or left position forces layout to be recalculated. Transform animations move it without disturbing its neighbours.
Keep pages eligible for the back and forward cache. When a returning visitor can be shown a page restored from memory, there is no fresh load and no fresh shift.

How much do Core Web Vitals affect rankings?

Modestly. Google says its ranking systems use Core Web Vitals and recommends good scores, but also says it will show the most relevant content even when page experience is poor. Treat them as a tiebreaker between similar pages, not a switch that lifts or sinks a site by itself.

Google's own wording is worth reading closely. It says there is no single page experience signal, that good results in the Search Console report do not promise a top position, and that among many helpful results, page experience can contribute to success. Google has not published a weight, so a confident figure for how much they matter is either invented or measures something narrower than rankings.

That leaves a sensible order of priorities. If your pages are not indexed, or do not answer what searchers want, passing all three measures will not rescue them. If your pages are competitive and a competitor's are similar, a failing mobile score is an avoidable disadvantage. Either way the visitor is the stronger reason: a page that stutters on a phone loses the enquiry before Google has any say, which is where conversion rate optimisation and speed work meet. Where Core Web Vitals fit into the wider job is covered in what SEO involves.

The point
If your pages are not indexed, or do not answer what searchers want, passing all three measures will not rescue them.

How do you know a fix has worked?

Test the same page in the lab straight after the change, then wait for field data to catch up. Lab results confirm the change did something; only field data shows whether visitors feel it. In Search Console, Start Tracking runs a 28-day check before an issue is marked fixed.

A few habits keep you honest. Run the lab test more than once, because a single run is one sample. Test on a simulated mobile device and a throttled connection rather than on office broadband. Change one thing at a time where you can, so you know which change moved the number. And note the date of every change, so that a movement in the report can be matched to its cause.

Be cautious with improvements that appear in one tool only. If the lab number improves and the field number does not move, it may be that the real problem is something the lab test does not reproduce, such as a script that runs only after a visitor interacts, or a cookie banner that appears only for first-time visitors. For a structured way of checking this, what an SEO audit includes lists the checks that sit around performance.

The point
For a structured way of checking this, what an SEO audit includes lists the checks that sit around performance.

When should you not worry about Core Web Vitals?

Do not spend time on them when your pages already pass, when the site has too little traffic to produce field data, or when the real problem is that pages are not indexed or do not match what searchers want. In those cases the effort belongs elsewhere, and a small gap is not worth a rebuild.

Your key pages already show Good on mobile. Passing is the target. Squeezing a Good score into a better Good brings nothing that Google has said it rewards.
The report says “No data available”. A small or new site often has too few visits to be reported. Fix obvious problems you can see, such as an enormous hero image, and then spend your time on content. Do not chase a number that is not being measured.
You are chasing a perfect lab score. A 100 in a testing tool is not the target and is not what the report shows. Field data is what Google reports, so use the lab to debug, not to keep score.
Only a handful of low-value URLs fail. If the failing group is old posts nobody visits, the work is rarely worth it. Rank fixes by the pages that earn enquiries.
A rebuild is already planned. Fixing the old templates and then replacing them wastes the first piece of work. Put the requirements into the brief for the new build instead.
The fix would remove something that earns money. A chat widget or booking tool may cost some speed and pay for itself. Measure the trade rather than assuming that faster always wins.
You need enquiries sooner than any technical fix can pay back. If that is the position, comparing SEO with paid search is the better first decision.

Who should fix Core Web Vitals problems?

Whoever controls the templates, the scripts and the hosting: usually the developer who built the site or the team that maintains it. A marketer can read the report, but most fixes sit in code, images, caching and third-party tags. Plan for the fix as development work, not as a settings change.

The three pieces of work are different. Finding which template and which metric are failing is diagnosis, and it belongs inside a technical SEO engagement. Fixing it is website development, because the hero image markup, the script loading and the layout rules all live in the theme or application. Stopping it coming back is website maintenance, because a plugin update or a new marketing tag can undo a fix quietly.

If you are commissioning a new site, put the thresholds into the brief and ask how they will be measured on launch day and afterwards. That is far cheaper than retrofitting; how maintenance is priced explains where the ongoing part sits. If you already have a Search Console report and nobody to act on it, send us the failing group and the metric and we will say what we think is causing it. We build websites and software, so we can usually see the cause in the template, and you can see the sites we have built before you decide.

The point
If you are commissioning a new site, put the thresholds into the brief and ask how they will be measured on launch day and afterwards.

Questions people ask about this

What is a good Core Web Vitals score?

There is no single score. A page is good when its Largest Contentful Paint is 2.5 seconds or less, its Interaction to Next Paint is 200 milliseconds or less and its Cumulative Layout Shift is 0.1 or less, measured at the 75th percentile of real visits, with mobile and desktop judged separately.

Will fixing Core Web Vitals improve my rankings?

It can help, but do not expect a jump. Google says it uses them and recommends good scores, yet relevance still comes first. They are most likely to matter between pages that are otherwise close. The more reliable gain is that visitors on phones stay long enough to enquire.

Why do PageSpeed Insights and Search Console show different numbers?

They draw on different data. Search Console reports field data from real visits over a period, grouped by similar pages. PageSpeed Insights shows field data for one URL where enough exists, beside a lab run from one simulated test. Lab results cannot reproduce every device, connection and interaction, so the two rarely match exactly.

Why does Search Console say there is no data for my site?

Usually because too few real visitors have been recorded for that device type. New sites and low-traffic sites often have no field data at all. It is not an error and not a penalty. Fix any obvious problems you can see, then focus on content until traffic builds enough to be measured.

Are Core Web Vitals the same as page speed?

No. Page speed is a loose idea covering many things. Core Web Vitals are three specific measures: when the main content appears, how fast the page responds to input, and how stable the layout is. A page can feel quick overall and still fail one of them, which is why a single speed score misleads.

Can a WordPress or Shopify site pass Core Web Vitals?

Yes. The platform does not decide it; the theme, plugins or apps, images, hosting and third-party tags do. A carefully built site on either can pass and a heavy one can fail. Our pages on WordPress development and Shopify work cover how each is built for speed. For shops, the platform choice itself is covered in Shopify, WooCommerce or custom.

How often should I check Core Web Vitals?

Look at the Search Console report after any significant change to the site, such as a redesign, a new plugin, a new tracking tag or a new theme, and otherwise at a regular interval that suits you. Because field data lags, a problem introduced today may take a while to show up.