Core Web Vitals are no longer optional for competitive SEO. Since Google replaced FID with INP as a ranking signal in March 2024, many websites that previously passed CWV assessments are now failing — and losing rankings as a result. After auditing 200+ websites across industries, our technical SEO team has identified the most impactful fixes. This guide covers everything you need to go from failing to Good across all three metrics.
- INP replaced FID in March 2024 — sites that passed before may now be failing this stricter metric
- Google uses field data (real user experience) for rankings — not lab data from Lighthouse. These are often very different.
- LCP improvements typically deliver the largest ranking gains fastest — prioritise this metric first
- Images without explicit dimensions and late-loading fonts are the two most common CLS causes
- Heavy JavaScript is the primary INP culprit — JS tasks over 50ms must be broken up
- Focus fixes on your top 20 organic traffic pages first — this is where ranking improvement matters most
What Are Core Web Vitals and Why Do They Matter for Rankings?
Core Web Vitals are user experience metrics Google uses as a ranking factor within its Page Experience signals. They measure how fast, visually stable, and responsive your website feels to real users. Google's reasoning: a slow, visually unstable, or unresponsive page creates a bad experience regardless of how good the content is — and should rank below equivalent content with a better experience.
The three metrics are: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). Your overall Page Experience assessment passes only when all three metrics fall in the Good band for at least 75% of real user sessions in your field data.
LCP — Largest Contentful Paint
What LCP Measures
LCP measures the time from navigation until the largest visible content element — typically a hero image, video poster, or large text block — finishes rendering. A poor LCP (above 4.0 seconds) is one of the strongest negative ranking signals. Pages that take more than 3 seconds to show meaningful content lose 40% or more of mobile visitors before they engage.
- Good: under 2.5 seconds (aim for under 1.8s for competitive niches)
- Needs Improvement: 2.5 – 4.0 seconds
- Poor: above 4.0 seconds
Top Causes of Poor LCP
- Slow server response time (TTFB above 800ms) — fix with a CDN, server-side caching, or faster hosting
- Render-blocking JavaScript and CSS in the <head> that delay the browser from painting content
- Large unoptimised images — a 2MB hero image on a mobile connection causes LCP above 6 seconds
- LCP element not discovered early — if the browser finds the LCP image late in the HTML, it cannot start loading it early
- Client-side rendering — the LCP element does not exist until JavaScript executes
How to Fix LCP — In Order of Impact
- Preload your LCP image: <link rel='preload' as='image' href='hero.webp'> in the document <head> — single highest-impact fix
- Convert images to WebP or AVIF: WebP is 25–35% smaller than JPEG. AVIF is up to 50% smaller. Next.js Image component handles this automatically.
- Serve images from a CDN: Assets from a CDN edge node close to the user reduce load times 40–70% for distributed audiences
- Eliminate render-blocking resources: Move non-critical CSS to the bottom, defer non-critical JavaScript, and inline above-the-fold critical CSS
- Improve server TTFB: Switch to hosting with sub-200ms TTFB, or add Cloudflare in proxy mode in front of your origin server
- Use Server-Side Rendering (SSR) or Static Generation (SSG) for content currently loaded via client-side JavaScript
CLS — Cumulative Layout Shift
What CLS Measures
CLS measures visual stability — how much the page layout shifts unexpectedly while loading. When elements jump around as images load, fonts swap, or ads inject into the layout, users accidentally click wrong targets and trust evaporates. A CLS score of 0.1 or below is Good. Above 0.25 is Poor.
The Most Common CLS Causes
- Images and videos without explicit width and height attributes — the browser does not reserve space and the layout shifts when they load
- Late-loading web fonts causing FOUT (Flash of Unstyled Text) — text repositions when the custom font loads
- Dynamically injected content above existing content — cookie banners, chat widgets, and ad slots appearing above page content
- Animations affecting layout properties (top, left, width, height) instead of CSS transforms
- Third-party widgets loading asynchronously — social media embeds and review widgets that expand the layout on load
CLS Fixes
- Set explicit width and height on every <img> and <video> element — or use the CSS aspect-ratio property
- Use font-display: optional to prevent FOUT — the browser uses the fallback font if the web font does not load within a short window
- Reserve min-height space for ad slots, chat widgets, and cookie banners before they load
- Replace layout-affecting animations with transform: translateY() and opacity — these are GPU-composited and do not trigger layout recalculation
- Audit all third-party scripts and lazy-initialise non-critical widgets after user interaction
INP — Interaction to Next Paint
What INP Measures and Why It Is Stricter Than FID
INP replaced FID as a Core Web Vital in March 2024 and is significantly more demanding. Where FID only measured input delay for the very first user interaction, INP measures the end-to-end latency of every interaction throughout the entire page session — every click, tap, and keyboard input. It reports the worst interaction above the 98th percentile, meaning even one slow interaction in a session can fail the metric.
The target is under 200ms from interaction to next visible paint. A menu click that takes 500ms to produce a visual response will fail INP — even if every other element on the page is lightning fast. JavaScript-heavy sites, pages with heavy React re-renders, and sites with many third-party scripts are the most common INP failures we audit.
- Good: INP under 200ms
- Needs Improvement: 200 – 500ms
- Poor: above 500ms
How to Fix Poor INP
- Break up long JavaScript tasks: Any JS task over 50ms blocks the main thread. Use setTimeout(fn, 0), scheduler.postTask(), or requestIdleCallback() to yield between chunks of work.
- Defer non-critical JavaScript: Analytics, chat widgets, and marketing pixels should load after the page is interactive — not blocking it.
- Optimise React/Vue/Angular re-renders: Profile with React DevTools Profiler. Use React.memo, useMemo, and useCallback to eliminate unnecessary re-renders.
- Audit and remove third-party scripts: Each third-party is a potential INP killer. Use WebPageTest to identify which scripts add main-thread blocking time.
- Debug with Chrome DevTools: Performance panel > record an interaction > look for long tasks and identify which functions run during that time.
Lab Data vs. Field Data — The Most Important Distinction
Lab data (Lighthouse, PageSpeed Insights) runs in a controlled environment on a simulated mid-range device with throttled connection. Field data (Chrome User Experience Report, CrUX) measures real user experiences. Google uses field data for ranking decisions — not lab scores. A page can score 95/100 in Lighthouse but fail CWV in field data because real users on slower devices and connections experience it very differently.
- Google Search Console > Core Web Vitals: Your most important source. Real field data, updated monthly.
- PageSpeed Insights (pagespeed.web.dev): Shows both field data and lab data. Understand the gap between them.
- Web Vitals Chrome Extension: Measures CWV as you browse your own site — useful for page-by-page diagnosis.
- WebPageTest: Deep waterfall analysis for diagnosing render-blocking resources and TTFB.
- SpeedCurve or Calibre: Continuous performance monitoring with alerts for regressions.
The Prioritised CWV Improvement Plan
- Identify your top 20 pages by organic impressions in Search Console
- Check which pages are in the Poor or Needs Improvement bands
- Fix LCP first — largest ranking impact, often caused by a small number of fixable issues
- Address CLS — usually faster to fix than INP once sources are identified
- Tackle INP last — requires JavaScript profiling, more complex but critical for JS-heavy sites
- Wait 28 days after deploying fixes for CrUX field data to reflect the improvement
DigiSutra Solutions — DigiSutra's technical SEO team has improved Core Web Vitals for 120+ websites, consistently moving pages from Needs Improvement to Good within 4–8 weeks. Get a free Core Web Vitals audit — we will diagnose your scores, identify the specific blockers, and give you a prioritised fix list.
Book a Free Consultation →Frequently Asked Questions
Yes — they are a confirmed ranking signal within Google's Page Experience update. However, they function more as a tiebreaker than a primary factor. A page with excellent CWV but weak content will not outrank a page with great content and strong authority. The impact is strongest when competing pages are otherwise very similar in quality.
Lighthouse simulates a controlled environment. Search Console shows real field data from actual Chrome users on their real devices and connections. Indian mobile users on 4G experience your pages very differently from a desktop Lighthouse test. Always prioritise fixing field data issues over improving lab scores.
CrUX updates on a 28-day rolling window. After deploying fixes, you will not see the improvement in Search Console for up to 4 weeks. Ranking changes typically appear 4–8 weeks after the field data improves, as Google recrawls and re-evaluates page experience signals.
Yes — Google evaluates page experience signals separately for mobile and desktop rankings. A page can pass CWV on desktop but fail on mobile. Since over 65% of Google searches globally are on mobile, always prioritise fixing mobile CWV first.