How to Fix Core Web Vitals: LCP, CLS, INP Fixes That Actually Work
Core Web Vitals are Google ranking signals. This guide covers exactly how to fix LCP, CLS, and INP issues across Next.js, WordPress, and Shopify — with before/after impact.
Core Web Vitals are Google's user-experience metrics that directly affect search rankings. They measure loading speed (LCP), visual stability (CLS), and interactivity (INP). Poor scores cost rankings, reduce AI crawler efficiency, and frustrate real users — the triple cost that makes fixing them one of the highest-ROI technical SEO tasks available.
This guide provides the complete step-by-step approach for each metric, with specific fixes for Next.js, WordPress, and Shopify. For the full technical SEO context, see The Complete Technical SEO Checklist for SaaS Websites.
What Are Core Web Vitals and Why They Matter
Core Web Vitals are a set of standardised performance metrics that Google uses as ranking signals as part of its Page Experience algorithm. Since their introduction as ranking factors in 2021 and the addition of INP as a replacement for FID in 2024, they have become increasingly influential in competitive SERPs.
Beyond rankings, poor Core Web Vitals have real business impact. Pages with LCP over 4 seconds see significantly higher bounce rates. CLS events — where page elements shift unexpectedly — trigger user frustration and accidental clicks. High INP makes interfaces feel unresponsive and reduces conversion rates. Fixing Core Web Vitals is not just an SEO task; it is a conversion rate optimisation task.
OmniRank's audit pulls live CrUX field data for all your key pages and flags exactly which pages are failing which metrics. Run a free audit to see your current scores.
Understanding Your Current Scores
Before fixing, measure accurately. The critical distinction is between field data (real user measurements from the Chrome User Experience Report, or CrUX) and lab data (synthetic measurements from tools like Lighthouse).
Google's ranking signals use field data, not lab data. A page can score 95 in Lighthouse and still fail CrUX thresholds if your actual visitors use slower devices or mobile connections.
Field data tools:
- Google Search Console → Core Web Vitals report (URL-level field data)
- PageSpeed Insights → Field data section (CrUX data for your specific URL)
- OmniRank's audit — pulls CrUX data for all key pages automatically
Lab data tools (for diagnosing specific issues):
- Chrome DevTools → Lighthouse tab
- WebPageTest.org
- Chrome DevTools → Performance panel (timeline recording)
Always target improvements in field data. Lab data is useful for identifying what to fix, not for confirming the fix worked at scale.
Fixing LCP — Largest Contentful Paint
Target: under 2.5 seconds. "Needs improvement": 2.5–4 seconds. "Poor": over 4 seconds.
What LCP measures: the time until the largest visible content element in the viewport is fully rendered. On most SaaS sites, this is either a hero image or a large H1 heading.
The highest-impact LCP fixes:
Fix 1 — Preload the LCP element. If your LCP element is an image, add a preload hint in the HTML <head>: <link rel="preload" as="image" href="/hero.webp" fetchpriority="high">. This single change reduces LCP by 0.5–1 second on most sites.
Fix 2 — Serve images in modern formats. Convert hero images to WebP or AVIF. WebP is typically 25–34% smaller than JPEG at equivalent quality; AVIF is up to 50% smaller. Smaller images load faster.
Fix 3 — Eliminate render-blocking resources. CSS and JavaScript in the <head> that delay rendering push LCP later. Use <link rel="preconnect"> for third-party origins. Defer non-critical JavaScript with the defer attribute.
Next.js fix: Use the built-in <Image> component — it auto-converts to WebP/AVIF, adds fetchpriority="high" for above-the-fold images, and handles lazy loading for below-fold images automatically.
WordPress fix: Install a performance plugin (ShortPixel, WP Rocket, or Imagify) to auto-convert images on upload and enable lazy loading for below-fold images.
Shopify fix: Shopify's CDN automatically serves WebP when supported by the browser. Ensure your theme uses lazy loading for below-fold images.
Fixing CLS — Cumulative Layout Shift
Target: under 0.1. "Needs improvement": 0.1–0.25. "Poor": over 0.25.
What CLS measures: unexpected movement of page elements during load. A button that shifts down 200 pixels as an ad loads above it creates a high CLS score.
The highest-impact CLS fixes:
Fix 1 — Set explicit width and height on all images. When a browser encounters an image without defined dimensions, it cannot reserve space for it. When the image loads, it pushes other content. Add width and height attributes to every <img> tag. This is the single most common CLS cause and the fastest fix.
Fix 2 — Reserve space for ads and embeds. Dynamically loaded ads, YouTube embeds, and third-party widgets all cause CLS if their container has no defined height before they load. Set a minimum-height CSS rule on ad containers.
Fix 3 — Use font-display: swap. Web fonts that load after initial render cause text layout shifts as the browser swaps from fallback fonts. Add font-display: swap to all @font-face declarations.
Next.js fix: The <Image> component requires explicit width and height props, preventing this CLS cause automatically. For fill-layout images, ensure the parent has position: relative and defined dimensions.
Fixing INP — Interaction to Next Paint
Target: under 200ms. "Needs improvement": 200–500ms. "Poor": over 500ms.
What INP measures: the latency from a user interaction (click, tap, keypress) to the next visual update. It replaced FID (First Input Delay) as a Core Web Vital in 2024.
The highest-impact INP fixes:
Fix 1 — Reduce long tasks on the main thread. Long JavaScript tasks (over 50ms) block the main thread and delay visual updates after user interactions. Identify long tasks in Chrome DevTools → Performance panel → Main thread flame chart. Break long tasks by using setTimeout(0) or scheduler.postTask() to yield to the browser between work chunks.
Fix 2 — Reduce third-party script impact. Analytics scripts, chat widgets, A/B testing tools, and heatmap scripts are leading causes of high INP because they execute on the main thread. Audit which third-party scripts are active, remove any that are not essential, and load the rest with async or defer.
Fix 3 — Optimise event handler callbacks. Click handlers that do synchronous work before updating the UI cause high INP. Defer non-critical work after the visual update using requestAnimationFrame.
Fixing TTFB — Time to First Byte
Target: under 800ms. TTFB is not officially a Core Web Vital but is a strong predictor of LCP.
Fixes: Implement server-side caching for database-driven pages. Use a CDN to serve cached responses from edge locations geographically near users. Enable HTTP/2 or HTTP/3. Optimise database queries on server-rendered pages. Upgrade to a faster hosting tier if TTFB is consistently above 1 second.
Tools to Monitor Ongoing Performance
After fixing, monitor continuously:
- Google Search Console → Core Web Vitals report (28-day rolling field data)
- OmniRank's audit — scheduled re-audits flag regressions automatically
- Vercel Analytics / Datadog RUM — real-user monitoring for Next.js deployments
- PageSpeed Insights API — can be integrated into CI/CD pipelines to catch regressions before deployment
Frequently Asked Questions
Do Core Web Vitals directly affect my Google ranking?
Yes. Core Web Vitals are confirmed ranking signals in Google's Page Experience algorithm. Poor CWV scores disadvantage you against competitors with better scores for the same keywords, all else being equal.
My lab scores are good but my field scores are poor — why?
Lab scores use a simulated mid-tier device and fast connection. Field scores reflect your actual visitors on their real devices and networks. Many sites have good lab scores but poor field scores because their actual users are on mobile devices and slower connections. Optimise for field data by testing on real mobile devices.
How long does it take for CWV improvements to affect rankings?
Google recalculates CWV scores using 28-day rolling field data. An improvement implemented today will take up to 28 days to fully reflect in ranking signals, then ranking changes may take a further 1–2 weeks. Total turnaround: 4–6 weeks.
What is the fastest CWV win on any platform?
Setting explicit width and height attributes on all images (fixes CLS) and adding a preload hint for the LCP image are the two changes that most consistently deliver the fastest measurable improvements across all platforms. Both can typically be deployed in under an hour.
Fix Your Core Web Vitals This Week
Core Web Vitals are not optional in 2026. They are ranking signals, crawl efficiency signals, and conversion rate drivers simultaneously. The fixes in this guide are deployable without specialist performance engineering on any major platform.
Run a free OmniRank audit — it pulls live CrUX field data for all your key pages and shows exactly which pages are failing which metrics, with a prioritised fix list.
OmniRank Editorial Team
SEO & AI Research Team
The OmniRank team combines expertise in AI, SEO, and SaaS growth to deliver actionable insights that help websites rank across Google, AI search engines, and LLM citation networks.
