Website speed and conversions: why a slow page quietly loses the sale

A visitor does not email you to say the page felt sluggish. They close the tab and go to whoever loaded. Website speed and conversions are the same conversation: every extra second of waiting is a person who never saw your offer, never booked, never paid. This is the owner version of page speed and Core Web Vitals — what the numbers actually mean, how they show up in sales, and what you can fix without becoming a performance engineer.

Why does website speed actually change whether someone buys?

People treat waiting as a broken shop. Think with Google's mobile research is the figure owners still quote: more than half of mobile visits are abandoned if a page takes longer than three seconds [5]. That is not a branding problem. That is a closed tab before your headline finished drawing.

Later conversion work put a sales number on the same delay. Portent analysed more than 100 million page views across lead-gen and store sites and found a one-second page converted about three times better for goals than a five-second page, and about 2.5 times better for ecommerce [6]. web.dev's own speed guidance is the same idea without the slide deck: a slow page wastes the click you already paid for [4].

What are Core Web Vitals in plain English?

They are Google's three field metrics for whether a page felt usable to real people, not only to a developer's laptop [1]. You do not need the acronyms for a meeting. You need the jobs they describe.

• Largest Contentful Paint (LCP). Did the main thing — hero, product shot, headline block — show up soon enough? Google's "good" threshold is 2.5 seconds for most visits [7].
• Interaction to Next Paint (INP). When someone taps Book, Add to cart, or a menu, does the page react, or freeze? That is the interactivity metric Search now uses [12].
• Cumulative Layout Shift (CLS). Did the layout jump while they tried to tap, so they hit the wrong button or lost their place? That is visual stability [13].

Search talks about these as part of page experience: a usable page is easier to rank and easier to trust after the click [2] [3]. Lab scores on office fibre can look fine while phones on cellular fail. Field data is the version that matters.

How fast is fast enough for a small-business site?

Fast enough is "the next action is obvious before the visitor gets impatient," not a perfect 100 in a marketing screenshot. Nielsen Norman Group's old response-time limits still explain the feeling: around one second, thought stays in flow; stretch toward ten seconds and attention is gone [11]. Google's LCP "good" line of 2.5 seconds is a practical target for most templates [7]. Think with Google's three-second abandon figure is the warning light if you are slower than that on a phone [5].

Portent's dataset is stricter on money pages. For store transactions they pointed at a one-to-two-second load; for lead-gen goals, one to four seconds still held up much better than anything past five [6]. You will not hit one second on a cheap shared host with a 4MB hero. You can usually get out of the "this feels down" zone with image weight, fewer scripts, and a host that answers quickly.

Does Google still use page speed as a ranking signal?

Yes — as page experience, measured through Core Web Vitals on real users, not as a single "speed score" you can game with one plugin [2] [3]. It is not the only ranking factor. A thin page that loads instantly still loses to a useful page that loads well enough. A useful page that feels broken on a phone still leaves ranking and conversion on the table.

Treat Search Console's Core Web Vitals report as a maintenance check, the same way you would treat a failed backup. Passing "good" on the URLs that already get traffic is the job. Chasing a vanity lab score on a URL nobody visits is not.

Why can a page look loaded and still feel slow?

Because "the hero appeared" and "I can tap something" are different jobs. LCP can look acceptable while INP is poor because a pile of JavaScript is still parsing when the visitor tries to open the menu [12]. CLS can look like a finished page and then shove the Book button down when a cookie banner, font, or late image arrives [13]. Cloudflare's explainer on why speed matters is useful here: perceived performance is what people remember, not the moment the HTML document finished downloading [14].

If customers say "your site is glitchy" and your homepage screenshot looks fine, believe the customers. Walk the live URL on a mid-range phone on cellular. Tap the thing a stranger would tap. If it hesitates, your conversion path hesitates.

What usually makes a small-business website slow?

It is rarely one exotic bug. It is a stack of ordinary choices. The HTTP Archive's performance chapters keep showing the live web is still heavy: large images, third-party scripts, and pages that ask a phone to download more than it needs [10]. Lighthouse will name the same offenders on your URL if you run it [8].

• A hero that is really a billboard. Uncompressed photos, autoplay background video, or a slider with five full-width shots. That is usually your LCP element, and it is usually too big [7].
• Scripts that are not your site. Chat widgets, pixel managers, review carousels, popup builders, and three analytics tools that all load in the head. They steal INP and they fail on flaky networks [12].
• A theme that never says no. Page builders that load every widget on every URL, unused webfonts, and plugins installed for one campaign that nobody removed. That is how a brochure site starts feeling like an app.
• A host that thinks about it. Slow time-to-first-byte makes every later optimisation look worse. You cannot compress your way out of a server that takes a second to say hello.

What can I fix this week without a rebuild?

