Core Web Vitals are three Google metrics that measure real-user experience on a page: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability). A page passes when at least 75% of visits score LCP within 2.5 seconds, INP under 200 milliseconds and CLS below 0.1.
Core Web Vitals are often discussed as a ranking factor, but their bigger value is practical: they describe whether a page feels fast, responds when tapped and stays still while loading. Those are the things that make visitors stay or leave. This guide explains each metric, what the latest data shows about how sites perform, the most common causes of failure and a fix order that works on typical WordPress and business websites. It is written for marketers who need to understand the reports and developers who need a starting checklist.
Key takeaways
- Three metrics, real users. LCP, INP and CLS are measured from real Chrome users, so lab tests are a guide, not the final score.
- INP replaced FID. Google made Interaction to Next Paint a Core Web Vital on 12 March 2024, replacing First Input Delay.
- Mobile is the hard part. The 2024 Web Almanac found only 43% of mobile sites passed all three metrics, against 54% on desktop.
- Images cause most LCP problems. An image is the LCP element on 73% of mobile pages, according to the same report.
- Fix in order. Server response, then the LCP image, then layout stability, then scripts that block interaction.
What are the three Core Web Vitals?
Google’s Core Web Vitals documentation sets out the three metrics and the thresholds for a “good” experience.
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | How long the main content takes to appear | 2.5 s or less | 2.5 s to 4 s | Over 4 s |
| Interaction to Next Paint (INP) | How quickly the page responds to taps, clicks and key presses | 200 ms or less | 200 ms to 500 ms | Over 500 ms |
| Cumulative Layout Shift (CLS) | How much content jumps around while loading | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Each threshold is assessed at the 75th percentile of page visits, segmented by mobile and desktop. In plain terms, at least three out of four visits need a good score for the page to pass. That is why one fast test on your office Wi-Fi does not prove much; the score reflects your real visitors’ devices and connections.
What happened to First Input Delay?
First Input Delay only measured the delay before the browser started handling the first interaction. Google’s web.dev announcement confirmed that INP became a Core Web Vital on 12 March 2024, replacing FID. INP looks at the responsiveness of all interactions during a visit and reports one of the slowest, so it is a much stricter and more realistic measure.
How do websites actually perform on Core Web Vitals?
The HTTP Archive Web Almanac 2024 Performance chapter, based on Chrome User Experience Report data, gives the clearest picture of the web as a whole.
INP is easier to pass than LCP; passing all three is hardest
Several other findings from the same chapter explain where problems come from:
- An image was the LCP element on 73% of mobile pages.
- 16% of pages lazy-loaded their LCP image, which delays the very element that should load first.
- On 35% of mobile pages, the LCP element was not discoverable in the initial HTML, so the browser could not start fetching it early.
- Only 15% of pages used
fetchpriorityto tell the browser which image matters most. - 66% of mobile pages had at least one image without set dimensions, down from 72% in 2022. Unsized images are a common cause of layout shift.
- Good INP was reported on 97% of desktop sites but 74% of mobile sites, reflecting slower processors on phones.
- Pages using a consent management platform had notably worse responsiveness: only 53% of mobile pages with one had good INP.
- 21% of pages used
Cache-Control: no-store, which prevents the browser’s back/forward cache from restoring the page instantly.
Do Core Web Vitals affect rankings?
Google’s documentation says Core Web Vitals are used by its ranking systems and that it recommends site owners achieve good scores, but it also stresses that good page experience does not guarantee top rankings. Relevance and content quality come first. In practice, Core Web Vitals act as one of many signals and are most likely to matter when competing pages are similar in relevance.
The stronger business case is user behaviour. A page that takes five seconds to show its main content, or freezes when someone taps the menu, loses visitors before they read anything. Fixing performance helps every channel, including paid traffic, email and social, not just SEO.
Where do you check your scores?
| Tool | Data type | Best use |
|---|---|---|
| Search Console, Core Web Vitals report | Field (real users), grouped by URL pattern | See which groups of pages pass or fail across the site |
| PageSpeed Insights | Field data where available, plus a Lighthouse lab test | Check one URL and get specific diagnostics |
| Chrome DevTools, Performance panel | Lab, on your own device | Find exactly which script or element causes a delay |
| Web Vitals extension or the web-vitals library | Field, from your own users | Collect your own measurements in analytics |
Remember that field data is collected over a rolling 28-day period. After you ship a fix, it can take several weeks for Search Console to reflect it. Use lab tests to confirm the fix works, then wait for field data to catch up.
How do you fix Largest Contentful Paint?
LCP has four parts: the time for the server to respond, the delay before the browser starts loading the LCP resource, the time to download it and the time to render it. Fix them in that order.
- Reduce server response time. The Web Almanac 2024 reported that sites with poor LCP had a 75th-percentile Time to First Byte of about 2.27 seconds, which leaves almost no time for anything else. Use page caching, a content delivery network and a host with adequate resources. On WordPress, a well-configured caching plugin and server-level cache are usually the biggest single win.
- Make the LCP image discoverable. Put the main image in the HTML as a normal
<img>, not as a CSS background or an element injected by JavaScript. - Never lazy-load the LCP image. Remove
loading="lazy"from hero images and addfetchpriority="high". - Serve the right size. Use modern formats (WebP or AVIF), compress properly and use
srcsetso phones do not download desktop-sized images. - Remove render-blocking resources. Defer non-critical JavaScript, and inline or prioritise only the CSS needed for the first screen.
How do you fix Interaction to Next Paint?
INP problems almost always come from JavaScript keeping the browser’s main thread busy, so it cannot respond when someone interacts. Common causes on business sites include heavy page builders, multiple analytics and marketing tags, chat widgets, consent banners and sliders.
- Audit third-party scripts. List every tag on the page. Remove what nobody uses. Load the rest after the page is interactive where possible.
- Break up long tasks. Developers can split long JavaScript work into smaller chunks and yield to the browser between them.
- Keep event handlers light. A click on “Add to cart” or “Open menu” should update the screen first and do heavy work afterwards.
- Reduce DOM size. Very large pages with thousands of elements make every update slower. Page builders often add many wrapper elements.
- Review your consent setup. Given the 2024 data on consent platforms and INP, choose a lightweight solution and test it on a mid-range phone.
How do you fix Cumulative Layout Shift?
- Set width and height on every image and video, or use CSS
aspect-ratio, so space is reserved before the file loads. - Reserve space for ads, embeds and banners. Cookie bars and promotional strips that push content down are frequent offenders; overlay them instead.
- Load web fonts carefully. Use
font-display: swapwith a similar fallback font, or preload the main font file, to avoid text jumping. - Avoid inserting content above existing content after the page has loaded, unless it is in response to a user action.
- Allow the back/forward cache. Avoid
no-storewhere it is not required, so returning visitors get an instant, stable page.
One more cause worth checking on every site is the cookie or consent banner. Because it appears on the first visit for most users, a heavy banner can affect LCP, INP and CLS at the same time. Test the page with and without the banner to see its real cost.
The Bargaon fix order for business websites
When a site fails Core Web Vitals, we work through the same sequence. It puts the cheapest, highest-impact fixes first and avoids rebuilding a site when configuration changes would do.
Fix the foundation before polishing
Most WordPress sites see the largest gains in stages 1 and 2. Stage 4 needs the most developer time.
What should WordPress sites check first?
- Is page caching active, and are logged-out visitors served cached HTML?
- Is an image optimisation tool generating WebP or AVIF and correct sizes?
- Is the theme or plugin lazy-loading the hero image? WordPress core avoids lazy-loading the first large image, but some themes and plugins override this.
- How many plugins add scripts to every page? Contact form, slider and social plugins often load assets site-wide when they are only needed on one page.
- Is the page builder producing very deep, heavy markup? A lighter theme or block-based templates can help.
Our guide to website performance and accessibility covers the wider performance picture, including accessibility checks that often overlap with speed fixes.
Worked example: a slow service page
Imagine a fictional consultancy whose main service page fails on mobile. Search Console shows the “service pages” URL group with poor LCP. PageSpeed Insights reports a 75th-percentile LCP of 4.6 seconds and good INP and CLS.
Working through the fix order:
- Server response. The lab test shows a Time to First Byte of 1.8 seconds. Page caching is installed but disabled for pages with a contact form. Enabling a cache that excludes only the form submission endpoint brings TTFB down sharply.
- LCP element. DevTools shows the LCP element is a large hero photo set as a CSS background, loaded by a slider script. The team replaces the slider with a single
<img>in the HTML, addsfetchpriority="high", serves WebP and adds a mobile-sized version throughsrcset. - Stability. The new image has width and height set, so CLS stays good.
- Scripts. The slider library is no longer needed on any page and is removed, which also shortens main-thread work.
Lab LCP drops to well under 2.5 seconds. Over the following four weeks, field data in Search Console moves the group to “good”. The numbers here are illustrative, but the pattern is one of the most common we see: a caching gap plus a hero image the browser discovers too late.
How do you keep scores good after fixing them?
Performance tends to decay. New plugins, marketing tags, larger images and redesigned sections slowly add weight. A light monitoring routine stops that drift:
- Monthly: check the Core Web Vitals report in Search Console for any URL group moving to “needs improvement” or “poor”.
- Before adding any new tag or plugin: test a key page in PageSpeed Insights before and after, on mobile.
- On every release: run Lighthouse against two or three key templates as part of the release checklist.
- Collect your own field data with the open-source web-vitals library and send it to analytics, so you see changes within days rather than waiting for the 28-day window.
- Set a performance budget, for example a maximum image weight for hero images and a limit on third-party scripts per page, and make it part of design and content briefs.
What Core Web Vitals cannot tell you
Passing Core Web Vitals means the page loads, responds and stays stable for most visitors. It does not mean the page is useful, persuasive or accessible. A fast page with weak content will still struggle to rank or convert. Equally, scores vary with your audience: a site whose visitors use older phones on slower networks will find the thresholds harder to meet. Treat the metrics as a floor for good experience, not the goal itself. For the rest of the technical picture, see our technical SEO guide and the SEO audit checklist. If a redesign is planned, read website migration SEO first so performance gains are not lost to broken URLs.
Frequently asked questions
Why does PageSpeed Insights show a different score from Search Console?
The Lighthouse score in PageSpeed Insights is a lab test on simulated hardware. Search Console uses field data from real Chrome users over 28 days. The field data is what Google’s Core Web Vitals assessment uses.
My page has no field data. What does that mean?
Google only reports field data when a page or site has enough Chrome users to measure. Low-traffic pages may show no data. Use lab tests and fix obvious issues; the site-level or URL-group data in Search Console may still apply.
How long until fixes show in Search Console?
Field data is a rolling 28-day window, so improvements usually take two to four weeks to show fully. You can use the “Validate fix” option in Search Console to track progress.
Is a 100 Lighthouse score necessary?
No. The Lighthouse score is a lab diagnostic. What matters is passing the field thresholds for LCP, INP and CLS at the 75th percentile. Chasing 100 can waste time on changes real users never notice.
Do Core Web Vitals matter for AI Overviews?
Google says AI features rely on the same Search foundations and need no special optimisation. Good page experience is part of those foundations, but relevance and content quality matter far more for being cited.
Which Core Web Vital should I fix first?
Start with whichever metric fails on your most important URL group in Search Console. On most business sites that is LCP on mobile, because it is usually caused by server response time and hero images, which are relatively quick to fix.
Sources and further reading
- Google Search Central: Understanding Core Web Vitals and Google search results.
- web.dev: Interaction to Next Paint becomes a Core Web Vital on March 12 (2024).
- HTTP Archive Web Almanac 2024: Performance chapter.
- web.dev: Largest Contentful Paint.
- web.dev: Interaction to Next Paint.
- web.dev: Cumulative Layout Shift.
Failing Core Web Vitals? Bargaon’s technical SEO service diagnoses the causes on real pages and prioritises fixes, and our website development team can implement them on WordPress and WooCommerce.