Why Website Speed Changes Your Revenue

The request we hear most often when building a new website is "please make it beautiful." A few months later, the sentence we hear most often is "why aren't inquiries growing?" Between those two questions sits a cause that rarely gets named: speed. Design is visible, so it gets discussed. Slowness only reveals itself as visitors quietly leaving.

A slow site never complains. People just go back. That is why owners notice the problem late. This article goes past the obvious "speed matters" and lays out what to measure and what to fix first, without the developer vocabulary. By the end you will be able to check your own site and describe improvements in concrete terms.

One second costs more than you think

Human patience for a loading screen is remarkably short. What field studies consistently show is that bounce climbs noticeably as loading stretches from one second to three. Past three seconds, a meaningful share of visitors hit back before they see anything. If you paid for that visitor through advertising, the bounce is a direct cost.

What matters is that this loss is not evenly distributed. The first to leave are first-time visitors — people who have no reason to trust you yet. Regulars will wait through a little slowness. New customers will not. So a speed problem does not show up as "traffic dipped slightly." It shows up as "new customers never stick."

On a slow site, the first person to leave is exactly the first-time visitor you most wanted to keep.

Search visibility compounds this. Google has said for years that page experience is one of its ranking signals. Speed alone will not flip a ranking, but between two pages of comparable content quality it tips the scale. A slow site loses visitors, and through that loses visibility too. The loss happens twice.

Core Web Vitals, without the jargon

Google distilled perceived speed into three metrics called Core Web Vitals. The names are unfamiliar, but the questions each one asks are plain common sense.

LCP — "when does the important thing appear?"

It measures when the largest element on screen — usually the hero image or a big headline — shows up. That moment lines up almost exactly with when a visitor thinks "ah, it loaded." Under 2.5 seconds is good; past 4 seconds needs work. The cause is usually singular: the hero image is too heavy.

INP — "does it respond when I tap?"

The time between tapping a button or menu and the screen reacting. Under 200 milliseconds feels instant; slower and people tap again. A submit button pressed twice becomes a duplicate inquiry, and to the user it is remembered as broken.

CLS — "does the page shift while I read?"

When an image or ad loads late and pushes the text you were reading downward. This is where "I tapped the wrong thing" comes from. Of the three it is the most reliably irritating, and also the easiest to fix: give images explicit width and height so the browser reserves the space.

Always judge on mobile, and on a first visit

The most common mistake is "it's fast on my machine, so we're fine." An office desktop sits on wired internet, and your browser already holds your site's images in cache. In other words, you always view your site as a returning visitor — under the most favorable conditions possible.

Most real visitors open your site for the first time on the subway, while walking, on a phone that is a few years old. So test on mobile, as a first visit. A private browsing window is enough to approximate the uncached first-visit state.

Two tools are enough to get numbers.

• PageSpeed Insights — paste a URL and it reports mobile and desktop scores alongside the three metrics. Sites with enough real traffic also get field data.
• The page experience report in Search Console — shows data from actual visitors, grouped by page type. Good for finding which kind of page is the problem.

Do not fixate on a single score. Moving 40 to 70 leaves far more revenue behind than polishing 90 into 100. The goal is not a perfect score; it is a state where visitors never wait.

This is usually where it gets slow

Open enough sites and the causes of slowness look remarkably alike. Most of them are fixable without a rebuild.

• Images uploaded at original size — the most common, and the highest impact. A 5MB phone photo uploaded as-is still transfers 5MB even when it displays small. Resize to the display size and convert to a modern format like WebP, and a tenth of the original weight is a normal result.
• Too many third-party scripts — ads, analytics, chat widgets, fonts, heatmaps. Each feels light when added; together they are heavy. This is the main culprit behind poor INP. If a tool has gone unread for six months, delete that one first.
• Web font overload — loading two typefaces in every weight leaves the screen blank until the text arrives. Keep only the weights you actually use, and subset large character sets.
• Images without dimensions — nearly the only cause of CLS. Writing width and height solves it.
• Slow hosting — if the server is late with its first response, every optimization after it is moot. Worth checking whether responses come from a region near your visitors and whether static files are served from a CDN.

What you can do this week

There is no need to wait for a redesign. Doing these in order, one at a time, already changes how the site feels.

• 1. Measure — run your three most important pages (home, main service, contact) through PageSpeed Insights and write down the mobile scores. You need a before number to claim an after.
• 2. Shrink the single heaviest image — usually the hero on the home page. Doing this one properly often moves LCP visibly on its own.
• 3. Delete unused scripts — the old analytics tool, the chat widget nobody answers, the tag added for a test.
• 4. Set dimensions on images — the shifting-layout problem disappears.
• 5. Measure again — same pages, same conditions, and compare.

These five steps usually fit inside a day, and afterwards staying fast is mostly a matter of watching image sizes as you publish. Speed is not something you build once; it is something you maintain. If every new post adds one oversized photo, the site will be slow again in six months.

A fast site is a trust question

Treat speed as purely technical and it will always lose the priority argument. But to a visitor, loading is a first impression. When a shop door sticks, we start doubting the products. Websites work the same way. A site that opens quickly quietly signals that this company does careful work.

At ononc we treat image optimization and Core Web Vitals as defaults, not extras. If the speed of a site you already run is bothering you, we are happy to start by reviewing where it stands — laid out so you can see, in numbers, what improves when you fix what.