Page Speed for Small Business Websites

Almost every slow local website is slow for the same three reasons.

What Slow Costs You

Speed affects two things. It affects whether visitors stay, and it affects rankings, though not equally.

The ranking effect is real but modest. Google uses page experience as one input among many, and a fast page will not outrank a better answer. Anyone selling you a rankings turnaround based purely on speed is overselling it.

The visitor effect is much larger and less debated. Abandonment climbs sharply between one and four seconds, and it climbs fastest on mobile, which is where most local searches happen. A three second improvement on a page that gets a hundred visits a week is worth more to you than any keyword you are chasing.

Core Web Vitals Without The Jargon

Google measures three things and gives them acronyms that hide what they mean.

Largest Contentful Paint is how long until the main thing on screen appears. Usually your hero image or headline. Target under 2.5 seconds. This is the one most local sites fail, and images are almost always the cause.

Interaction to Next Paint is how quickly the page responds when someone taps something. Target under 200 milliseconds. Failures here come from too much JavaScript running, which on a local site usually means tracking scripts and chat widgets.

Cumulative Layout Shift is how much the page moves around while loading. Target under 0.1. Failures come from images and embeds without reserved space, and from fonts that swap in late.

You can see all three for your own site in Google Search Console under Page Experience, measured on real visitors rather than a lab test. That report is more useful than any score out of a hundred because it reflects the phones and connections your actual customers have.

Cause One: The Images

This is the majority of it. Someone uploads a photo of the shopfront straight from a phone camera at 4000 pixels wide and several megabytes, and the browser downloads all of it to display something 800 pixels wide.

Three fixes, in order of impact. Resize every image to roughly the largest size it is displayed at. Convert to WebP, which typically saves a further quarter to a third at the same visual quality. Add lazy loading so anything below the fold does not compete with the first view.

Do this to your homepage hero first. On most local sites that single image is the largest contentful paint, so fixing it moves the headline number more than everything else combined.

Cause Two: Scripts You Forgot About

Over a few years a site accumulates tags. Two analytics tools, a heatmap trial nobody cancelled, a chat widget, a review carousel, a social feed, three ad pixels from campaigns that ended.

Each one is a separate download and some of them block rendering. The review widget in particular is a common offender, because pulling live reviews from a third party can add a second or more before anything renders.

Audit what is loading. In Chrome DevTools open the Network tab, reload, and sort by size and by time. Anything you cannot justify by name comes off. For anything you keep but do not need immediately, such as chat, load it after the page is interactive rather than with it.

For review widgets specifically, consider rendering the reviews as text on the page rather than pulling them live. It is faster, and unlike a widget it is content search engines and AI systems can read, which is worth more than the star graphic.

Cause Three: Hosting And Caching

The cheapest shared hosting plans oversubscribe their servers. Your site is competing for resources with hundreds of others, and the first byte can take most of a second before anything else has begun.

Check your time to first byte. Under 200 milliseconds is good, over 600 is a hosting problem no amount of image compression will fix.

Two changes fix most of it. Put a CDN in front of the site so static files are served from somewhere near the visitor. Turn on page caching so the server is not rebuilding the same page for every visitor.

If you are on a platform where you cannot do either, that is a reason to move, and it is usually cheaper than the SEO work people do instead.

Measuring It Properly

Do not judge speed from your own machine. You have the site cached, you are on a good connection, and you are probably on a desktop.

Use PageSpeed Insights for a lab test and to get specific recommendations, but weight the field data section higher, because that is real visitors. Use the Search Console Core Web Vitals report for a view over time and by page group. And test at least one real phone on mobile data.

Ignore the temptation to chase a perfect score. Going from a two second load to a 1.6 second load will not change your business. Going from six seconds to two will.

Why It Slows Down Again

The frustrating part of speed work is that it does not stay fixed. Someone uploads an uncompressed image to a new blog post. A plugin update adds a script. A new campaign adds a pixel. Six months later you are back where you started and nobody noticed, because the decline was gradual.

That drift is the reason askotter treats a site as something that is monitored rather than something that is finished. The site watches its own performance, and when a page gets slower or a vital fails, that becomes a flagged change with the cause identified and a fix proposed for someone to approve.

A site does not need to be rebuilt every three years if it is being corrected every month. Self serve starts at $99/mo, managed is $600/mo, and the monitoring platform is included with both.