Website Speed and SEO:
What Small Businesses Should Know

Speed is one of the few parts of SEO that Google measures with a number, tells you the number, and tells you the threshold. There is no guessing. Your site either loads fast enough on a phone or it does not, and if it does not, you are paying for it twice: once in rankings, and again in every visitor who taps back before the page finishes drawing.

This post explains what Google is measuring without the jargon, how to test your own site in two minutes, what usually makes a small business website slow, what to fix first, and how to tell when patching is a waste of money.

Why speed matters for a local business

Google has used page speed as a ranking signal since 2010 and mobile speed since 2018. Since 2021 it has used a specific set of measurements called Core Web Vitals. Speed is not the biggest ranking factor; relevance and reputation still matter more. But among businesses with similar pages and similar reviews, the faster site tends to win the tie, and local search is full of ties.

The bigger cost is conversion. Your customers are searching from a phone, often on a weak signal, often with an urgent problem. A page that takes six seconds to show them a phone number loses a real share of them to the next listing. That loss never shows up in a report, which is why it gets ignored.

Core Web Vitals in plain English

There are three measurements. Google grades each one as good, needs improvement, or poor, based on what real visitors to your site experience over the previous month.

LCP: how long until the main thing appears

Largest Contentful Paint is the time from tapping the link to the biggest element on the screen, usually the hero image or headline, being visible. Google wants it under 2.5 seconds. Over 4 seconds is poor. This is the one most small business sites fail, and the culprit is almost always a big image at the top of the page.

INP: how quickly the page reacts when you tap something

Interaction to Next Paint measures the delay between tapping a button or menu and the screen responding. Under 200 milliseconds is good; over 500 is poor. When a site feels sluggish, where the menu takes a beat to open, that is INP. It is caused by too much JavaScript running in the background: chat widgets, tracking scripts, sliders, page-builder code.

CLS: whether things jump around while loading

Cumulative Layout Shift is the annoying thing where you go to tap "Call Now" and an image loads above it, shoving the button down so you tap an ad instead. Google scores this from 0 upward; under 0.1 is good. It comes from images without set dimensions, fonts swapping in late, and banners or cookie bars that push content down after it has drawn.

How to test your site

Go to PageSpeed Insights at pagespeed.web.dev, paste in your homepage address, and wait about thirty seconds. Make sure the Mobile tab is selected; that is what Google ranks on, and it is always the worse score.

The top section, if it appears, is real-visitor data for the three vitals above. That is the part Google actually uses. Below it is a lab test with a score out of 100 and a list of suggestions. The score is a useful guide but not the ranking factor; the three vitals are.

Then test your busiest service page, not just the homepage. Homepages often get attention and inner pages get neglected. If you have Google Search Console set up, its Core Web Vitals report will list every page on the site that is failing, which saves testing them one at a time.

The usual culprits

• Huge images. A photo straight off a phone is 3 to 5 megabytes and 4,000 pixels wide, displayed in a box 800 pixels wide. Ten of those on a page is 40 megabytes. This is the number one cause of a bad LCP and the easiest to fix.
• Page builders. Visual builders load their whole toolkit on every page whether the page uses it or not. A simple "About" page can carry a megabyte of styles and scripts for sliders and animations it does not contain.
• Too many plugins and third-party scripts. Each plugin adds its own files. Each chat widget, review badge, social feed, and tracking pixel adds a request to another company's server. Twenty of them and INP falls apart. We regularly find sites running plugins nobody remembers installing.
• Cheap shared hosting. The lowest-tier hosting plan puts your site on a server with hundreds of others. When the server is busy, your page waits before it even starts sending. PageSpeed calls this "server response time." If it is over 600 milliseconds, hosting is part of the problem.
• No caching or compression. Without caching, the server rebuilds the page from scratch for every visitor. Without compression, files are sent at several times their necessary size. Both are switches that were never flipped.
• Web fonts and embeds. Five font weights from a font service, an embedded map, and a YouTube video on the homepage each add a chunk of load time before the page settles.

Fixes, in the order we do them

Images first. Resize every image to the size it is actually displayed at, convert to WebP, and compress. Set width and height on every image tag so the browser reserves the space (that alone fixes most CLS). Lazy-load anything below the first screen. This one step often takes a site from poor to needs-improvement on LCP.

Then subtract. Remove every plugin, widget, and script you cannot name a reason for. Replace the embedded map with a static image that links to Google Maps. Load the chat widget only after the visitor scrolls. Cut font weights to two.

Then the server. Turn on caching and compression, and put the site behind a content delivery network so files are served from somewhere near the visitor. If server response time is still slow, move to better hosting; the difference in cost is small compared with what a slow site costs you.

Then re-test and keep testing. Speed drifts. Someone adds a plugin, uploads a 6 MB photo, or the host gets slower. A monthly speed check is one of the standing items in our Website + SEO Care Plan because we have watched sites we tuned drift back within a year when nobody was looking.

When to rebuild instead

Sometimes you do all of the above and the mobile score moves from 28 to 45. That is the sign the problem is structural: the theme or builder itself is the weight, and no amount of trimming removes it. At that point more optimization is money spent making a slow thing slightly less slow.

Other signs it is time: the site is more than five or six years old; it is on a builder or theme that is no longer updated; you have to fight it to make any change; or the mobile layout was never right to begin with. Our post on when to migrate from WordPress to a custom site goes deeper on that decision.

A site built by hand for a local business, with no builder and no plugin stack, is typically a fraction of the size and passes all three vitals on the first test. That is how we build websites and web apps: plain, fast pages that do the one job of getting the phone to ring, and that stay fast because there is nothing underneath them to rot. Whether you patch or rebuild, start by running the test. The number tells you where you stand, and a quick look at the other signs tells you whether speed is your only problem.