Core Web Vitals and Revenue: What Site Speed Is Worth

Performance work is usually sold as a score to improve and bought as a box to tick. That framing is why it keeps getting deprioritized: nobody can defend a budget for moving a number from 62 to 89 when the number has no stated relationship to money.

The relationship exists and it runs through three separate channels. Speed changes how many visitors convert, it changes what you pay per click for the same ad position, and on large sites it changes how much of your content gets crawled and indexed at all. Those are conversion, media cost and reach. None of them are technical concerns.

What the Three Metrics Actually Measure

Core Web Vitals are Google-defined measurements of loading, responsiveness and visual stability, each with a published threshold for what counts as good. The thresholds below are documented standards rather than estimates, and they are assessed at the 75th percentile of real page loads.

Largest Contentful Paint

LCP measures how long it takes for the largest visible content element in the viewport to finish rendering, counted from the moment navigation starts. That element is usually a hero image, a background image, a video poster or a large block of text. Good is under 2.5 seconds. It is a proxy for the question a visitor is actually asking, which is not whether the page has technically begun loading but whether the thing they came for is on screen yet.

LCP has two components people commonly conflate. There is the time before the browser receives anything useful from the server, and there is the time spent rendering once it has. A fast server with a bloated hero image fails. A perfectly optimized image behind a slow server response also fails. Diagnosing which half is responsible determines whether the fix is infrastructure or asset handling.

Interaction to Next Paint

INP measures responsiveness across the whole visit rather than at a single moment. It observes the latency of interactions such as clicks, taps and key presses, and reports a value representing the worst of them, measured from the interaction until the next frame is painted with visible feedback. Good is under 200 milliseconds. It replaced First Input Delay because responsiveness at the first interaction says nothing about what happens on the fifth.

This is the metric most directly tied to whether a page feels broken. When someone taps a button and nothing visibly changes, they tap again, then assume the site is malfunctioning. INP failures are almost always long JavaScript tasks occupying the main thread, and the main thread is single-threaded: while a script is executing, the browser cannot paint a response to anything the user does.

Cumulative Layout Shift

CLS measures how much visible content moves unexpectedly during the life of the page, scored on the proportion of the viewport affected and the distance moved. Good is under 0.1. Unlike the other two it is not about waiting, it is about instability, and it produces a specific commercial failure: the user reaches for one element, the page reflows, and their tap lands on something else. On a form or a checkout that is a lost transaction, and the analytics will record it as an abandonment with no visible cause.

Field Data, Lab Data, and Why Your Tools Disagree

Two teams can look at the same page and reach opposite conclusions because they are reading different kinds of measurement. Understanding the difference prevents a great deal of wasted argument.

Field data is what real visitors experienced. The Chrome User Experience Report collects it from consenting Chrome users on real devices and real connections, and reports it as a trailing window rather than a live figure. It reflects your actual audience, including the ones on older phones and weak signal, and it is the data that informs how these metrics are assessed. It is also slow to respond: fix something today and the field numbers improve gradually as the reporting window rolls forward.

Lab data is a simulated load. Lighthouse, which powers the lower half of a PageSpeed Insights report and the audit panel in Chrome, loads the page once on a defined device profile with throttled network and CPU settings. It is reproducible, immediate and diagnostic, which makes it the right tool for finding causes and for checking whether a change worked before it reaches production.

They disagree for structural reasons rather than because one is wrong. Lab tests one device at one moment while the field aggregates every device your audience owns. Field data trails by weeks while lab data is current. Lab cannot measure INP at all, because INP requires real interactions, so it substitutes Total Blocking Time as a proxy. And field data needs traffic to report: low-volume URLs return no page-level data and fall back to origin-level figures, which is why a landing page can show numbers describing a different page entirely.

The working rule is simple: field data decides whether you have a problem, lab data tells you what is causing it. Teams that only read lab scores optimize for a simulation. Teams that only read field data know they are failing and cannot say why.

The Commercial Case for Speed

Speed as a Conversion Variable

A visitor cannot distinguish between a page that is slow and a page that is broken, and they do not spend time trying. On a phone, on a connection that is not the one in your office, a blank viewport for several seconds is functionally identical to a site that failed to load. The visitor returns to the results page and opens the next option, and if the click was paid, you were charged for the entire experience.

Responsiveness compounds this at the point of maximum commercial value. The interactions that matter most, such as submitting a form, adding to a cart, opening a booking widget or advancing a multi-step flow, tend to be the ones that trigger the most JavaScript. That means the worst responsiveness on the site frequently occurs at the exact moment the visitor is deciding to commit. Layout instability adds a second failure mode at the same moment, because a shifting page produces mis-taps that read to the user as their own mistake and to you as an abandonment.

You do not need an industry statistic to price this. Segment your own conversion rate by device, then compare sessions on your slowest page templates against your fastest. The gap is your number, measured on your own audience, and it is the only version of the figure a finance team should accept.

Speed as an Ad Efficiency Variable

This is the argument that usually moves budget, because it converts performance work directly into media savings. Google Ads factors landing page experience into ad rank, so the quality of the destination affects both the position you achieve and the price you pay to hold it. Two advertisers bidding identically do not pay identically, and a slow, poorly matched landing page is one of the things that widens the gap.

The second cost is more direct. Every visitor who abandons before the page renders was a click you already bought. That spend produced nothing, it is not recoverable, and it recurs on every impression served for as long as the page stays slow. For an account spending meaningfully every month, performance work on the top landing pages is often the fastest-paying engineering task available, because it reduces waste on traffic you have already committed to purchasing.

