Core Web Vitals as a conversion lever

We stopped treating Core Web Vitals as an SEO chore

Most teams chase Core Web Vitals because Google attached a ranking signal to them. We chase them because slow pages lose money before they ever lose rank. On a recent client storefront doing roughly 40,000 sessions a month, we measured the field data in CrUX and saw a 75th-percentile LCP of 4.1 seconds. The conversion rate on those slow sessions sat at 1.2 percent. Sessions where LCP landed under 2.5 seconds converted at 2.0 percent. Same traffic, same offer, same checkout. The only variable was how fast the page became usable.

That gap is the entire argument. When we tie LCP, INP, and CLS to a revenue model instead of a Lighthouse score, the priority order changes and the work gets funded.

What each metric actually breaks at the till

LCP, Largest Contentful Paint, is the moment the main content renders. A 4-second LCP means four seconds where a visitor stares at a blank or skeleton page and decides whether to wait. INP, Interaction to Next Paint, replaced FID in March 2024 and measures how long the page takes to respond after a tap or click. A poor INP means the add-to-cart button feels dead for 300 milliseconds or more, and people tap it twice or leave. CLS, Cumulative Layout Shift, measures content jumping around as it loads. A shifting layout makes someone tap the wrong thing, often a banner instead of the buy button.

We map each one to a checkout step. LCP governs whether the product page earns a scroll. INP governs whether the cart and form feel responsive. CLS governs whether the final tap lands where the visitor aimed. A funnel with a fast LCP and a janky CLS still leaks at the bottom, which is why we never optimize a single metric in isolation.

The order we fix things in

We always start with LCP, because it sits at the top of the funnel and the fixes carry the most reach. The first move is almost never code. It is finding what the LCP element actually is. On the storefront above, the LCP element was a hero image served at 2,400 pixels wide into a 720-pixel container, uncompressed, 1.1 megabytes. We served a responsive AVIF at the right size, added fetchpriority high on that one image, and preconnected to the image CDN. LCP dropped from 4.1 to 2.3 seconds in field data over the following 28 days, which is how long CrUX takes to reflect a change.

INP comes second. The usual culprit is a main thread blocked by third-party scripts. We audited the tag stack and found a chat widget, two analytics scripts, and a personalization library all parsing on load. We deferred the chat widget until first interaction, moved analytics behind requestIdleCallback, and the personalization call became a server-side fetch. INP at the 75th percentile went from 290 milliseconds to 140. The add-to-cart button started responding inside one frame.

CLS comes third because it is usually the cheapest fix once the other two are done. We set explicit width and height attributes on every image, reserved space for the cookie banner and the promo bar, and stopped injecting a font swap that reflowed the headline. CLS went from 0.18 to 0.02.

Putting a number on it

Here is the model we run before any of this work starts, so the operator knows what they are buying. Take the slow-session conversion rate and the fast-session rate from field data. On the storefront, that was 1.2 percent versus 2.0 percent. Roughly 60 percent of sessions were in the slow bucket. If we move even half of those into the fast bucket, that is 12,000 sessions a month shifting from 1.2 to 2.0 percent conversion. At an average order value of 68 dollars, that is 96 extra orders, near 6,500 dollars in monthly revenue, from speed alone. We bill the project against that number, not against a green Lighthouse badge.

The field data is what we hold ourselves to. Lab scores in Lighthouse are useful for catching regressions in a pull request, but they run on a throttled simulation, not on the mid-range Android phones our client's real customers use. We wire a synthetic check into the deploy pipeline that fails the build if lab LCP regresses past 2.5 seconds, and we watch the 28-day CrUX trend to confirm the field caught up. The two together keep a fast page fast after launch, which is where most CWV projects quietly fall apart.

The mobile reality nobody wants to measure

The single biggest gap between teams that ship fast pages and teams that think they did is the device. Lighthouse on a developer's laptop runs on a fast machine over a fast connection. The customer is on a three-year-old Android phone on a congested mobile network in a train carriage. Those are different worlds, and Core Web Vitals are scored on the second one.

We pull the device breakdown out of CrUX every time. On the storefront, 71 percent of sessions were mobile, and the mobile 75th-percentile LCP was 4.6 seconds against a desktop figure of 2.9. If we had optimized against the desktop number, we would have declared victory while the majority of real customers still waited almost five seconds. So every fix gets validated on a throttled mobile profile, a mid-tier device emulation at 4x CPU slowdown and a slow 4G network, before it ships. The numbers we report to the operator are always the mobile field numbers, because that is where the revenue is and where the problem hides.

How a fast page stays fast

The quiet failure mode of every Core Web Vitals project is regression. A page ships at 2.3 seconds, the team celebrates, and four months later a marketing tag, a new hero video, and an unoptimized image have dragged it back to 4 seconds. Nobody is watching, because the project ended.

We close that gap with two guards. The first is a budget check in the deploy pipeline. We set a hard ceiling, lab LCP under 2.5 seconds and total JavaScript under 300 kilobytes on the critical path, and the build fails if a pull request crosses it. That stops most regressions at the door, before they reach a single customer. The second is a weekly field-data pull from CrUX into a dashboard the operator actually sees, so the 28-day trend is visible and a slow drift gets caught in week two rather than month four. The combination is what turns a one-time speed project into a page that is still fast a year later. Without it, the work decays, and the revenue gain decays with it.

What we do not do

We do not chase a perfect 100. The return curve flattens hard past good thresholds, and the engineering time is better spent elsewhere once LCP is under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. Those are the thresholds Google calls good, and they line up neatly with where our conversion data stops improving. Past that point we are polishing a number, not earning an order. We have watched teams spend two weeks shaving 200 milliseconds off an already-fast page while the checkout form three steps down still shifted layout on every load. The honest move is to fix the metric that is actually below threshold and stop the moment it crosses into good.

Core Web Vitals are worth the work because they are one of the few technical metrics that connect cleanly to revenue. Fix the LCP element, unblock the main thread, reserve the layout, and measure the result in field data and in orders. That is the lever. If you want the model we use to size this before committing to it, we are at arthea.ai.