Rankevra Blog

How to Fix Core Web Vitals: LCP, INP & CLS Action Plan

August 2, 2026

Most Core Web Vitals content stops at textbook definitions or generic page-speed tips — compress images, use a CDN, enable caching. That advice isn't wrong, it's just untethered from the diagnostic signal that tells you which fix your page actually needs. This guide gives you a decision tree: for each metric, the report that reveals the root cause, the fixes that resolve the vast majority of real cases, and how to confirm the fix landed.

What "Fixing" Core Web Vitals Actually Means (75th Percentile, Not a Vibe)

Core Web Vitals pass or fail per metric, per page (or page group), based on the core web vitals 75th percentile of real-user CrUX data collected over a rolling ~28-day window. It's not a single Lighthouse run, and it's not an average — if 75% of your real visitors get a "Good" experience, the metric passes, even if the remaining 25% had a rough one.

This is the field data vs lab data distinction that trips people up. Lab data — from Lighthouse or PageSpeed Insights on demand — reflects one simulated session on one device and connection profile. Field data is what Google uses to assess ranking-relevant performance, and it lags behind your changes by weeks, not minutes. Chasing a perfect Lighthouse score while ignoring CrUX trends is a common way to burn engineering hours without moving the metric Search Console actually reports on. As thresholds stand, "Good" means LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1 — each judged independently, per page.

Step 1: Find Which Pages and Metrics Are Actually Failing

You can't fix what you haven't isolated. The diagnostic path has two steps, in order.

First, open the core web vitals report in search console. It groups your URLs by performance pattern and status (Poor, Needs Improvement, Good), split by mobile and desktop. This is field data — real users, real conditions — so it's your source of truth for which URL groups need attention and which device is worse. Don't skip straight to a tool; Search Console tells you where to spend diagnostic time instead of guessing.

Second, take your highest-traffic failing URLs — not every URL in the group — and run them through PageSpeed Insights. This confirms the pagespeed insights field data (the "Discover what your real users experienced" section) lines up with what Search Console flagged, and it hands you the Lighthouse lab diagnostics and opportunities panel pointing at specific root causes — render-blocking scripts, oversized images, long tasks. Field data confirms the problem is real; lab diagnostics tell you why. For a broader framework on triaging technical issues, see the priority action plan for technical SEO, and if you'd rather see this diagnostic path automated across a site, a site audit tool does exactly that.

Fix LCP (Loading)

Largest Contentful Paint measures when the biggest visible element — usually a hero image, banner, or heading — finishes rendering. How to fix LCP starts with reading the Lighthouse diagnostics panel to see which of four common culprits applies:

Slow TTFB (Time to First Byte). If the server takes too long to respond before rendering can start, no front-end fix helps. Look at hosting, database query time, and server-side caching. Prioritize this if TTFB alone eats more than 20-30% of your LCP budget.
Render-blocking resources. CSS or JavaScript in the <head> that must finish before the browser can paint. Inline critical CSS for above-the-fold content and defer the rest; move non-essential scripts to load after first paint.
Unoptimized or unpreloaded hero image. If the LCP element is an image, check its file size and format (WebP/AVIF over JPEG), and add <link rel="preload"> so the browser fetches it immediately instead of discovering it late.
Lack of server-side rendering. For JS-framework-heavy sites, if the LCP element only appears after client-side JavaScript hydrates, consider SSR or static rendering so it's present in the initial HTML response.

Applying the largest contentful paint fix that doesn't match your actual bottleneck — say, preloading an image when the real problem is TTFB — wastes a sprint and moves nothing. Read the diagnosis first.

Fix INP (Responsiveness)

INP replaced FID as the official responsiveness metric in March 2024, and it's the hardest of the three to fix because it measures the full lifecycle of user interactions — clicks, taps, key presses — across the entire page visit, not just the first one. A single laggy dropdown deep in a session can tank your INP even if everything else feels snappy.

To diagnose, open Chrome DevTools' Performance panel and record a session while interacting with the page the way a real user would — clicking menus, filtering tables, opening modals. Look for long tasks: any JavaScript execution blocking the main thread for more than 50ms. These delay the browser from responding to input, and DevTools will show exactly which script is holding the thread hostage.

Core fixes for how to fix INP:

Break up long tasks. Split large JavaScript functions into smaller chunks using techniques like scheduler.yield() or setTimeout chunking, so the main thread gets breathing room between chunks.
Defer non-critical JavaScript. Anything not needed for the initial interaction — analytics, chat widgets, below-fold interactivity — should load after the page is idle, not competing with user-facing scripts.
Reduce third-party script impact. Ad networks, tag managers, and embedded widgets are frequent long-task offenders because you don't control their code. Audit them individually; load via async/defer, lazy-load below-fold ones, and remove anything not earning its keep.

The interaction to next paint fix that works best depends on whether your long tasks come from your own code or third-party scripts — DevTools will show you which.

Fix CLS (Visual Stability)

Cumulative Layout Shift measures unexpected movement of visible elements — the classic case being a page that jumps as ads or images load in. It's usually the fastest of the three metrics to fix.

Open DevTools' Performance panel or the Rendering tab and enable "Layout Shift Regions" to see what's moving and when. The cumulative layout shift fix almost always comes down to one of these:

