You probably check your website on the office Wi-Fi, on a laptop, with the page already cached from the last hundred times you looked at it. It seems fine.
Your customers see it on a phone, in a parking lot, on one bar of signal, for the first time. For them it may be a white screen, then a photo that draws itself in slowly, then a menu button that does nothing for a second when they tap it. Plenty of them won’t wait to find out what comes next. They go back and tap the next result.
That’s the cost. It doesn’t show up as a bill. It shows up as people who were looking for exactly what you sell and left before they saw it.
What slow actually costs
There are three costs, and the first one is the biggest.
People leave. Someone who searched “bakery near me” has four other bakeries a tap away. A page that sits blank for a few seconds loses some of them, and you never find out who. Your analytics, if you have any, often don’t even count them, because they left before the tracking script loaded.
You pay for clicks that never land. If you run any ads, every visitor who gives up on a slow page is a click you paid for and got nothing from.
Google notices, a bit. Google uses page experience, including the three speed measurements below, as one of the signals it ranks by. It is not the main one. Google has been clear that a relevant page beats a fast irrelevant one. But between two similar local businesses, a site that works well on a phone is not at a disadvantage, and a slow one might be.
There’s a fourth, smaller cost. A heavy page uses up your customer’s mobile data, and people on cheap or prepaid plans notice that even if you don’t.
Google’s three numbers, in plain words
Google measures speed with three numbers it calls Core Web Vitals. They sound technical. They describe things every visitor feels.
Largest Contentful Paint (LCP): when the main thing shows up. It’s the time until the biggest thing on the screen, usually your main photo or your headline, has finished appearing. Think of a restaurant. Bread on the table is nice, but you judge the wait by when your meal arrives. Google calls 2.5 seconds or less good and more than 4 seconds poor.
Interaction to Next Paint (INP): whether it responds when you tap. It’s the delay between someone tapping a button, opening a menu or typing in a box, and the page visibly reacting. Picture a light switch that waits half a second before the light comes on. You’d flick it again, and wonder if it was broken. Good is 200 milliseconds or less, a fifth of a second. Poor is more than half a second.
Cumulative Layout Shift (CLS): whether things jump around while it loads. You go to tap “Call us” and a banner loads above it, the button drops, and you’ve tapped “Directions” instead. It’s like someone moving the door handle as you reach for it. This is a score rather than a time; 0.1 or less is good, more than 0.25 is poor.
One detail matters for reading your results: Google judges each number by the slower end of your real visitors. Roughly, three out of four visits have to be good for the number to count as good. A page that’s quick on your laptop and slow on an older phone is slow, as far as Google is concerned.
Five usual culprits
I’ve looked at a lot of slow small business sites. The causes repeat.
Photos straight off the camera
A photo from a modern phone is often several megabytes and thousands of pixels wide. Upload that to a page where it’s shown at the size of a postcard and every visitor downloads the whole thing anyway. One of those at the top of your home page can, on its own, push your main-content time past the line. Three in a gallery and the page is heavy before anything else has loaded.
This is the most common problem and the cheapest to fix.
The page builder
Drag-and-drop builders and do-everything themes are convenient for you and expensive for your visitor. To let you put anything anywhere, they ship code for everything everywhere: animation libraries, layout systems, styles for features you never turned on. Each one is reasonable. Together they’re a lot of code the phone has to download and run before the page will respond to a tap.
You can’t always fix this from inside the builder. It’s the main reason a rebuild sometimes makes more sense than a cleanup.
Things bolted on
Most of what makes a small business site slow isn’t the site. It’s what got added to it over the years:
- A chat bubble you stopped answering.
- Two or three tracking pixels from ad accounts you no longer use.
- A tag manager loading more scripts than anyone remembers adding.
- An Instagram feed, a reviews carousel, a booking widget, an embedded map, a YouTube video.
Each of these loads code from somebody else’s server, often a lot of it, and some of it competes for the phone’s attention right when the visitor is trying to tap something. That’s usually where a bad INP comes from. Chat widgets and embedded feeds are frequent offenders.
Cheap hosting
On the cheapest shared hosting, your site sits on a busy server with a great many others, and every visit has to wait for that server to build the page. If PageSpeed Insights flags a slow “server response time” or “time to first byte”, this is the likely reason. It sets a floor nothing else can get under. No amount of photo compression helps if the server takes a second and a half to start answering.
Sliders and background videos
The rotating banner of five photos at the top of a home page loads five large images to show one, usually adds a script to animate them, and few visitors wait to see the second slide. A full-screen background video is heavier still. Both sit exactly where Google measures your main-content time. One good photo and one clear sentence will almost always do the job better.
Test it yourself in under ten minutes
Do this now: go to PageSpeed Insights (pagespeed.web.dev, Google’s free tool), paste in your home page address, and run it. It will show the mobile results first. Stay there; that’s where your customers are.
You’ll get two sections, and the difference matters.
The top section is real visits. If your site gets enough traffic from Chrome users, Google shows how your actual visitors experienced it over the last 28 days, with the three numbers above, each marked good, needs improvement or poor. This is the part Google uses. Many small sites don’t get enough visits for it to appear. That’s normal and doesn’t mean anything is wrong.
The section below is a test run. Google loads your page once on a simulated mid-range phone over a slowish mobile connection, and gives you a performance score out of 100 and a list of suggestions. Three things to know before you react to the score:
- It’s a deliberately harsh test. A score in the 50s doesn’t mean your site is broken.
- It wobbles. Run it twice and you may get scores several points apart. Look at the trend over a few runs, not a single number.
- The test run can’t measure INP, because nobody taps anything. It shows “Total Blocking Time” instead, which is a reasonable stand-in: if it’s high, taps are probably slow too.
Then do two specific things. Find the line that names your Largest Contentful Paint element. It tells you exactly which photo or block of text the main-content time is waiting for, and very often it’s the hero image or the slider. And scroll the list of suggestions for anything mentioning images, “third-party code”, or server response time. Those are the culprits above, by name.
Finally, put your phone on mobile data, open a private tab, and load your site as a stranger would. Watch what appears first, what jumps, and how long before you can tap the menu. Ten seconds of this teaches you more than the score.
Fixes, in order of payoff
Do these roughly in this order. The first two fix most of the small business sites I see, and neither needs a developer.
1. Shrink your images
Resize each photo to no more than about twice the width it’s actually shown at. For a full-width banner, roughly 2,000 pixels wide is plenty; for a photo in a column, much less. Then compress it. Free tools do this in the browser, and modern formats like WebP and AVIF are much smaller for the same quality. Most site platforms and WordPress plugins can do this automatically for new uploads, but check: the photos you uploaded years ago probably weren’t done.
If you or someone technical can edit the page code, two more things help. Give each image its width and height so the page saves room for it and nothing jumps when it loads. And set images further down the page to load only when the visitor scrolls near them (loading="lazy"), but never the main image at the top. Lazy-loading that one makes your main-content time worse, not better.
2. Remove what you don’t use
Open your site’s settings, plugin list, tag manager, or the code that goes in the page header, and make a list of every outside thing it loads. For each one ask: who looks at this, and when did they last? Ad pixels for campaigns that ended, the analytics tool you replaced, the chat widget nobody answers, the popup. Delete them.
This often does more for how fast the page responds to a tap than anything else on this list. It also stops sending information about your visitors to companies you no longer do business with, which is worth doing for its own sake.
3. Replace the slider and the video
One strong photo, sized properly, with a clear headline: what you do, where, and how to reach you. If the video matters, put a still image with a play button and load the video only when someone taps it.
4. Make embeds wait for a tap
An embedded Google Map or YouTube video loads a lot of code even if nobody touches it. Use a picture of the map, linked to Google Maps, and a thumbnail for the video that loads the player on tap. Visitors lose nothing, and the page gets much lighter.
5. Better hosting, and a CDN
If the server itself is slow, move. Hosting that serves your pages from a network of locations close to the visitor (a CDN, short for content delivery network) is now cheap, and for a small site it’s often free. Many platforms include it. This doesn’t help much if the page itself is heavy, which is why it’s fifth.
6. Fewer fonts
Each typeface, and each weight of it (regular, bold, italic), is a separate download. Two fonts in two weights each is usually enough. The fonts already built into phones and laptops cost nothing to load and look fine.
When to stop fixing and rebuild
Sometimes the honest answer is that the site isn’t worth patching. Some signs:
- You’ve shrunk the images and removed the extra scripts, and the page is still slow, because the theme or builder itself is the weight.
- The fixes you need can’t be done on your platform, or each one needs a plugin that adds more weight.
- Nobody knows how the site was built anymore, or who has the logins.
- It was built before phones were the main way people visit, and it shows.
- Paying someone to untangle it would cost about as much as starting clean.
A rebuild doesn’t have to be a big project. A small business site with a handful of plain pages, properly sized photos and no bolted-on extras will be fast almost by default. Most speed comes from leaving things out, not from clever tricks.
If you do rebuild, keep the same page addresses where you can, or set up redirects from the old ones, so you don’t lose the links and search history the old site built up.
The short version
A slow site rarely has one dramatic problem. It has a heavy photo, a forgotten pixel, a chat bubble, a slider, and a busy server, each a little bit bad, added up. You fix it the same way: one at a time, biggest first, testing as you go.
Start with your images and your scripts this week. Run PageSpeed Insights before and after so you can see what changed. If the numbers barely move after that, you’ve learned something useful too: the problem is the foundation, and it’s time to decide whether to rebuild.