Core Web Vitals are three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when, at the 75th percentile of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less. To improve them, fix the element that loads last, reduce the JavaScript that blocks interactions, and reserve space for everything that loads late.
This guide explains what each metric means, the difference between field data and lab data, which tools to use, and the fixes that usually matter most, with notes for WordPress, Shopify and Next.js. It also gives an honest answer on how much Core Web Vitals affect search rankings, because that is where a lot of wasted effort starts.
The three metrics and their thresholds
LCP measures when the largest image or text block in the viewport finishes rendering. On most pages that is a hero image, a banner or the main heading. INP measures how quickly the page visually responds to clicks, taps and key presses across the whole visit, and reports roughly the slowest interaction. It replaced First Input Delay as a Core Web Vital in March 2024 and is harder to pass, because it counts every interaction rather than only the first.
CLS measures how much visible content moves unexpectedly while the page is in use, such as text jumping down when an ad or image loads above it. Each metric is judged at the 75th percentile of page loads, separately for mobile and desktop, so a page passes only if at least three in four visits meet the "good" threshold. Mobile is usually the harder one, especially for audiences on mid-range Android phones and variable networks.
| Metric | Measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Loading of main content | 2.5 s or less | 2.5 s to 4 s | Over 4 s |
| INP | Responsiveness to interactions | 200 ms or less | 200 ms to 500 ms | Over 500 ms |
| CLS | Unexpected layout movement | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Field data vs lab data
Field data comes from real Chrome users visiting your site, collected in the Chrome User Experience Report (CrUX) over a rolling 28-day window. This is what Google uses for its page experience assessment. Lab data comes from a single simulated test, such as a Lighthouse run on a throttled device and network. Lab tests are repeatable and good for debugging, but they cannot measure INP directly, since no real person is interacting, and they often differ from what users experience.
The practical rule: use field data to decide whether you have a problem and whether a fix worked, and lab data to find out why. Do not chase a Lighthouse performance score of 100; it is a lab score with its own weighting, and a page can score well in the lab while failing in the field, or the reverse. Low-traffic pages may not have enough CrUX data, in which case Google groups them with similar pages or the whole origin.
How to measure: PageSpeed Insights and Search Console
PageSpeed Insights shows both views for any URL: field data from CrUX at the top, when available, and a Lighthouse lab audit below with specific diagnostics. The Core Web Vitals report in Google Search Console groups your URLs into good, needs improvement and poor, based on field data, which helps you spot templates that fail across many pages, such as all product pages or all blog posts.
For deeper work, Chrome DevTools' Performance panel shows exactly what the browser did during a load or interaction, and the web-vitals JavaScript library lets you collect the metrics from your own visitors and send them to your analytics. That real-user monitoring is the fastest way to see whether a change helped, rather than waiting weeks for the CrUX window to roll over.
- PageSpeed Insights: quick check of field and lab data for one URL
- Search Console Core Web Vitals report: site-wide view grouped by similar pages
- Chrome DevTools Performance panel: find the cause of slow loads and interactions
- web-vitals library: collect LCP, INP and CLS from real visitors yourself
Fixing LCP: images, fonts, servers and video
Start by identifying the LCP element; PageSpeed Insights names it. If it is an image, serve it in a modern format such as WebP or AVIF, at the size it is actually displayed, with responsive srcset sizes for mobile. Do not lazy-load it, since lazy-loading delays exactly the image you need first, and consider adding fetchpriority="high" so the browser requests it early. Avoid setting the hero image through CSS or JavaScript, where the browser discovers it late.
Slow server response delays everything, so check time to first byte. Page caching, a CDN close to your visitors and fewer database queries per request often help more than front-end tweaks. For web fonts, self-host where possible, preload the one or two critical files, and use font-display: swap so text appears immediately. Hero videos are a common LCP killer: use a lightweight poster image, compress the video heavily, and avoid autoplaying large files on mobile.
Caching deserves its own mention. Set long cache lifetimes for static files such as images, fonts, CSS and JavaScript, using versioned file names so updates still reach visitors. Serve them from a CDN so a visitor in Chennai or Delhi is not waiting on a server in another continent. For HTML, cache full pages where content is the same for everyone, and keep personalised parts small so the rest can be cached.
Fixing INP: less JavaScript, fewer third parties
Poor INP almost always means the browser's main thread is busy running JavaScript when the user taps something. Large framework bundles, heavy page builders, chat widgets, tag managers loaded with many tags, A/B testing tools, and analytics and ad scripts all compete for the same thread. Audit what runs on each page and remove what nobody uses; this is usually the cheapest and most effective fix.
For code you control, break long tasks into smaller ones so the browser can respond between them, give immediate visual feedback on click before starting heavy work, and avoid re-rendering large parts of the page for small changes. Load non-essential third-party scripts after the page is interactive or on user action, for example loading a chat widget only when someone clicks the chat button.
Be sceptical of every new tag. Marketing teams add pixels and widgets one at a time, each looking harmless, and a year later the page runs a dozen scripts nobody reviews. Keep a simple register of third-party scripts, who owns each one and why it exists, and review it every quarter. Removing one unused script often improves INP more than a week of code optimisation.
Fixing CLS: reserve space for everything
Layout shifts happen when something appears or resizes after the surrounding content has already rendered. The fix is to tell the browser in advance how much space each element needs. Always set width and height attributes, or a CSS aspect-ratio, on images, videos and iframes. Give ad slots, embeds and cookie banners a fixed reserved area, or overlay them instead of pushing content down.
Web fonts can also cause shifts when the fallback font and the real font have different sizes; matching fallback metrics or using size-adjust reduces this. Avoid inserting banners or notices above existing content after load. Animations should use transform and opacity rather than changing top, height or margin, which move other elements.
Platform-specific tips: WordPress, Shopify and Next.js
The same principles apply everywhere, but each platform has its own usual suspects. On WordPress and Shopify the biggest wins often come from removing things rather than adding optimisation plugins, because each plugin or app can add its own scripts and styles to every page, including pages where it does nothing. Uninstalled Shopify apps can also leave code behind in the theme, so check theme files after removing one. On WordPress, hosting quality matters more than most owners expect: cheap shared hosting with slow server response caps how good LCP can ever get.
On Next.js, the framework gives you good defaults, but it is still easy to ship too much client-side JavaScript. Keep components on the server unless they need interactivity, push client boundaries down to the smallest interactive piece, and check bundle sizes when adding libraries. Statically generate or cache pages that do not change per visitor, so they are served from a CDN rather than rendered on every request.
| Platform | Common causes | Typical fixes |
|---|---|---|
| WordPress | Heavy page builders and themes, many plugins, no page cache, unoptimised images, slow shared hosting | Lighter theme, remove unused plugins, page caching and CDN, image optimisation with WebP/AVIF, better hosting |
| Shopify | Too many apps injecting scripts, large hero sliders and videos, heavy themes | Remove unused apps and leftover app code, use a lean theme, one static hero image, limit third-party widgets |
| Next.js | Large client bundles, everything marked as client components, unoptimised images, third-party scripts in the head | Server components by default, next/image with priority on the LCP image, next/font, next/script with a later loading strategy |
How much do Core Web Vitals matter for SEO?
Core Web Vitals are part of Google's page experience signals and are used in ranking, but Google has been clear that relevance and quality of content matter much more. A fast page with thin content will not outrank a slower page that answers the query better. Where Core Web Vitals help most is as a tie-breaker between pages of similar relevance, and indirectly, through lower bounce rates and better conversions.
So be proportionate. If your site fails badly on mobile, fixing it is worthwhile for users and conversions as much as for search. If you already pass, pushing from good to excellent is unlikely to move rankings, and that time is better spent on content, internal linking and technical basics such as indexing and structured data.
How to improve Core Web Vitals: an order of work
If you are wondering how to improve Core Web Vitals without rebuilding the whole site, work template by template: fix the home page, product or service pages and blog posts, then measure with field data before moving on. RED SAG builds fast websites on Next.js and maintains WordPress and Shopify sites from Tiruppur, including performance audits that list the specific causes on your pages rather than a generic score, if you would like an outside view.
Frequently asked questions
Why does PageSpeed Insights show different scores each time?
The lab score comes from a single simulated run and varies with server response time, network conditions and third-party scripts at that moment. Field data is more stable because it covers 28 days of real visits. Run lab tests several times and look at the trend, and use field data to judge whether your site actually passes.
My Lighthouse score is high but Search Console says my pages are poor. Why?
Search Console uses field data from real users, often on slower phones and networks than the lab simulation, and it includes INP, which Lighthouse cannot measure. Pages can also fail due to interactions or layout shifts that happen after the initial load. Trust the field data and use DevTools to reproduce real user conditions.
How long does it take for Core Web Vitals improvements to show?
Field data in CrUX and Search Console is based on a rolling 28-day window, so improvements appear gradually over about four weeks. Search Console also offers a validation process for fixed issues. Collecting your own real-user metrics with the web-vitals library lets you confirm a fix within days rather than weeks.
What replaced First Input Delay?
Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital in March 2024. FID only measured the delay before the first interaction was processed. INP measures the full time until the page visually responds, across all interactions during a visit, so it is a better reflection of how responsive a page feels.
Do I need a caching or speed plugin for WordPress?
A good page cache helps most WordPress sites, and a CDN helps if your visitors are spread out. But plugins cannot fix a heavy theme, too many plugins or oversized images. Measure first, remove what you do not need, and add optimisation tools only for specific problems. Stacking several speed plugins often causes conflicts.
Will passing Core Web Vitals improve my Google rankings?
It can help, but usually modestly. Core Web Vitals are one of many signals, and Google prioritises relevant, helpful content. Passing matters most when competing pages are similarly relevant, and a faster site generally improves engagement and conversions. If your site fails badly, fix it; if it already passes, focus on content.