Why Is My Small Business Website Slow? The Four Causes and How to Check Yourself

A slow website is almost never slow for mysterious reasons. In nearly every small business site I have looked at, the delay traces back to one of four causes: oversized images, too many third-party scripts, a heavy theme with plugins stacked on top, or cheap shared hosting. You can identify which one you have in about twenty minutes, for free, without being technical, and three of the four are fixable without rebuilding anything.

This post is the diagnosis, not the sales pitch. If you read to the end and conclude that you need to compress some images and delete two tracking scripts, that is a good outcome and it costs you nothing.

What counts as slow?

Google publishes specific thresholds, which is useful because it replaces opinion with numbers. Three metrics, collectively called Core Web Vitals:

Largest Contentful Paint (LCP) is how long until the biggest visible thing on the screen finishes loading, usually your hero image or headline. Good is 2.5 seconds or less. This is the one small business sites fail most often, and it is almost always an image problem.

Interaction to Next Paint (INP) measures how quickly the page responds when someone taps or clicks. Good is 200 milliseconds or less. This replaced the older First Input Delay metric in 2024. Failures here are usually caused by scripts occupying the browser while the visitor is trying to use the page.

Cumulative Layout Shift (CLS) measures how much the page jumps around while loading. Good is 0.1 or less. You have felt this one: you go to tap a link, an ad or banner loads above it, and you tap the wrong thing. It is caused by elements that do not reserve their space before they load.

Two things worth knowing about how these are judged. They are assessed at the 75th percentile of real visits, meaning three quarters of your visitors need a good experience, not your best-case test on office wifi. And Google’s field data comes from actual Chrome users, so a site with little traffic may have no field data at all and will be judged on lab simulation instead.

Speed is a ranking factor, but a modest one. Do not expect a compressed image to move you from page three to page one. The real payoff is that people leave slow sites, and every visitor who leaves before your page renders is a lead you paid for and did not get. That is the argument, not the ranking.

Cause 1: Your images are enormous

This is the single most common cause, by a distance. Someone uploads a photo straight from a phone or a stock library at 4000 pixels wide and several megabytes, the site displays it in a 600 pixel box, and every visitor downloads the full file anyway so the browser can shrink it.

What a correctly handled image looks like: sized to roughly the dimensions it will actually display, saved in a modern format (WebP or AVIF rather than a raw JPEG or PNG), typically well under 200 kilobytes for a photo, with width and height set so the browser reserves the space before it arrives, and with images below the fold set to load lazily so they do not compete with the part of the page the visitor can see.

The fix is usually an afternoon and free. Most site platforms will convert and resize on upload if you turn the setting on, and any free image compressor will handle the existing library. This one change fixes more failing LCP scores than everything else on this list combined.

Cause 2: Third-party scripts you forgot you installed

Every tracking pixel, chat widget, popup builder, review carousel, heatmap recorder, and analytics tag is code loaded from someone else’s server, and your page waits on it. Sites accumulate these the way garages accumulate boxes. I regularly find a dozen on a site with one employee, including tags for advertising platforms the business stopped using two years ago.

Two specific offenders worth naming. Live chat widgets are heavy and frequently load before anything else. If yours produces two conversations a month, it is not paying for the visitors it costs you. Embedded video loaded directly into the page can pull in a large player script for every visitor whether or not they press play; use a click-to-load thumbnail instead.

The fix: list every script on your site, and for each one answer when you last used its data. Delete the ones with no answer. This is free and takes an hour.

Cause 3: A heavy theme with plugins stacked on it

Page builders and multipurpose themes are convenient and they ship a lot of code your particular site does not use. Add fifteen plugins, each loading its own stylesheet and script on every page, and you have a site where a contact page loads the machinery of an online store.

The signals that this is your problem: a homepage that pulls in several megabytes of code, dozens of separate file requests, and a page that looks finished but does not respond to taps for another second or two.

Honest assessment: this is the hardest of the four to fix incrementally. You can audit plugins, remove what you do not use, and consolidate overlapping ones, which helps. Sometimes the platform itself is the ceiling, and that is one of the few situations where rebuilding is genuinely the cheaper path. I laid out how to make that call without an agency pitching you in website redesign or fix what you have, and the short version is that you rebuild when the platform blocks the fix, not when the site looks dated.

Cause 4: Hosting that costs less than lunch

Budget shared hosting puts hundreds of sites on one machine. When a neighbor gets a traffic spike, your server response time is what suffers. The number to look at is time to first byte, how long the server takes to start answering at all. A slow first byte means no amount of image compression will save you, because nothing has started yet.

There is a useful distinction here. Static sites are pre-built pages served from a content delivery network, meaning there is effectively no server work per visit and the page comes from a location near the visitor. This is how the site you are reading is built, which is why it loads quickly on a modest budget. Dynamic sites assemble each page on request, which is necessary for genuinely dynamic functionality and unnecessary for a brochure site that changes monthly. Most small business sites are paying the cost of dynamic assembly for content that never changes.

