Why Small Business Websites Get Slow

A website is fast on launch day and slow three years later, and nobody can point to the day it changed. That is because nothing changed on any single day. It accumulated.

Here is what accumulates, roughly in order of how much damage it does.

Images nobody resized

This is the biggest one, and it is not close. Somebody uploads a photo straight off a phone — 4,000 pixels wide, four megabytes — into a slot that displays it at 600 pixels. The browser downloads the whole four megabytes and throws away 97% of the data before drawing it.

Do that on twenty pages and the site is carrying tens of megabytes it does not need. On a phone on rural broadband, which is a substantial share of traffic across Southeast Ohio and West Virginia, that is the difference between a page that loads and a page somebody abandons.

The fix is unglamorous: resize to the largest size actually displayed, save as WebP, and set width and height attributes so the layout does not jump while it loads. Every image on this site is WebP at exactly two sizes, and the whole image payload of a page here is smaller than one unresized phone photo.

Most slow websites are one folder of unresized photographs wearing a trenchcoat.

Plugins that each seemed reasonable

A contact form. A slider. A popup for the newsletter. A social feed. A reviews widget. A cookie banner. A page builder. Each one was a sensible decision. Together they load fifteen stylesheets and twenty scripts on every page, including pages that use none of them.

The page builder is usually the worst offender, because it ships its entire framework on every page regardless of what that page contains. A text-only page on a heavily built site can be carrying several hundred kilobytes of CSS to render a paragraph.

Audit honestly. Most sites have three to five plugins that are actively used and several that were installed to solve a problem that no longer exists.

Third-party scripts, which are somebody else’s performance problem

Analytics, tag managers, chat widgets, retargeting pixels, heatmap recorders, review embeds. Each one fetches JavaScript from a server you do not control, and your page waits on it.

A chat widget is frequently the single heaviest thing on a small business site — heavier than all the content combined — and on many of them, nobody has looked at the transcripts in a year.

• Ask what each script is for and whether anyone reads its output
• Load the ones you keep with async or defer, at the end of the body
• Delay non-essential ones until the browser is idle rather than during page load
• Delete the rest, including the pixel from the campaign that ended in 2023

Hosting that was cheap for a reason

Shared hosting at a few dollars a month puts hundreds of sites on one machine. When a neighbour gets busy, you get slow. Server response time — the wait before the browser receives the first byte — is where this shows up, and no amount of image optimisation fixes it.

If your time to first byte is consistently above about 600 milliseconds and the site is not doing anything heavy, the hosting is the problem. This is one of the few cases where spending more genuinely solves it.

Fonts, redirects, and the small stuff

Four font families at three weights each is twelve files, each one blocking text from rendering. Two families, three weights, with display=swap so text shows immediately in a fallback, is almost always enough.

Redirect chains add a round trip each. A link to http://example.com/page/ that goes to HTTPS, then to www, then strips the slash, is three round trips before anything downloads. Point links at the final URL and make the server do one hop, not three.

How to measure it honestly

Test on a phone, on a mobile connection, not on the office fibre. PageSpeed Insights gives you both a lab test and — more usefully — field data from real Chrome users on your site, which is the only number that reflects your actual visitors.

1. Largest Contentful Paint — when the main thing appears. Target under 2.5 seconds.
2. Interaction to Next Paint — how fast it responds to a tap. Target under 200ms.
3. Cumulative Layout Shift — how much the page jumps while loading. Target under 0.1.

Speed is part of every website audit we run, and it is the item that most often turns out to be the reason a site with decent content is not getting calls.