A customer taps your link. The screen sits white for a second. Then two. A logo flickers in, an image shoves the text down, a button jumps just as they reach for it.
They’re gone. They hit back and tapped the next result before your site ever finished loading.
You never saw it happen. There’s no notification for “person left because the page was slow.” But it happens all day, and it’s the kind of leak that doesn’t show up in any report you’re looking at.
Speed Is Money, Measured Directly
This is measurable, not a hunch. The relationship between load time and lost business is one of the most studied things on the web.
Every extra second of load time pushes your bounce rate up — more people leave before they do anything. And it pushes conversions down — fewer of the people who stay actually call, book, or buy. The first few seconds are the steepest part of the curve, which is exactly where most small-business sites are losing the race.
Then there’s Google. Site speed is a ranking factor. A faster site doesn’t just keep the visitors it gets — it gets ranked higher, so it gets more visitors in the first place. Slow sites lose on both ends: fewer people find them, and more of the ones who do bounce.
You’re paying for that twice.
Core Web Vitals, In Plain English
Google measures real-world speed with three numbers called Core Web Vitals. The names are jargon, but each one maps to something a normal human would notice. Here’s what they actually mean.
| Metric | What it stands for | What a visitor feels |
|---|---|---|
| LCP | Largest Contentful Paint | How long until the main thing on screen actually shows up |
| CLS | Cumulative Layout Shift | Whether the page jumps around while it loads |
| INP | Interaction to Next Paint | How fast the page reacts when they tap or click |
LCP — load speed
LCP is the moment the biggest visible element — usually your hero image or headline — finishes painting. It’s the honest answer to “when did this page feel loaded?” If your LCP is slow, visitors are staring at a blank or half-built screen, deciding whether to wait.
CLS — layout stability
CLS measures how much the page shifts around as it loads. You’ve felt this: you go to tap a link and an ad or image loads above it, the whole layout lurches, and you tap the wrong thing. A high CLS feels broken and cheap even when everything technically works.
INP — responsiveness
INP measures how quickly the page responds when someone interacts with it. They tap “Book Now” and… nothing, for a beat, while the browser chews through scripts. That hesitation reads as “this is broken,” and broken sites don’t get second chances.
Three numbers. Did it load fast, did it hold still, did it respond. Get those right and the rest follows.
Why Most Small-Business Sites Are Slow
Here’s the uncomfortable part: most slow sites weren’t built to be slow. They got that way one convenient decision at a time.
- Bloated page builders. Drag-and-drop builders are easy to use, and they pay for that ease by shipping mountains of generic code to the browser. The visitor downloads the weight of every feature the builder could do, whether your page uses it or not.
- Plugin pileup. A plugin for the contact form, one for the popup, one for the slider, one for analytics, one for the cookie banner. Each one loads its own scripts and styles. Stack up a couple dozen and the browser is assembling a small application just to show your hours and phone number.
- Gigantic unoptimized images. This is the single most common killer. Someone uploads a photo straight off a phone or a stock site — a huge file sized for a billboard — and the browser has to drag that whole thing down a phone connection before the page can settle. One oversized hero image can blow your LCP all by itself.
- Heavy third-party scripts. Chat widgets, tracking pixels, embedded maps, social feeds, font services. Every one is a request to someone else’s server, and your page often waits on the slowest one in the pile.
None of these are evil on their own. Together they turn a simple five-page site into a heavyweight that makes phones wheeze.
Fast By Default Is a Choice You Make Up Front
You can’t reliably bolt speed onto a bloated site afterward. The bloat is the site. The fix is to not build it heavy in the first place.
That’s the whole idea behind how we build. A lean, statically-built site ships finished pages — the HTML is already assembled, so the browser isn’t running a builder’s engine just to draw your homepage. Images are optimized and sized correctly for the device asking for them, instead of forcing a phone to download a desktop-sized file. Third-party scripts get questioned, not stacked. The result loads fast because there’s simply less to load.
Here’s the difference in one picture:
Bloated page builder site Lean static site
----------------------- -----------------------
Builder engine .............. ❌ Pre-built HTML ......... ✅
20+ plugins ................. ❌ Only what's needed ..... ✅
Full-res phone photos ....... ❌ Right-sized images ..... ✅
Pile of 3rd-party scripts ... ❌ Questioned, not stacked ✅
Result: visitor waits. Result: it's just there.Fast by default comes standard with building things the right way instead of the convenient way. Good Core Web Vitals fall out of that approach on their own. You don’t chase the metrics; you build so they’re already green.
The Quiet Part
The brutal thing about a slow site is how invisible the cost is. Nobody emails to say “I would have booked but your page took four seconds.” They just leave, and you keep paying for ads and SEO that send people to a site that drops a chunk of them at the door.
Speed is the cheapest conversion improvement you’ll ever make, because you’re not buying more traffic — you’re stopping the leak in the traffic you already have.
If your site feels slow to you, it’s slower for the customer on a three-year-old phone and a weak connection. That’s the person you’re losing. Let’s build you something that’s fast before anyone has to ask. Take a look at how we approach web development and we’ll get your site loading like it should.