Speed as a Crawl and Indexing Variable

Search engines allocate a finite amount of crawling to each site, influenced by how quickly the server responds and how much value the crawler finds. When responses are slow, crawl rate is reduced to avoid overloading the server, which means new and updated pages are discovered later. Content that only exists after client-side JavaScript executes adds another stage, because rendering is queued and processed separately rather than read directly from the initial response.

Be proportionate about this one. For a site of thirty pages, crawl budget is close to irrelevant, and any consultant who leads with it is padding the proposal. For a large catalog or a publisher with changing inventory it is a real constraint: pages crawled late are indexed late, and pages indexed late earn nothing in the window that mattered.

Where the Time Actually Goes

Across most real sites, the same six causes account for the overwhelming majority of failures.

• Render-blocking resources. Stylesheets and synchronous scripts in the document head must be downloaded and processed before the browser paints anything, so every one of them adds directly to LCP. Most sites ship far more CSS and JavaScript on first load than the visible portion of the page requires.
• Unoptimized images in the wrong formats. Serving a large source image scaled down in the browser, using legacy formats where modern ones are supported, omitting responsive sizes so phones download desktop assets, and lazy-loading the hero image so the single most important element is deliberately delayed.
• Third-party scripts and tag manager sprawl. Analytics, heatmaps, chat widgets, review embeds, consent tools, remarketing pixels and abandoned test scripts accumulate over years with no owner and no removal process. Each executes on the main thread, and collectively they are the most common reason INP fails.
• Client-side rendering for content that should be server-rendered. When the initial response is an empty container and the content requires a JavaScript bundle to appear, you have added download, parse and execution time in front of every visitor and every crawler for content that never changes between users.
• Font loading strategy. Multiple weights and styles of a custom font, loaded from a third-party origin without preloading or a sensible display setting, produce either invisible text during load or a visible reflow when the font arrives. The reflow shows up directly in CLS.
• Bloated page builders. Visual editors generate deeply nested markup, load their full runtime on every page regardless of what is used, and frequently ship a stylesheet covering every feature in the product rather than the handful present on the page.

What Actually Fixes Them

The fixes are well understood and mostly unglamorous. They are also ordered, because some create the headroom the others need.

Handle Images Properly

Serve modern formats such as AVIF and WebP with appropriate fallbacks, generate responsive variants so devices download the size they will actually display, and set explicit dimensions on every image so the browser reserves the space before the file arrives. Identify the LCP element and give it priority loading rather than lazy loading it. Lazy loading is correct below the fold and actively harmful applied to the hero.

Render on the Server Where the Content Allows It

Content that is identical for every visitor should arrive in the initial HTML response. Server-side rendering and static generation remove an entire class of delay for both users and crawlers, and reduce the amount of JavaScript required before the page becomes useful. Reserve client-side rendering for genuinely interactive, personalized or authenticated regions, and hydrate those selectively rather than shipping the whole page as an application.

Audit Third-Party Scripts Like a Line-Item Budget

Inventory every tag on the site and require three things for each: a named owner, a stated business purpose, and a decision about whether the value exceeds the cost. Most sites can remove a meaningful share on the first pass because the campaign that needed the tag ended years ago. What survives should load after interaction or on the pages that need it rather than globally, and anything measuring behavior should be evaluated against what it changes rather than against how interesting it is to look at.

Trim the Critical Path and the Fonts

Inline the styles needed for the visible portion of the page and defer the rest, remove unused CSS, defer non-essential scripts, and cut the font payload to the weights actually used. Self-host and preload the fonts that appear above the fold, and choose a display strategy that avoids either invisible text or a late reflow. Then address server response time with caching and a content delivery network, because no amount of asset work compensates for a slow origin.

Performance Is an Architecture Decision, Not a Plugin

The reason optimization plugins disappoint is that they operate at the wrong layer. A plugin can compress images, concatenate files and add caching headers. It cannot change whether your content requires a large JavaScript bundle to exist, whether your platform generates six levels of unnecessary markup, or whether every page loads a runtime built for features you do not use. Those are decisions made when the site was architected, and they set a ceiling that no post-processing step can raise.

This is why performance is cheap to build in and expensive to retrofit. Choosing a rendering strategy that matches the content, keeping the dependency list short and justified, treating the main thread as a scarce resource, and establishing a page weight budget cost nothing during a build. Reversing those decisions afterward means rebuilding the parts of the site that carry the most commercial weight, usually while they are in active use.

It is also why performance regresses without governance. Sites get slower one reasonable request at a time: a chat widget for sales, a heatmap for a research project, a review embed, a pixel for a campaign. Nobody makes a bad decision, and the aggregate fails every threshold. A performance budget enforced in the deployment pipeline and a named owner for third-party scripts prevent more degradation than any annual optimization exercise recovers.

Measure It Against Your Own Revenue First

Start with the pages that carry money: the templates paid traffic lands on, the top organic entry points, and the conversion path itself. Pull field data for each, note which thresholds they miss, then run the lab tools to find the cause. Segment conversion rate by device against those same templates. Within an afternoon you will know whether performance is a real constraint on revenue or a score somebody wants improved for its own sake.

If the constraint is real and the causes trace back to rendering strategy, platform overhead or accumulated dependencies, that is a web development engagement rather than a tuning exercise, and we scope it as one: the architecture changed at the layer where the problem lives, with the commercial pages prioritized first. Where the numbers are acceptable today, our website maintenance work exists to keep them that way, because the realistic failure mode is not a site that was built slow. It is a site that was built fast and left ungoverned.