Core Web Vitals Fixes That Actually Move Rankings

Every SaaS founder has stared at a Lighthouse score of 47 and wondered which of the dozens of recommendations actually move rankings. The honest answer is that most of them do not. Google ranks pages based on field data from Chrome User Experience Report, not lab data from your laptop. Field data comes from real users on real devices with real network conditions, and it looks nothing like the pristine simulated environment inside Lighthouse. This post is the working list of Core Web Vitals fixes we ship inside QwiklyLaunch 45-day sprints that reliably move field data and, by extension, rankings. Every fix is explained with the exact engineering pattern, the tradeoff, and the expected impact. No fluff, no chasing 100 badges, no premature optimization. Just the fixes that produce green LCP, INP, and CLS at the 75th percentile of real users.

Understand What Google Actually Measures

Google uses three Core Web Vitals for ranking: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Each is measured at the 75th percentile across 28 days of field data. That means if 25 percent of your users have a bad experience, you fail, even if the median is fantastic. This detail is crucial. Optimizing for the median wastes effort. Optimizing for the 75th percentile means fixing the long tail: slow devices, spotty networks, and heavy pages.

The current thresholds

• LCP: good under 2.5 seconds, poor over 4.0 seconds
• INP: good under 200 milliseconds, poor over 500 milliseconds
• CLS: good under 0.1, poor over 0.25

Aim for all three green on at least 90 percent of your indexed URLs. Anything less means Google is downgrading you on a nontrivial share of your traffic.

LCP Fix Number One: Ship the Hero Image Correctly

The LCP element on most SaaS marketing pages is the hero image or headline text. If it is an image, the fix is preloading it, sizing it correctly, and serving modern formats. Add a link rel preload with fetchpriority high in the head. Serve the image as AVIF with WebP and JPEG fallbacks. Provide explicit width and height attributes to prevent layout shift. Size the image to no more than 2x the display resolution. A common failure is shipping a 4000 by 3000 pixel image and displaying it at 800 by 600. That wastes bandwidth and destroys LCP on slow connections.

If the LCP element is text, the fix is preloading the primary font and using font-display swap. Self-host fonts. Google Fonts served from fonts.googleapis.com adds a DNS lookup and a TCP handshake that costs 200 to 500 milliseconds on slow networks.

LCP Fix Number Two: Reduce Server Response Time

Time to First Byte is a hidden LCP killer. If your server takes 800 milliseconds to respond, your LCP cannot be under 2 seconds no matter how fast you render. Move to a CDN with edge rendering. For Next.js, deploy to Vercel or Cloudflare Workers with edge runtime for marketing pages. For a Rails or Django app, put a CDN cache in front of anonymous marketing routes with a 60-second cache. TTFB should be under 200 milliseconds at the 75th percentile globally, not just from your office in San Francisco.

Common TTFB pain points

1. Database queries in the render path for anonymous pages
2. Third-party API calls made server-side without caching
3. Cold starts on serverless functions in unused regions
4. Missing HTTP caching headers on static assets

LCP Fix Number Three: Kill Render-Blocking Resources

Every CSS file in your head blocks rendering until it downloads and parses. Every synchronous script does the same. Audit your head with WebPageTest and identify the critical rendering path. Inline critical CSS for above-the-fold content. Defer non-critical CSS with a preload plus onload swap. Move analytics and third-party tags to async or defer. If a script is not required for first paint, it does not belong in the head.

INP Fix Number One: Break Up Long Tasks

INP measures the time from user input to the next paint that reflects that input. The killer is long JavaScript tasks that block the main thread. Anything over 50 milliseconds is a long task. React re-renders with hundreds of children, expensive selectors in a state manager, and synchronous work inside event handlers are the usual suspects. Break long tasks using scheduler.postTask, requestIdleCallback, or React 18 startTransition. For large lists, use virtualization. For expensive computations, move them to a Web Worker. The engineering work here is significant but the ranking impact is direct.

