Core Web Vitals: What Actually Moves the Numbers

Core Web Vitals come down to three metrics measured in real user field data at the 75th percentile: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. That field data, pulled from Chrome UX Report (CrUX), is what Google uses as a ranking signal. Your Lighthouse score is not the same thing, and optimizing for it instead of field data is the single most common mistake I see.

The Short Answer (Read This First)

If you are reading this because your PageSpeed Insights score looks bad, the first thing to do is scroll past the lab score and look at the Field Data section. If there is no field data, Lighthouse numbers do not affect your rankings. If there is field data, the metric flagged there is your actual problem.

Core Web Vitals are a confirmed ranking signal. Google has also been clear that they are a tiebreaker, not a primary factor. A well-written page with strong backlinks and relevant content will outrank a faster but thinner competitor. That said, in competitive markets where comparable pages are already close on content and authority, CWV can push you up or down. And the conversion data is real: pages that pass all three CWV thresholds see 24% fewer abandonment rates than pages that fail. For a site where a lead is worth several hundred dollars, that math matters more than the rankings discussion.

As of early 2026, only about 48% of websites globally pass all three thresholds in field data. Financial services and lending sites trail that average, mostly because of how heavily they rely on third-party scripts.

The Three Metrics and What They Actually Measure

All three metrics are measured at the 75th percentile of real user sessions for a given URL, using Chrome's CrUX dataset. That means 75% of your users need to be hitting the threshold, not just the median user.

LCP (Largest Contentful Paint) measures how long it takes for the largest visible element to render. That element is usually a hero image, a headline rendered behind a web font, or a rate offer banner. Good is under 2.5 seconds. Needs Improvement is 2.5 to 4.0 seconds. Poor is above 4.0 seconds.

INP (Interaction to Next Paint) measures the latency from user input to the next paint the browser produces. It replaced FID (First Input Delay) on March 12, 2024. FID only measured the delay before the first event handler fired. INP measures the full interaction cost, including processing time and rendering. It is a much stricter measure of how responsive a page actually feels. Good is under 200ms. Needs Improvement is 200 to 500ms. Poor is above 500ms. A lot of sites that passed FID are now failing INP, and many site owners have not caught this yet because it was a new metric in 2024.

CLS (Cumulative Layout Shift) measures unexpected visual movement during page load. Good is under 0.1. Needs Improvement is 0.1 to 0.25. Poor is above 0.25.

All three thresholds apply to field data, not a single synthetic test. One fast load in Lighthouse does not tell you what is happening at the 75th percentile on a mid-range Android phone on a 4G connection.

The Fixes That Actually Move Field Data

I prioritize these in this order: LCP first, INP second, CLS third. LCP is almost always the highest-impact fix, and it is usually more tractable than INP work.

Fix LCP First

The most common LCP mistakes I see: lazy-loading the LCP image, failing to preload it, and serving it from a slow origin without a CDN.

Never put loading="lazy" on your LCP image. This is obvious in hindsight but it happens constantly, especially when a developer applies lazy loading globally to "optimize" images. Add fetchpriority="high" to the LCP image tag and add a <link rel="preload"> in the document head. If the image is served from your own origin, put a CDN in front of it. If it is a JPEG, make sure it is compressed correctly and served as WebP where browsers support it.

If your LCP element is a text block waiting on a web font, that is a different problem (see CLS section below, since font loading affects both metrics).

For sites built on a static architecture, LCP fixes are often straightforward because you control the full document output. For sites with heavier CMS layers, image delivery is sometimes handled by the platform, which creates a platform conversation rather than a quick code fix.

Fix INP Second

Third-party scripts account for an average of 45% of total JavaScript execution time on financial services pages. On a site with a rate calculator, a live chat widget, and a lead capture embed, that percentage is often higher. Long JavaScript tasks on the main thread directly cause high INP scores because the browser cannot respond to user input while it is processing a 200ms task.

The fix is breaking up those long tasks. scheduler.yield() is the cleanest modern approach. setTimeout chunking works as a fallback for older environments. For third-party scripts you cannot rewrite, deferring them until after the page is interactive is the next best option. Load your chat widget after a user interaction, not on page load.

The median time to interactive for financial services pages on mobile is over 7 seconds according to HTTP Archive data. That is not a Lighthouse problem; that is a script loading problem showing up in real user experience.

Fix CLS Third

On lending and compliance-heavy sites, the top CLS causes are: late-loading compliance banners (RESPA, TILA, NMLS disclosures) that push content down, ad units injected above existing content, and web fonts that cause layout shift.

For banners, reserve space in the layout before the banner loads. A min-height on the container holding the disclosure prevents the page from jumping when the content appears.

For fonts, font-display: swap without size-adjust is a known CLS contributor. The fallback font renders at a different size, then shifts when the web font loads. Either use font-display: optional (which skips the swap entirely if the font is not cached) or specify size-adjust to match the fallback metrics closely enough to eliminate the visual shift.

All of this matters most on mobile. CrUX measures real devices on real networks, and mobile scores are consistently worse than desktop. If you are only checking desktop in Lighthouse, you are missing where most of your real users are failing.

A Prioritized Fix Checklist

This is ordered by impact. Hand this to your developer or use it to audit your own site.

Highest impact, do these first:

1. Identify the actual LCP element using PageSpeed Insights or Chrome DevTools (Elements panel, look for the LCP annotation in Performance tab).
2. Remove loading="lazy" from the LCP image if present.
3. Add fetchpriority="high" to the LCP image tag.
4. Add a <link rel="preload" as="image"> for the LCP image in the document <head>.
5. Verify the LCP image is served from a CDN, not directly from the origin server.
6. Compress the LCP image. Use WebP. Aim for under 100KB for a typical hero.