Explicit width and height on images, video, iframes, and ad slots. Without dimensions set in HTML or CSS, the browser doesn't reserve space and shifts content once the asset loads. Add width/height attributes or aspect-ratio in CSS.
Reserved space for dynamic or injected content. Cookie banners, promotional bars, and lazy-loaded sections that insert above existing content cause shifts. Reserve a fixed-height container even before the content loads.
Font-display handling. Web fonts that swap in after a system-font fallback can reflow text if their metrics differ significantly. Use font-display: swap paired with matching fallback font metrics, or preload critical fonts to shrink the swap window.

How to fix CLS is less about deep diagnostics and more about discipline: every element that loads asynchronously needs a reserved footprint before it arrives.

Which Metric to Fix First When All Three Are Failing

When Search Console flags multiple failing metrics on the same URL group, don't try to fix everything simultaneously — you'll lose track of what caused which improvement. The prioritization rule for which core web vital to fix first:

Fix whatever's in the "Poor" band first, regardless of metric. A metric sitting in "Poor" drags your 75th percentile hardest and is most visible to real users.
If multiple metrics are in "Poor," weigh traffic volume and effort. Fix the metric affecting your highest-traffic URL group first, and within that, start with whichever fix has the best effort-to-impact ratio — CLS fixes are typically quick wins, while TTFB or SSR changes for LCP take longer.
Don't let "Needs Improvement" metrics sit indefinitely once "Poor" ones are resolved — they're still failing the pass/fail bar even if they look less urgent.

How to Confirm the Fix Worked

Verification has two speeds, and conflating them causes false confidence or false panic. Re-test in PageSpeed Insights immediately after shipping a fix — this gives a lab-data sanity check that the specific diagnostic (blocking script, missing dimension, long task) is actually resolved.

But that lab result is not your verdict. How long to see core web vitals improvement in Search Console depends on the CrUX rolling window: expect roughly 28 days of new field data to accumulate before the report reflects your change, sometimes longer since CrUX blends recent history rather than snapping to the latest day. If you check Search Console a week after deploying and status hasn't moved, that's not core web vitals not updating — it's the window doing what it's designed to do. Mark your calendar, don't re-fix a working solution out of impatience, and recheck at the four-week mark.

Why This Loop Gets Hard to Maintain Manually

Run through the full loop once and it's manageable: check Search Console, pull failing URLs into PageSpeed Insights, read the Lighthouse diagnostics, hand a ticket to a developer, wait nearly a month for CrUX to catch up, then recheck. Multiply that across dozens or hundreds of URLs — each with a different failing metric, root cause, and point in its 28-day wait — and the process stops being a checklist and becomes a spreadsheet nobody maintains.

This is where automated core web vitals monitoring earns its place in the workflow. A dedicated core web vitals tool continuously pulls field data, flags which URL groups are drifting toward "Poor," and prioritizes fixes by traffic impact rather than making you rebuild that triage manually every time. Rankevra's audit workflow handles the diagnose-fix-verify loop continuously instead of as a one-off project — surfacing exactly which pages and metrics need attention next, without re-running the same manual checks every few weeks. For broader page-speed tactics (CDN, caching, hosting choices) that complement these fixes, the Core Web Vitals fix-it playbook covers that ground, and if you're still weighing whether the effort is worth it, the evidence on Core Web Vitals' SEO impact is worth reading first. For getting more out of the report where this process starts, see these Google Search Console tips.

Ready to stop re-running this loop by hand? Rankevra automates the audit-to-fix pipeline so failing URLs get flagged, prioritized, and tracked through the CrUX verification window automatically.

Frequently Asked Questions

What are the current "Good" thresholds for Core Web Vitals?

A page passes when LCP is under 2.5 seconds, INP is under 200 milliseconds, and CLS is under 0.1, each measured at the 75th percentile of real-user field data. All three are judged independently and per page — passing two out of three still means the page fails Core Web Vitals overall.

Why does PageSpeed Insights show different results than Search Console?

PageSpeed Insights runs a lab test (a single simulated session) alongside a field data summary, while Search Console's Core Web Vitals report reflects rolling 28-day CrUX field data aggregated by URL group. A page can look fast in a lab run while still failing in the field if most real users are on slower devices or networks than the test simulates.

How long does it take to see Core Web Vitals improve after a fix?

Expect roughly 28 days for Search Console to reflect a change, since it relies on a rolling CrUX window rather than instant data. PageSpeed Insights can confirm the fix worked at the lab-data level within minutes, but treat that as a sanity check, not final proof.

Which Core Web Vital should I fix first if all three are failing?

Fix whichever metric sits in the "Poor" band first, since it's dragging your pass rate hardest. If more than one metric is in "Poor," prioritize by traffic volume of the affected URL group, then by which fix has the best effort-to-impact ratio.

Is INP harder to fix than LCP or CLS?

Yes, because INP depends on every interaction across an entire page visit, not just page load, making it sensitive to long JavaScript tasks and third-party scripts that are harder to isolate. Diagnosing it requires recording real interaction sessions in DevTools' Performance panel to find which script is blocking the main thread.

Can Core Web Vitals issues be fixed without a developer?

Some fixes — like adding explicit image dimensions or adjusting font-display settings — can often be done through a CMS or theme settings without deep development work. Others, like server-side rendering changes or breaking up long JavaScript tasks, typically require developer involvement to implement safely.

Keep reading

Back to all blog posts