Start with the path money takes: homepage, the service or product URL that already gets traffic, then the form, book, or checkout step. Do not begin with a new illustration on About. PageSpeed Insights will give you a punch list you can hand to whoever maintains the site [9]. web.dev's speed guidance is the same order of operations: show the main content sooner, then stop fighting the tap [4].

• Shrink the hero. Compress it, serve a modern format, and size it to the layout. If LCP is a 3MB photograph, you do not need a new brand strategy [7] [9].
• Turn off what you cannot name. If you cannot say what a script is for, it does not load on the first screen. Chat and popups can wait until idle — or come off the booking page entirely [12].
• Stop layout jumps. Give images and embeds reserved space so the Book button does not move. That is CLS, and it is a conversion bug wearing a design costume [13].
• Keep it off the junk pile. A one-week pass dies if the next campaign adds two tags and a video banner. Put speed on the same list as updates in why website maintenance matters, and on a small business website checklist before you launch anything new.

If those changes need a pair of hands, that is what website maintenance services are for: image weight, plugin cleanup, and a periodic vitals check — not a full rebuild.

How should I measure speed so I am not guessing?

Use three views, not one screenshot. PageSpeed Insights combines a lab run with Chrome's field data when enough people have visited the URL [9]. Lighthouse in Chrome is the same lab idea you can re-run after each change [8]. Search Console's Core Web Vitals report is the ranking-adjacent view of real users over time [2].

• Test like a customer. Phone, cellular, not office Wi-Fi. A "green" desktop lab score can hide a red mobile LCP [7] [10].
• Watch the URL that sells. Homepage vanity scores lie. Measure the product, service, book, and checkout templates that already get sessions [6].
• Believe field over lab when they disagree. Lab is a recipe. Field is dinner service. web.dev's vitals docs are explicit that real-user data is the source of truth [1].

When is a slow site a redesign problem, not a tweak?

When the theme cannot shed weight. Tables and absolute positioning that will not wrap. A page builder that loads every widget on every URL. A decade of stacked plugins. At that point you are paying for archaeology. That is one of the clearer signs you need a website redesign than "we are bored of the colour."

Patch if the structure is already simple and you mainly need image weight, fewer scripts, and a host that answers. Rebuild if every "quick speed fix" creates a desktop regression, or if Lighthouse keeps pointing at architecture you do not own [8] [10]. Focused website development that treats the first screen as a budget — one hero, one font, one script list — is often fewer hours than fighting a layout that was never meant to be light.

Do stores and booking sites need a different speed standard?

They need a stricter one on the pages where money moves. Portent's research is blunt that checkout, login, home, and high-intent category pages are where delay costs the most [6]. A lookbook that loads in four seconds is annoying. A cart that loads in four seconds is a lost order. If you are scoping e-commerce development, ask to see the product and checkout templates on a mid-range phone in the proposal, not only the homepage mock.

Booking is the same shape with a clock on it. Someone is trying to grab a slot before they get back in the car. If the calendar spinner is the first thing they meet, they will text you instead — or they will book the competitor whose page answered. Stripe or PayPal on a store, or a confirmation screen after a booking, should feel instant enough that the visitor never wonders whether the tap worked [12] [14].

What should I ask a developer before they touch performance?

Ask for a budget, not a vibe. Google's vitals docs and Search's page-experience language are fair contract wording: field LCP, INP, and CLS on the templates that already get traffic [1] [2] [3]. If they cannot talk about image weight and third-party scripts, the hero video will win and your vitals will lose [7] [12].

• Which URLs are in scope? Homepage plus the money path. "We will make the whole site faster" with no URL list is how you pay for a homepage-only pass.
• What is the LCP element today, and what will it be after? If they have not identified it, they have not started [7] [9].
• Which third-party scripts stay on the first load? Everything else waits or leaves. That is an INP decision, not a branding one [12].
• How will you prove it? Before-and-after PageSpeed Insights and Search Console, plus a real-phone walk-through. A Lighthouse screenshot from a desktop profile is a sketch [8] [9].

If you are comparing quotes, put that checklist next to website pricing so you are buying a performance pass with a finish line, not an open-ended "optimisation" retainer.

How much should I budget to make a slow site faster?

A cleanup — compress the hero, drop unused plugins, delay chat, fix CLS — is a maintenance ticket. A new host plus image pipeline is a small project. A theme that cannot shed scripts is a rebuild. The HTTP Archive data is the industry backdrop: pages are still heavy, so "we already have a speed plugin" is not a strategy [10]. Nielsen's limits are the human backdrop: people will not wait politely because your brand is nice [11].

Budget the money path first. If product, book, and checkout are acceptable on a real phone, you can live with a heavier About page for a quarter. If the homepage LCP is a video and the form takes two seconds to notice a tap, you are not shopping for a new colour palette. Send the live URL and a screenshot of PageSpeed Insights on mobile. We will tell you if you need a weekend pass, a host change, or a project — and we will not pretend a slider will fix a three-second abandon [4] [5].