The React-specific INP checklist

• Wrap non-urgent state updates in startTransition
• Memoize expensive components with React.memo and useMemo
• Debounce input handlers on search and filter fields
• Virtualize any list over 50 items with TanStack Virtual
• Avoid re-rendering the whole tree on route change with route-based code splitting

INP Fix Number Two: Reduce JavaScript Bundle Size

Less JavaScript means less work on interaction. Audit your bundle with source-map-explorer or the Next.js bundle analyzer. Any dependency over 30 kilobytes gzipped should be justified. Common bloat includes full Lodash instead of individual imports, Moment.js instead of date-fns, and the full Firebase SDK when you only use auth. Replace, tree-shake, or lazy load. Route-based code splitting reduces initial bundle by 40 to 70 percent on most SaaS marketing sites. This work is standard inside our web development engagements.

CLS Fix Number One: Reserve Space for Everything

Cumulative Layout Shift is caused by content that appears after initial render and pushes other content down. The fixes are boring and mechanical. Every image needs explicit width and height. Every ad or embed needs a container with fixed dimensions. Every dynamically loaded component needs a skeleton with the same footprint. Fonts must load with size-adjust or font-display swap paired with a fallback font that matches the metrics of the web font. This is what modern browsers give us with font metric overrides. Use them.

CLS Fix Number Two: Avoid Injecting Content Above Existing Content

Cookie banners, promotional bars, and notification prompts injected at the top of the viewport push everything down and generate massive layout shift. Reserve space for these elements from initial render. If you must show a cookie banner, render it as a fixed overlay at the bottom, not as flow content at the top. If you must show a promotional bar, include it in the initial HTML so it does not shift the page when the JavaScript loads. Every element that appears after page load without reserved space costs you CLS.

Measurement: Field Data Over Lab Data

Stop optimizing for Lighthouse. Instrument real user monitoring instead. The web-vitals npm package from Google captures LCP, INP, and CLS from real sessions and lets you send the data to your analytics endpoint. Aggregate by URL, device type, and connection quality. This dataset tells you which pages have real problems and which are fine. Chase issues that show up in real user data. Ignore Lighthouse warnings on issues that do not affect real users. For a deeper look at how we bake this into launches, check the blog for related posts.

The RUM stack we recommend

1. web-vitals library on every page
2. Custom endpoint or SpeedCurve for aggregation
3. Alerting on 75th percentile regression per URL
4. Weekly review of top 50 pages by traffic

Continuous Performance Budgets

Fixing Core Web Vitals is not a one-time project. Every deploy risks regression. Set performance budgets in your CI pipeline. If a pull request adds 20 kilobytes to the JavaScript bundle or pushes LCP over 2.5 seconds in Lighthouse CI, block the merge. Tools like Lighthouse CI, SpeedCurve, and Bundlewatch make this trivial to set up. Once budgets are enforced, regression stops. Without them, performance drifts back to bad within six months.

Debugging INP Regressions in Production

INP regressions are the hardest performance issues to diagnose because they show up under real user interaction, not on your development machine. When RUM data flags a page with high INP, replicate the issue with the Performance panel in Chrome DevTools using CPU throttling to 4x slowdown. Record an interaction that matches the flagged one. Look at the long tasks in the flame chart. Most INP problems trace back to expensive rerenders in React, heavy computation in click handlers, or third-party scripts hijacking the main thread. Fix the root cause rather than the symptom. Adding a spinner does not fix INP. Only reducing main thread work does.

INP debugging checklist

• Reproduce with CPU throttling in DevTools Performance panel
• Identify the long tasks blocking the interaction
• Profile React rerenders using React DevTools Profiler
• Check for expensive layout thrashing in the Layout panel
• Audit third-party scripts for main thread work during interactions

CDN and Caching Strategy for Vitals

