Website Speed for Small Businesses: What We Measured and Fixed

Most people who find your business online are holding a phone, often on a patchy connection. Google measures how your website feels to them and uses that as one of the signals in search. Slow sites also lose people before they ever see your phone number.

We build websites for a living, so we ran the numbers on our own. This post explains what Google measures, what usually slows a small business site down, and what we found on ours, including the parts that aren't flattering.

The Three Numbers Google Watches

Google calls them Core Web Vitals. There are three:

• Largest Contentful Paint (LCP): how long until the main content (usually the headline or hero image) appears. Good is 2.5 seconds or less.
• Interaction to Next Paint (INP): how quickly the page responds when someone taps a button or opens a menu. Good is 200 milliseconds or less.
• Cumulative Layout Shift (CLS): how much the page jumps around while it loads, like a button moving just as you tap it. Good is 0.1 or less.

Google judges these at the 75th percentile of real visits. In plain terms, three out of four visitors should get a "good" experience.

What Usually Slows a Small Business Site Down

The same few causes show up again and again:

• Stylesheets that block the page. The browser won't draw anything until it has downloaded every stylesheet it was told about. A site built from many plugins or theme add-ons can ask for a dozen.
• Heavy scripts loaded up front. Contact forms, chat widgets, booking tools and sliders often load all their code on every page, before the visitor needs any of it.
• Oversized images. A 4,000-pixel photo straight from a camera, shown in a 400-pixel box on a phone.
• Third-party scripts. Every tracking pixel, review widget and embedded map is code from someone else's server that your visitors have to wait for.
• Fonts fetched from other servers. Each extra server the browser has to contact adds a delay, and a font that arrives late can make text appear late or jump.

None of these is exotic, and most can be fixed without rebuilding the site.

What We Fixed on Our Own Site

In early October we tackled two of those causes on our homepage:

1. Inlined our stylesheets. Instead of making the browser fetch 13 separate stylesheet files before drawing anything, the styles now arrive inside the page itself.
2. Deferred the contact form's code. The form's validation libraries now load only when the form is about to scroll into view, or when the browser is idle. A placeholder of the same height holds the space, so nothing jumps when the real form appears.

Here's what changed, measured with Lighthouse's mobile simulation on our homepage on October 9, 2026:

Around the same time, we also started hosting our fonts ourselves instead of loading them from Google Fonts. We did that because the outside font service was breaking our production builds, not to chase a score, but it has a side benefit: one less server for every visitor's browser to contact.

Where We Are Today

Since then we've extended our 3D redesign from the homepage to our service, city and blog pages. On October 12, 2026 we measured again, with the same kind of Lighthouse mobile test against the live site (three runs per page; the middle result shown):

That's worse than before, and well above Google's 2.5-second line. The two tests weren't run in exactly the same setup, so treat the comparison as a direction rather than a precise measurement, but the direction is clear. Accessibility and SEO both scored 100 on every page, but speed slipped. One of our three homepage runs, on a cold cache, also showed a layout shift of 0.361, far above the 0.1 limit.

We know where to start looking. The pages aren't slow to download: the server answers in about a quarter of a second and nothing blocks the browser from starting. Something in the newer pages is holding back the first paint, and tracking that down is our next job.

The lesson is the one we'd give any client: speed isn't a one-time fix. Every new feature, plugin or widget can undo earlier work, so measure again after every significant change.

How we built a 3D site without hurting accessibility or SEO, and what it has cost in speed so far: our redesign, measured →

Lab Numbers vs Real Visitors

Everything above is lab data: a test that simulates a mid-range phone on a slow mobile connection. It's repeatable, which makes it good for comparing before and after.

Google's search signal uses field data: real measurements from Chrome users who visit your site, collected over 28 days. Small sites often don't have enough visitors to get field data at all. That's normal, and the lab test is still the best guide you have.

Check Your Own Site

1. Go to Google's PageSpeed Insights (pagespeed.web.dev) and enter your homepage address.
2. Stay on the Mobile tab. That's where most small business sites struggle.
3. Look at LCP, INP and CLS at the top. If you see "No data", you don't have field data yet; scroll down to the lab results.
4. Open the Diagnose performance issues section. The top few items are usually the ones worth fixing first.
5. Run it again after any change, and keep a note of the numbers.

Get a free website speed and conversion audit →

Running Shopify? Mention it in the audit form and I'll include theme and app checks with Store Speed Doctor.

Related service: Custom Web Development in Surrey →