Caching helps a dynamic site considerably and is usually a single plugin or a hosting setting. If your host charges extra to enable basic caching, that tells you something about the host.

The free 20-minute self-check

Do this in order. Everything here is free.

1. Run PageSpeed Insights on your homepage and your most important service page. Google’s own tool, and it reports both real-visitor field data and a lab test. Test on mobile, because mobile is where sites fail and where most of your traffic is.
2. Read the three vitals, not the overall score. The score out of 100 is a weighted composite that moves around between runs. LCP, INP, and CLS are the ones Google actually uses.
3. Open the opportunities list and look at the top three only. It is typically sorted by impact, and the first few items usually account for most of the problem. Ignore the long tail.
4. Check the page weight. If your homepage is over about two megabytes, you have an image or script problem regardless of what any score says.
5. Check server response time. If time to first byte exceeds roughly 600 milliseconds consistently, that is your hosting, and it is the first thing to fix.
6. Load your own site on a phone on cellular data, not office wifi. This is the experience your visitors actually have, and it is sobering.

That sequence tells you which of the four causes you have. Images and scripts you can fix yourself this week. Hosting is a migration. The theme is a decision.

How to tell a real fix from an upsell

When you take this to a developer or agency, the proposals divide cleanly.

Reasonable: compress and convert the image library, remove unused scripts and plugins, enable caching, move to better hosting, defer non-critical code, add width and height attributes to stop layout shift. These are specific, verifiable, and mostly inexpensive.

Be careful with: a full rebuild proposed before anyone has run a diagnostic, a monthly “speed optimization” retainer with no defined work, a promise of a perfect score of 100 (chasing the last few points is usually wasted money), or a claim that speed work will fix your rankings. Speed is one input among many. If the goal is more phone calls, your Google Business Profile is probably the higher-leverage place to spend that hour.

Also worth knowing: much of this belongs in routine upkeep rather than a project. Image discipline on upload, a periodic plugin audit, and quarterly vitals checks keep a site from degrading in the first place, which is why they sit in the website maintenance routine I recommend.

What to do this week

Start with images. Convert and compress the library, set the platform to resize on upload, and re-test. Then remove the scripts nobody uses. Then check your server response time and decide whether hosting is the next bill worth changing. Re-run PageSpeed Insights after each step so you can see what actually moved, and wait a few weeks before judging the field data, since it reflects a rolling window of real visits rather than the change you made an hour ago.

If you work through that and the site is still slow, the platform is likely the ceiling, and that is a different conversation. I build small business websites as static sites served from a CDN specifically because it removes most of this category of problem at the foundation instead of patching it later. Happy to look at your PageSpeed report and tell you whether you have an afternoon of cleanup or a structural problem, which are very different bills.

Frequently asked questions

How fast should a small business website load?

Aim for a Largest Contentful Paint of 2.5 seconds or less on mobile, measured for real visitors rather than on a fast office connection. Interaction to Next Paint should be at or under 200 milliseconds and Cumulative Layout Shift at or under 0.1. Those are Google’s published thresholds for a good experience.

Does website speed affect Google rankings?

Yes, but modestly. Core Web Vitals are a ranking signal, and they matter most as a tiebreaker between pages of similar relevance and quality. Content that answers the query still dominates. The stronger commercial reason to fix speed is that visitors abandon slow pages before they ever see your offer.

Why is my website slow on mobile but fast on desktop?

Because your desktop test uses a fast connection and a powerful machine while your visitors use cellular networks and mid-range phones. Large images hurt far more on a slower connection, and JavaScript takes longer to execute on a phone processor. Always judge your site by the mobile results.

Do plugins slow down a website?

Individually, most are harmless. Collectively they are the problem, because many load their own scripts and stylesheets on every page whether that page uses the feature or not. The issue is usually the accumulation and the overlap rather than any single plugin, so audit for what you no longer use.

Is it worth paying for faster hosting?

If your server response time is consistently above roughly 600 milliseconds, yes, because nothing else you fix will matter much until the server starts answering faster. If your response time is already fast and your images are five megabytes, better hosting will change nothing and you should fix the images.

Can I fix my website speed myself?

Usually a good part of it. Compressing images, enabling caching, and deleting unused tracking scripts require no code and address the majority of slow small business sites. Theme-level problems and hosting migrations are where outside help starts to earn its cost.

The one-sentence version

Before anyone sells you a rebuild, run PageSpeed Insights on your phone, compress your images, and delete the tracking scripts you stopped using, because that is the whole fix more often than the industry would like to admit.

---

Jose Lugo is a CISSP-certified security engineer with 12 years of U.S. Army intelligence experience. He builds secure AI work environments and fast, maintainable websites for businesses at josecustom.ai. See his portfolio of 13 live client systems at portfolio.josecustom.ai.