Core Web Vitals are three Google metrics that score how a page feels to real visitors. Largest Contentful Paint (LCP) times loading, Interaction to Next Paint (INP) times the response to a tap or click, and Cumulative Layout Shift (CLS) scores how much the page jumps. To improve them, fix whichever one fails on mobile first.
Most sites still miss at least one target. The 2025 Web Almanac performance chapter used Chrome data from July 2025 and found that 48% of websites pass all three on mobile, against 56% on desktop. Mobile is the harder test, and every check below starts there.
On this page
- What LCP, INP and CLS measure, and the scores Google calls good
- How Google measures Core Web Vitals on real visits
- Why PageSpeed Insights and Search Console show different numbers
- Do Core Web Vitals affect Google rankings?
- What faster page speed is worth in sales
- How to fix a slow Largest Contentful Paint
- How to fix Interaction to Next Paint when clicks feel slow
- How to fix Cumulative Layout Shift and stop the page jumping
- How to improve Core Web Vitals when more than one metric fails
- Where the field data falls short
- Who should prioritize Core Web Vitals, and who can wait
- Write the three targets into your next website brief
What LCP, INP and CLS measure, and the scores Google calls good
Google rates each metric as good, needs improvement or poor. A page is good when its largest visible element renders within 2.5 seconds and it responds to input within 200 milliseconds. Its layout shift score must also stay at 0.1 or below. Google Search Central's Core Web Vitals page, last updated December 10, 2025, lists the same three targets.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | How long the biggest image, text block or video in the first screen takes to render | 2.5 seconds or less | Over 4 seconds |
| Interaction to Next Paint (INP) | How long the page takes to show a visual response after a click, tap or key press | 200 ms or less | Over 500 ms |
| Cumulative Layout Shift (CLS) | How much visible content moves without the visitor asking it to | 0.1 or less | Over 0.25 |
LCP times how long the biggest image, text block or video in view takes to appear. The clock starts when the visitor opens the page. On a product page that element is usually the main photo, and on a text-heavy blog post it's the headline or first paragraph.
INP, the newest of the three, replaced First Input Delay on March 12, 2024. The old metric looked only at the first interaction. INP watches every click, tap and key press in the visit and reports close to the slowest one, ignoring outliers. Scrolling, hovering and zooming don't count.
Chrome usage data shows visitors spend 90% of their time on a page after it loads. A page can load fast and still feel broken.
CLS scores visual stability. Each unexpected shift gets a score from how much of the screen moved and how far it moved. CLS then reports the worst burst of shifts, where a burst is a run of shifts less than one second apart, capped at five seconds. Shifts within 500 milliseconds of a tap or click don't count, because the visitor expects the page to change then.
How Google measures Core Web Vitals on real visits
Google judges Core Web Vitals with field data: timings from real Chrome users over a rolling 28-day window. A page passes a metric when at least 75% of its page loads meet the good target. Mobile and desktop get separate results.
Take a landing page that loads in 1.8 seconds for 70% of mobile visits. The slowest 30%, on older phones or weak signal, wait 3.4 seconds. The 75th percentile visit sits inside that slow group, so the page fails LCP on mobile. It still loaded fast every time the marketing team checked it on office Wi-Fi.
Pages with too little Chrome traffic get no score of their own. Search Console may fold them into one group for the whole origin, and PageSpeed Insights falls back to origin data or shows none at all.
Why PageSpeed Insights and Search Console show different numbers
Search Console's Core Web Vitals report covers the whole site. It groups URLs that share a similar experience and labels each group Good, Need improvement or Poor. A group takes the status of its slowest metric, so one failing metric fails the whole group.
PageSpeed Insights shows field data for a single URL, plus a Lighthouse lab test. The lab test loads the page on one simulated device with fixed network settings, then gives a score out of 100. PageSpeed Insights calls 90 or above good, 50 to 89 needs improvement, and anything under 50 poor.
That Lighthouse number is not your Core Web Vitals result. The PageSpeed Insights documentation says good lab data doesn't mean real users are having a good experience. Use the lab test to reproduce and debug a problem, and use field data to decide whether you have one.
Do Core Web Vitals affect Google rankings?
Yes, but relevance outweighs them. Google's page experience guidance says its ranking systems use Core Web Vitals. The same document says good scores don't guarantee a top position. It also says Google shows the most relevant content even when the page experience is sub-par.
That page states there is no single page experience signal. Google weighs a mix of signals, judges most of them page by page and adds some site-wide assessments on top. Fixing the templates that earn your traffic matters more than chasing a perfect site average.
Treat Core Web Vitals as a tiebreaker. When two pages answer the same search equally well, the one that loads in two seconds and holds still fits what Google says its systems seek to reward. If your page doesn't answer the query, no amount of image compression will rescue it. When rankings stall for reasons speed can't explain, a technical SEO and content audit looks at the rest.
What faster page speed is worth in sales
The stronger case for this work is commercial. In an A/B test published on web.dev in March 2021, Vodafone improved LCP by 31% on a landing page and recorded 8% more sales. Its lead-to-visit rate rose 15% and its cart-to-visit rate rose 11%.
The test design is why the result holds up. Vodafone split its paid traffic 50/50 between two versions of one page that were visually and functionally identical. Only version A got the performance work: a widget rendered on the server instead of in the browser, server-rendered HTML for the top of the page, a resized hero image and compressed SVG and PNG files.
Run the sums on your own numbers: a store with 20,000 monthly sessions, a 2% conversion rate and a $60 average order takes $24,000 a month. An 8% lift on that is $1,920 a month from the same products and ad spend. Vodafone's 8% won't carry over to every store. The sums show what even a few percent is worth on pages that already sell.
On a store, fix the product page, cart and checkout templates first, since load time on that path decides how many shoppers reach the order button. The guide to reducing cart abandonment covers the other leaks on the same path.
How to fix a slow Largest Contentful Paint
LCP is the metric mobile pages fail most: only 62% of them score good on it in the Almanac data. Find the LCP element first, then split its time into four parts.
Google's web.dev guidance suggests about 40% for the server's first response and 40% for downloading the resource. The wait before that download starts and the wait before the element renders should each take under 10%. Whichever part runs long tells you where to work.
- Image work can't touch the server's first response. Speed that slice up with caching, better hosting or a content delivery network (CDN).
- Put the LCP image in the HTML as a normal img tag. When it's a CSS background or injected by JavaScript, the browser can't find it until those files run.
- Add fetchpriority="high" to that one image. Only 17.3% of mobile pages in the Almanac sample do.
- Never lazy-load the LCP image, since loading="lazy" tells the browser to wait on the one image that matters most. About one mobile page in six still does it.
- A 2,400-pixel-wide photo in a 1,200-pixel slot carries four times the pixels it needs. Resize each file to its display size and compress it.
- Trim render-blocking files. Stylesheets and synchronous scripts in the page head hold up everything after them.
One common case is a homepage with a 3.6-second mobile LCP whose hero is a 900 KB CSS background image. Moving it into an img tag with fetchpriority="high" and compressing it to about 150 KB cuts both the wait before the download and the download itself. That one change fixes two of the four slices.
How to fix Interaction to Next Paint when clicks feel slow
A slow INP means the page took too long to show a response after a click, tap or key press. That time has three parts: the wait before your code starts, the time your code takes to run, and the time the browser needs to draw the next frame.
The main thread handles one task at a time, and any task over 50 milliseconds counts as a long task. Every long task running when the visitor taps adds to the wait. INP is in better shape than LCP, with 77% of mobile sites scoring good in the same report.
On a category page, a "Filter by price" button that runs a 300 ms script before it redraws the product grid fails the 200 ms target on its own. Show a loading state the moment someone presses the button, then run the filtering in smaller chunks. The visitor gets feedback at once instead of a frozen screen.
- Run less JavaScript at startup. Analytics tags and chat widgets compete for the same main thread the visitor's tap needs.
- Break long tasks into smaller pieces and yield to the browser between them. The scheduler.yield() method does this in Chrome and Edge 129 and Firefox 142. On Safari, fall back to setTimeout.
- Do the visible work first. In a click handler, update what the visitor sees, then defer analytics calls and other background work until after the next frame.
- A large DOM takes more work to render. The CSS content-visibility property lets the browser skip off-screen sections until they're near the viewport.
- Alternating DOM reads and writes forces the browser to redo layout on the spot, a problem called layout thrashing. Batch the reads, then the writes.
How to fix Cumulative Layout Shift and stop the page jumping
Layout shift happens when something loads late and pushes visible content out of the way. The usual causes are images, ads, embeds and iframes without set dimensions, content injected after load, and web fonts that swap in late. Reserve the space before the content arrives and the shift has nowhere to happen.
On a news article, a 250-pixel ad slot that loads above the first paragraph two seconds in pushes down the text the reader has already started. On a phone, that one shift can push CLS past 0.1 by itself.
CLS is the metric most sites already pass: 81% of mobile pages score good on it in the Almanac. Its image audit found that 62% of mobile pages leave at least one image without dimensions. Plenty of passing sites are one late banner away from failing.
- Add width and height attributes to every image and video, or set a CSS aspect-ratio, so the browser reserves the box before the file arrives.
- Give ad slots, embeds and cookie banners a fixed min-height. Content injected near the top of the screen causes bigger shifts. Place late-loading units lower where you can.
- Late web fonts reflow text when they arrive. Setting font-display: optional stops that, and preloading the fonts used above the fold helps them arrive in time.
- Animate with the CSS transform property instead of top or left, which make the browser redo layout.
- Keep pages eligible for the back/forward cache, so a visitor who hits Back gets the page restored as it was. The Almanac found Cache-Control: no-store, one of the common blockers, on 23% of sites.
How to improve Core Web Vitals when more than one metric fails
Start with real-user data, on mobile, on the pages that earn traffic. Then work through these steps in order, because each one narrows the problem before you spend developer time on it.
- Open Search Console's Core Web Vitals report and select the mobile view.
- Match the failing URL groups against your busiest traffic and revenue pages. A slow template, such as every product page, is one fix for hundreds of URLs.
- Note which metric fails in each group and fix that one before polishing the others.
- Reproduce the problem in PageSpeed Insights or Chrome DevTools, fix the cause and deploy.
- Click Start Tracking in Search Console. Validation runs a 28-day monitoring session, so judge the result in weeks, not hours.
When two metrics fail on the same template, fix LCP first on content and store pages, where the first screen decides whether people stay. Fix INP first on pages built around filters, forms or calculators, where the interaction is the product.
Where the field data falls short
Core Web Vitals give you the clearest public view of how visitors experience your site. The data comes from Chrome users on their own devices, and Google changes stable metrics at most once a year.
The weak spots are lag and coverage. Results trail your fixes by up to 28 days, and small sites or new pages may not have enough Chrome traffic to measure. Field data covers Chrome users only. Visitors on Safari or Firefox never appear in it.
One new third-party script, such as a chat widget or a heavier tag manager setup, can undo months of work. Nobody notices until the report turns red. Check it every month and after each new tag goes live.
Judge by field data and stop once you're in the good band. Pushing a 2.1-second LCP down to 1.4 seconds won't change much in search, and that week is better spent on content.
Who should prioritize Core Web Vitals, and who can wait
Prioritize Core Web Vitals when your pages make money directly or compete with pages of similar quality.
- Online stores, where a slow product photo or a jumping cart button costs orders. If you're weighing a rebuild, headless commerce storefronts need the same LCP check, because a heavy JavaScript bundle can load slower than a lean theme.
- Lead-generation sites running ads. You pay for every click, so a landing page that loses visitors before it renders wastes budget. Vodafone's test ran on paid traffic.
- Publishers and blogs with display ads, since late-loading ad slots are a classic cause of layout shift.
- Service businesses in crowded local searches, where several pages answer equally well and page experience can tip the result. Pair the speed work with local SEO for a small business.
Brand-new sites and thin pages can wait. A site with a few hundred visits a month may have no field data at all. Build it lean, publish pages that answer what people search, and check the reports once they fill in.
Write the three targets into your next website brief
The cheapest time to pass Core Web Vitals is before launch. Put 2.5 seconds, 200 milliseconds and 0.1 into the brief as acceptance criteria, measured on mobile. Before launch there's no field data, so ask for PageSpeed Insights lab results on each template at sign-off, then check the field data four weeks after go-live.
Any small business website quote should list that speed check next to page builds and contact forms.
Send your Search Console Core Web Vitals export to our website design and development team for a reply within one business day.
Frequently asked questions
A page passes when LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. Google checks each metric at the 75th percentile of page loads over 28 days, with mobile and desktop judged on their own.
Yes, Google's ranking systems use them, but they weigh less than relevance. Google says good scores don't guarantee top positions, and it will still rank the most relevant page when its page experience is sub-par. They count most when competing pages answer a search equally well.
Plan on about four weeks. The field data behind the reports covers the previous 28 days, so old slow visits drop out gradually. Search Console's validation also runs a 28-day monitoring session after you click Start Tracking.
They measure different things. The score out of 100 in PageSpeed Insights comes from one Lighthouse lab test on a simulated device. Search Console reports field data from real Chrome users, and that field data decides your Core Web Vitals assessment.
Interaction to Next Paint (INP) replaced First Input Delay on March 12, 2024. First Input Delay timed only the first interaction. INP checks the delay on every click, tap and key press during a visit, and its score sits near the slowest of them, so a page that slows down after loading still fails.