Second tier, address after LCP is passing:
7. Run a Chrome DevTools Performance trace and look for long tasks over 50ms.
8. Defer non-critical third-party scripts (chat, analytics beyond a basic page view beacon, lead capture widgets) until after page interactive.
9. Break up long tasks in your own JavaScript using scheduler.yield() or setTimeout chunking.
10. Reserve explicit height for compliance banners and any content loaded asynchronously above the fold.
11. Audit font loading: replace font-display: swap with font-display: optional or add size-adjust to your @font-face declarations.

Only if you have remaining dev budget:
12. Implement rel="preconnect" hints for third-party origins your page depends on.
13. Evaluate whether any third-party embeds can be replaced with self-hosted or facade alternatives.
14. Set up real user monitoring (RUM) using the Web Vitals JavaScript library to catch regressions before they show up in CrUX.

Note: fixes 1 through 6 can often be done at the CMS or template layer without platform escalation. Fixes 7 through 11 may require access to script configuration or platform settings. Fix 13 requires a platform or vendor conversation if the embeds are managed by a third party.

Optimizations That Change Nothing (and Why Vendors Keep Selling Them)

This is the section I wish more vendors were honest about.

Compressing non-LCP images improves page weight but does not move your LCP, INP, or CLS scores in field data. It is worth doing for bandwidth reasons, but it is not a CWV fix.

Minifying CSS that is already render-blocking saves a few kilobytes but does not address the structural problem. If a stylesheet is blocking render, minifying it does not change when it blocks.

Running Lighthouse in incognito and treating it as your real score is the most damaging habit I see. Lighthouse is a lab tool. It simulates one page load under specific conditions. CrUX is aggregated real user data across hundreds or thousands of sessions. For pages with personalized content, geo-targeted rate data, or heavy third-party scripts, the divergence between Lighthouse and field data is often dramatic. A mortgage site showing different rate quotes by state will look completely different in a Lighthouse simulation than it does to real users with cached third-party scripts in various states of readiness.

Adding browser cache headers to third-party resources does not work. You do not control the cache headers on a resource served from another origin. The browser respects the origin server's headers, not yours.

GTmetrix scores have the same problem as Lighthouse: they are lab data. A GTmetrix A score with failing CrUX field data is a common pattern on sites built with page builders that bloat your render-blocking scripts. The score looks fine in a controlled test; real users on real devices tell a different story.

The platform constraint issue deserves a direct statement: if you are on a locked-down CMS where you cannot control how the hero image is injected, cannot modify script loading order, and cannot adjust font delivery, some of these fixes are simply not available to you without a platform conversation. Identifying that constraint early saves everyone time.

How Much Does This Actually Affect Rankings and Leads

Honest answer: CWV is a tiebreaker. Google has confirmed this through documentation and through John Mueller's public statements. In most scenarios, a page with stronger content, better backlinks, and clearer E-E-A-T signals will outrank a faster but weaker competitor. CWV does not overcome a content quality gap.

In competitive local markets where pages are genuinely comparable on content and authority, CWV can be the marginal difference between positions. If you are fighting for position 3 versus position 5 in a high-volume metro refinance query, and the pages at positions 1 through 4 are all well-optimized content-wise, your CWV scores are more likely to matter than they would in a thinner market.

On the AI Overviews question: CWV still matters for organic blue-link rankings even as AI summaries change how SERPs look. The blue links are still there for most navigational and transactional queries, and the CWV signal applies to those rankings. For a broader view of how search visibility is changing beyond rankings, that is a separate conversation worth having.

The conversion rate data may be more directly significant than the ranking impact for most sites. A 24% reduction in page abandonment on pages that pass all three CWV thresholds, sourced from Google's own data, is substantial when a single closed loan is worth thousands in revenue. That argument for CWV investment does not depend on ranking mechanics at all.

Where This Goes Wrong: Tradeoffs and Honest Limitations

A few things I want to say plainly because most CWV content glosses over them.

First, some CWV fixes create real tension with compliance requirements. A lending site with RESPA, TILA, and NMLS disclosure overlays has legal obligations that cannot be deferred or hidden. Reserving space for a compliance banner is usually achievable. Removing it entirely to improve CLS is not an option. The fix has to work within the compliance constraint, and sometimes the compliance constraint wins.

Second, if you are on a locked CMS managed by a mortgage tech vendor, you may not have access to the levers that matter. Some fixes require escalation to the platform, and not every vendor prioritizes this. Knowing what is and is not in scope for your specific setup is step one.

Third, over-optimizing for CWV scores at the expense of functionality can hurt conversion even while it helps the metric. Deferring your mortgage calculator until after page interactive might improve INP. It might also mean the calculator is not ready when a user tries to use it immediately. Test the user experience, not just the score.

Finally, CrUX requires a minimum volume of real user visits before field data is populated. New pages, low-traffic pages, and pages behind authentication will not have CrUX data. PageSpeed Insights will fall back to lab data only for those URLs. That lab data does not affect rankings. For bulk analysis across a site, the Chrome UX Report via BigQuery or the Google Search Console CWV report are more useful than running PageSpeed Insights on individual URLs.

Open PageSpeed Insights on your top landing page URL right now, scroll to the Field Data section, and identify which metric is failing on mobile. That is your starting point.