Why Website Speed Sells: The Revenue Math of a Fast Site

Website speed is a revenue lever, not a technical vanity metric. Studies by Google and others have repeatedly found the same pattern: conversion rates drop measurably with each additional second of load time, and the majority of mobile visitors abandon a page that takes more than about 3 seconds to show them something. You paid for that visitor, through ads or SEO or word of mouth, and the slow page refunded them to a competitor.

The math is what makes this worth a business owner's attention. Suppose your site gets 5,000 visits a month and converts 2% of them into inquiries worth an average of $500 each. That is $50,000 a month in pipeline. If shaving two seconds off your load time lifts conversion from 2% to 2.4%, a modest and commonly observed kind of improvement, you just added $10,000 a month without spending another dollar on traffic. Few marketing changes have that ratio of cost to return.

Core Web Vitals, translated for humans

Core Web Vitals are the three numbers Google uses to grade how your page feels to a real visitor, and they feed directly into its ranking systems. Each one maps to a moment of frustration you have personally felt on someone else's website.

LCP: how long until the main thing shows up

Largest Contentful Paint measures the time from tapping a link to seeing the page's main content, usually the hero image or headline. To a visitor, LCP is the difference between "this site works" and staring at a blank screen wondering if the tap registered. Google's threshold for good is 2.5 seconds; past 4 seconds it grades the page as poor, and your visitors graded it earlier than that.

INP: how fast the page reacts when touched

Interaction to Next Paint measures the delay between a visitor's tap or click and the page visibly responding. Bad INP is the menu that opens a beat too late, the button you press twice because nothing happened the first time. It usually comes from too much JavaScript doing too much work, and it makes a site feel broken even when everything technically functions.

CLS: how much the page jumps around

Cumulative Layout Shift measures how far content moves while the page loads. It is the reason you tapped "Accept" when you meant "Decline," because a late-loading banner shoved everything down at the wrong moment. Visitors experience high CLS as a site that fights them, and Google scores it accordingly.

What actually makes sites slow

Four culprits account for most of the slow business sites we audit, and each one has a known price and a known payoff.

• Oversized images. The most common offender by far: a 4 MB photo straight off a phone camera, displayed at 400 pixels wide. Compressing and resizing images, serving modern formats like WebP, and lazy-loading anything below the fold routinely cuts page weight by more than half. This is usually the cheapest fix with the largest LCP improvement.
• Bloated themes and plugins. Page builders and plugin stacks ship JavaScript and CSS for every feature they offer, whether your site uses it or not. Every unused slider library is code your visitor's phone must download and parse. Trimming or replacing the heaviest offenders is slower work, but it is where most INP problems live.
• Cheap hosting. A crowded shared server can spend 500 to 800 milliseconds thinking before it sends the first byte. Nothing you do to the front end recovers time lost before the page starts. Moving to competent hosting typically costs a few dollars more a month and buys back that entire delay.
• Third-party scripts. Chat widgets, heatmaps, tag managers, three analytics tools, and a retargeting pixel from a campaign that ended last year. Each one is a separate connection and more code. Auditing them annually and cutting the dead ones is free, and it is the fix that most often surprises owners with how much it recovers.

Nobody has ever left a website because it loaded too fast.

The triple tax on a slow site

Speed compounds, which is why the slow site loses three times on the same weakness. First, Core Web Vitals feed Google's rankings, so the slow site sits lower in results and earns fewer clicks. Second, the visits it does earn bounce at a higher rate, and the engagement signals from those short visits reinforce the lower ranking. Third, the visitors who stay convert at a reduced rate, so even the surviving traffic is worth less.

Run in reverse, the same loop pays you three times. A fast site ranks a little better, keeps more of each click, and converts more of the visitors it keeps. This is why we treat speed work as part of SEO rather than a separate technical chore: it is one of the few investments that improves acquisition and conversion in the same move. It also feeds the newer answer surfaces; our post on SEO vs AEO vs GEO covers why crawl and speed basics come first even when the goal is showing up in AI answers.

How to measure speed honestly

Use PageSpeed Insights, and read the top section before the score. That top section shows field data from the Chrome User Experience Report (CrUX): the real Core Web Vitals of your actual visitors over the past 28 days, on their real phones and connections. The Lighthouse score below it is lab data, one simulated load under fixed conditions. Lab data is useful for diagnosing problems; field data tells you whether you have one. When the two disagree, believe the field data, because that is also what Google's rankings use. And test your money pages, not just the homepage; the contact page that loads in 6 seconds is the one costing you inquiries.

The fix list, in order of return

Hand this to your developer as written. The order matters: the early items are cheap and usually recover the most time.

1. Run PageSpeed Insights on your five most-visited pages and record the CrUX field numbers as a baseline. You cannot claim a win you never measured.
2. Compress and resize every image, serve WebP or AVIF, and lazy-load everything below the fold.
3. Check server response time. If time to first byte regularly exceeds 500 milliseconds, move hosting or add caching before touching anything else.
4. Put the site behind a CDN and enable full-page caching so repeat loads are nearly instant.
5. Audit third-party scripts and delete every tag that no longer earns its keep.
6. Defer non-critical JavaScript and remove unused plugin or theme code, the main INP work.
7. Set explicit dimensions on images, ads, and embeds so the layout stops shifting.
8. Re-measure after 28 days, when CrUX has fresh field data, and compare against the baseline.

On most small business sites the first five items are a week of work, and they routinely take a 6 second page under 3. The remaining items are refinement, worth doing once the big wins are banked.

Measure first, then fix what moves the needle

The honest version of speed work starts with measurement, because the slowest thing on your site is rarely the thing you would guess. We have audited sites where the owner wanted a new theme and the actual problem was one 8 MB background video, and sites where every image was pristine but the hosting added a full second before anything happened. Fixing the wrong thing feels productive and changes nothing.

That measure-first approach is how we run performance work inside our SEO engagements, and how we build new sites so they never need rescuing in the first place: lightweight pages, right-sized images, no plugin sprawl. If your site takes more than 3 seconds to load on a phone, you now know roughly what that costs each month. The fix is almost always cheaper.