The CDN configuration matters as much as your code. Cache HTML at the edge for anonymous users with a short TTL like 60 seconds. Cache static assets like JavaScript, CSS, and images aggressively with a one-year TTL and immutable filename hashes. Enable Brotli compression at the CDN. Configure HTTP/3 for faster connection setup on modern browsers. Use resource hints like dns-prefetch and preconnect for third-party origins your critical path depends on. These CDN-level optimizations can reduce TTFB by 200 to 500 milliseconds without any code changes. Most teams underuse their CDN and pay for it in field data.

Preventing Regressions in Feature Development

Every new feature risks performance regression. Establish a performance review as part of feature planning, not just after implementation. When a designer proposes a hero animation, ask about the impact on LCP. When an engineer adds a new dependency, check the bundle size impact. When a marketer adds a third-party tag, evaluate its performance cost. This upstream discipline prevents the slow accumulation of debt that eventually kills performance. Teams that only think about performance after launch spend months per year firefighting. Teams that think about it upstream ship fast features that stay fast.

Real User Monitoring Setup End to End

Setting up RUM correctly takes about a day and pays back for years. Install the web-vitals library in your root layout. Attach a callback that sends each metric to your endpoint via navigator.sendBeacon so the metric ships even during page unload. On the backend, store metric name, value, URL, device type, connection type, and geography per event. Aggregate nightly into a dashboard that shows 75th percentile per URL per metric. Alert when any high-traffic URL breaches its target for three consecutive days. This setup uses no expensive third-party tool. Free alternatives include SpeedCurve for teams that want a hosted solution or Grafana with a custom backend for teams that prefer to own the data.

Fields to log per RUM event

1. Metric name and value
2. URL path and full URL
3. Device type from user agent
4. Connection type from Network Information API
5. Geography from IP or CDN header
6. Page visibility state at metric capture time

Common Vitals Failures on Marketing Pages

Marketing pages have predictable performance killers. Massive hero videos autoplaying above the fold destroy LCP. Marketing tag managers loading Facebook, LinkedIn, and Google tags simultaneously destroy INP. Cookie banners injected at the top push everything down and destroy CLS. Custom font loading with poor fallback metrics destroys CLS. Each of these has a well-known fix but each is often left broken because marketers own the change and engineers own the metric. Break this handoff by adding performance requirements to every marketing tag or design change request. Speed and marketing effectiveness are not in tension when both teams understand the constraints. Publish a shared performance policy that both engineering and marketing sign off on. Include specific limits like maximum total page weight, maximum number of third-party scripts, and maximum time to interactive. Then hold everyone accountable when a proposed change would break a policy. This shared ownership prevents finger-pointing when field data regresses and makes performance a team responsibility rather than an engineering-only burden. Publish the policy in your team wiki and reference it in every design and marketing review. The habit of naming the constraint upfront prevents most regressions before they ship. Teams that adopt this discipline consistently report a fifty percent reduction in performance-related production incidents within the first six months, which frees engineering time for actual feature work rather than repeated cleanup of the same categories of mistakes.

The 45-Day Reality

Inside a QwiklyLaunch 45-day sprint, we treat Core Web Vitals as a day-one engineering constraint, not a day-forty polish task. The right image handling, font loading, bundle strategy, and rendering pattern are chosen up front so we ship green vitals on day one instead of retrofitting them at the end. Retrofitting is always more expensive than doing it right the first time. If your site has been bleeding rank due to slow vitals for months, retrofitting is still worth it. But if you are starting fresh, choose the stack and pattern that gives you green vitals by default.

Green Core Web Vitals will not save a site with bad content or thin backlinks. But bad Core Web Vitals will drag down a site with great content and strong backlinks. Fix the technical foundation and every other SEO investment compounds. If you want help shipping a site that hits green vitals on day one, start a conversation with our team. We also cover related decisions in our DevOps and cloud guides on caching and edge strategy.