Why Core Web Vitals Matter Twice
Core Web Vitals are Google's standardized metrics for measuring real-world web performance. The three current metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Google uses them as ranking signals, which gets most of the attention. The bigger business case is conversion.
Slow pages convert worse than fast pages. Pages that visually shift around as they load convert worse than pages that render stably. Pages that lag when users tap or click convert worse than pages that respond instantly. The relationship is well-documented: every additional second of LCP correlates with conversion drop-off, and the magnitude is significant. The conversion lift from getting Core Web Vitals into the green often pays back the optimization investment many times over before the SEO benefit even compounds.
This piece walks through what each metric measures, what users actually feel, and where the conversion impact comes from. For broader SEO foundation context, see our SEO 101 guide.
Largest Contentful Paint (LCP)
LCP measures how quickly the largest visible element on the page renders. For most pages, the LCP element is a hero image, a headline, or a video poster. The metric captures the moment that element finishes painting — not the moment the page starts loading, not the moment the page is technically complete, but the moment the user can actually see what the page is.
Google's threshold for "good" LCP is under 2.5 seconds. Above 4.0 seconds is "poor." The space between is "needs improvement."
The user experience corollary is straightforward. A page with a 4.5-second LCP feels slow even on a fast connection. The user looks at a blank or partially-rendered page for several seconds before the meaningful content appears. The instinctive response is to leave or to lose patience. Bounce rates climb, time-on-page drops, and conversion rates correspondingly suffer.
The most common LCP issues we encounter:
Unoptimized hero images. A 4 MB hero image at 4000×3000 pixels delivered without responsive sizing or modern formats. Easy fix: generate a 1920px maximum-width WebP or AVIF, lazy-load below-the-fold images, and use responsive image attributes (srcset, sizes).
Render-blocking JavaScript and CSS. External stylesheets and scripts that block the browser from painting until they download and parse. Easy fix: defer non-critical JavaScript, inline critical CSS, and load fonts asynchronously.
Slow server response. The server takes 800ms+ to return the initial HTML, leaving no time budget for the rest of the load. Fix: server-side rendering with proper caching, edge deployment, or static generation where possible.
Cumulative layout overhead. Large client-side JavaScript bundles that have to download, parse, execute, and hydrate before LCP completes. Fix: ship less JavaScript, use server components or static rendering, lazy-load below-the-fold interactivity.
Interaction to Next Paint (INP)
INP replaced First Input Delay (FID) in 2024 as Google's core interactivity metric. INP measures the latency between a user input (tap, click, key press) and the next visible response on the page. Unlike FID, which only measured the first interaction, INP captures interactivity across the user's entire session.
Google's threshold for "good" INP is under 200 milliseconds. Above 500 ms is "poor."
The user experience corollary: a page with a 600 ms INP feels laggy. The user taps a button and waits a noticeable beat before anything happens. Even on a perceptually fast site, this lag erodes trust — users sense the site is slow even if they can't articulate why.
INP issues are usually JavaScript issues. Long-running scripts block the main thread. Heavy event handlers run synchronous work. Third-party scripts (analytics, chat widgets, ad pixels) compete for thread time. The browser can't respond to user input while it's busy with these tasks, and INP captures the lag.
The fixes are mostly architectural. Reduce the volume of JavaScript loaded on initial render. Move heavy computation off the main thread (web workers). Defer third-party scripts. Use modern frameworks that avoid full-page hydration (server components, partial hydration, islands architecture).
Cumulative Layout Shift (CLS)
CLS measures how much the page content moves around during loading. The classic failure mode: a user starts reading the headline, an image loads above it, and the headline jumps down. The user loses their place. Worse, sometimes the user is about to click a button and the page shifts, causing them to click the wrong thing.
Google's threshold for "good" CLS is under 0.1. Above 0.25 is "poor."
The user experience corollary is visceral. Layout shift is one of the most user-hostile patterns on the web because it actively interferes with what the user is trying to do. The conversion impact is direct — users misclick, lose their place, or simply leave.
CLS issues are almost always image-related or font-related:
Images without explicit dimensions. Browser doesn't know how much vertical space to reserve. When the image loads, it pushes everything else down. Fix: always set explicit width and height attributes on images, or use CSS aspect-ratio to reserve space.
Web fonts that swap. The page renders in a fallback font, then swaps to the web font. The font swap changes line heights and pushes content. Fix: use font-display: swap with size-adjusted fallbacks, preload critical fonts, or use system fonts where appropriate.
Ads and embeds without reserved space. A YouTube embed or an ad slot loads after the page renders, pushing content down. Fix: reserve space with CSS placeholders, even if the placeholder is briefly empty.
Dynamic content injected above the fold. A sticky banner that appears 2 seconds in, an A/B test variant that swaps in, or any content that arrives late. Fix: avoid these patterns above the fold, or handle the layout shift explicitly with reserved space.
What Users Actually Feel (and Why It Matters for Conversion)
The conversion case for Core Web Vitals is that they correspond to specific user pain points that depress action.
A slow LCP feels like waiting. The user doesn't know if the page is loading or broken. They're more likely to leave before content appears.
A laggy INP feels like a broken site. The user taps a button and nothing happens. Their second click might be on the wrong thing. Their third click might be the back button.
A high CLS feels disrespectful. The user is mid-interaction and the page changes under them. This is one of the most reliably annoying patterns in web design.
Each of these problems has a measurable correlation with conversion drop-off. The exact magnitude depends on the site, but the direction is consistent across nearly every case study published. Faster sites convert better. More stable sites convert better. More responsive sites convert better.
For sites that convert traffic into leads, sales, or signups, the conversion lift from CWV optimization typically pays back the optimization cost within months — often weeks — and the benefit compounds over time as traffic grows.
What Good Looks Like for an SMB
A practical target for an SMB website that takes Core Web Vitals seriously:
LCP under 2.5 seconds on the median 75th-percentile real-user measurement. This typically requires a properly-sized hero image, server-side rendering or static generation, and disciplined JavaScript bundle size.
INP under 200 milliseconds. This typically requires keeping the JavaScript bundle small, deferring non-critical scripts, and avoiding heavy event handlers on common interactions.
CLS under 0.1. This typically requires explicit image dimensions, careful font loading, and reserved space for late-arriving content.
Modern frameworks that handle this well by default — Next.js with App Router and server components, Astro, SvelteKit — produce good Core Web Vitals out of the box if you don't fight them. Older stacks (legacy WordPress with heavy plugin loads, single-page React apps with full client-side rendering) require more deliberate optimization.
For more on the technical SEO foundations Core Web Vitals fits inside, see our seven schema types guide.
How to Measure Real-User Performance
Lab data (PageSpeed Insights, Lighthouse) is useful for diagnosis, but real-user measurement (RUM) is what determines whether the user experience is actually good. Two free sources for RUM data:
Chrome User Experience Report (CrUX). Public dataset of real Chrome user performance for sites with sufficient traffic. Accessible via PageSpeed Insights and Search Console's Core Web Vitals report.
Web Vitals JavaScript library. Lightweight library that captures Core Web Vitals from your own users and reports them to your analytics platform. Gives you site-specific data even when CrUX traffic thresholds aren't met.
The decision rule: optimize for the 75th-percentile real-user data, not the lab data. Lab data tells you what's possible. Real-user data tells you what's happening.
Key Takeaways
- LCP under 2.5s, INP under 200ms, and CLS under 0.1 are the thresholds for "good" Core Web Vitals.
- Each metric corresponds to a specific user-facing problem that depresses conversion: LCP feels slow, INP feels broken, CLS feels disrespectful.
- The conversion lift from CWV optimization typically pays back the cost faster than the SEO benefit alone justifies.
- Most issues are predictable: oversized hero images, render-blocking JavaScript, web fonts swapping, missing image dimensions, and large client-side JavaScript bundles.
- Modern frameworks (Next.js, Astro, SvelteKit) handle CWV well by default. Legacy stacks (heavy WordPress, full client-rendered React) require more deliberate work.
Final Take
Core Web Vitals optimization is not a vanity SEO project. It's user-experience work that happens to also produce SEO benefits. The conversion lift typically funds the technical investment many times over, and the SEO benefit compounds on top. Most SMB websites we audit have at least one CWV metric in the "needs improvement" or "poor" range, which means the work is meaningful for nearly any small business.
Our team handles end-to-end web performance optimization as part of our web development services. Request a free audit and we'll show you exactly where your Core Web Vitals stand and which optimizations would produce the largest conversion lift.
