Yes, speed matters for a local business website. Ten Grand Rapids contractor sites scored a median 59, and one script was costing ours 24 points.

Search "does website speed matter" and page one is agency posts that all say yes and none of which measured anything. So we measured something: the home pages of ten independent Grand Rapids contractors, on one morning, with the same tool Google gives away. Then, because it would be dishonest not to, we ran it on our own site. That second part turned out to be the most useful thing on this page.

What we measured, and how

Ten independent Grand Rapids contractor businesses, two each in roofing, plumbing, HVAC, electrical and landscaping, found by searching each trade on the day. The business's own home page in every case. They are named in our records, not here; the point is what a typical local trade site looks like on a phone, not which company to point at.

The tool was Google's Lighthouse, version 13.4.1, run on our own machine against the installed Chrome in headless mode, with Lighthouse's default mobile settings: a mid-range phone emulated, a simulated slow-4G connection, the processor throttled four times over, performance category only. Each site was measured once, between 12:18 and 12:22 UTC on 15 September 2026. One run each on the day.

Two caveats, stated plainly. First, we meant to use PageSpeed Insights, Google's public front end for the same audit, but its free daily quota had been used up before we got to it, so we ran Lighthouse locally instead. It is the same auditing engine PageSpeed Insights runs, but it ran here rather than on Google's servers, so the scores can differ by a few points from what PageSpeed Insights would show you today. Second, this is a lab test: a simulated phone on a simulated network. It says nothing about the real visitors each of these sites gets, which is the data Google's ranking systems actually use and which this method could not reach. Treat the numbers as a diagnosis, not a verdict, and treat any single Lighthouse score as roughly plus or minus a few points.

What ten Grand Rapids contractor sites scored

Ranked from fastest to slowest. "Mobile score" is Lighthouse's performance score out of 100. "Main content" is largest contentful paint, the moment the biggest thing on the first screen has appeared. "Weight" is everything the page downloaded, as Lighthouse reports it; we round it to megabytes in the text.

Rank	Mobile score	Main content shown	Weight
1	99	1.3 s	1,236 KiB
2	74	3.4 s	5,329 KiB
3	72	4.6 s	16,763 KiB
4	63	9.1 s	1,437 KiB
5	61	13.3 s	7,817 KiB
6	57	19.7 s	18,553 KiB
7	56	17.4 s	6,321 KiB
8	47	14.5 s	9,211 KiB
9	47	17.0 s	2,795 KiB
10	31	46.0 s	7,928 KiB

The median score is 59. Lighthouse colours 90 and above green, 50 to 89 orange and anything under 50 red, so that is one green site, six orange and three red. The main content took anywhere from 1.3 seconds to 46.0 seconds to appear; six of the ten took more than 13 seconds, and four took 17 seconds or longer. Page weights ran from about 1.2 MB to about 18.5 MB.

Two things in the table are worth more than the median. The first is the site at the top: a local trade site can be fast. It is a 1.2 MB page that painted its main content in 1.3 seconds on a throttled connection and scored 99. Nothing about being a roofer or an electrician condemns you to the orange band. The second is that weight and speed are not the same thing. The 1.4 MB page in fourth place took 9.1 seconds to show its main content; the 16.8 MB page in third took 4.6. What loads first matters more than what loads in total, which is the whole story of the next two sections.

What Google says speed is worth

Rather than tell you what Google thinks, here is what its own pages say, both read 15 September 2026.

On web.dev's Core Web Vitals page: "Optimizing for quality of user experience is key to the long-term success of any site on the web." The page defines the loading measure we used in the table: "Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading." And on how Google wants it measured: "a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices." That last line matters for reading our table honestly. Google's yardstick is real visitors, three-quarters of whom should see the main content inside 2.5 seconds. Our lab test is a single simulated visitor on a slow connection, which is harsher than most real phones on most days. Even so, six of ten local sites were over 13 seconds, five times Google's target, with room to spare.

On Google Search Central's page-experience documentation: "Google's core ranking systems look to reward content that provides a good page experience." And, without hedging: "Core Web Vitals are used by our ranking systems." But the same page is careful in both directions, and you should be too. "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." "There is no single signal." And: "getting good results in reports like Search Console's Core Web Vitals report or third-party tools doesn't guarantee that your pages will rank at the top of Google Search results; there's more to great page experience than Core Web Vitals scores alone."

So the honest reading is this. Speed is a ranking input, from Google's own mouth, but it sits behind relevance. A slow plumber's site will still outrank a fast one that is not about plumbing in Grand Rapids. Between two sites that are both plausibly the answer, though, the faster one is carrying a signal the slower one is not, and in local search the competition is usually exactly that: several plausible answers a few miles apart.

There is also the plainer reason, which needs no citation. Someone with water on the kitchen floor is holding a phone. We could not open the third-party studies on how many people give up as the seconds pass in time to check them for this page, so we are not going to quote them. You already know what you do with a page that is still blank after ten seconds.

What it looked like on our own site: 74 to 98 in a morning

We ran the same audit on our own pages in the same session, and the home page came back at 74, carrying 3.8 MB. Orange band, level with the second-best contractor site and 25 points behind the best. Not a good morning for a web shop.

It was worse than that, because 74 was the kindest of three readings. We had measured the same page twice earlier that morning while trying to get PageSpeed Insights to co-operate: 56 in a local Lighthouse run at 04:21 UTC, and 35 on PageSpeed Insights' own website at 07:18 UTC, the one Google-run result we managed to get that day. Same page, same 3.8 MB, three scores 39 points apart. That scatter was not noise in the tool. It was the widget: a 3 MB script arrives a little differently on every load, and the score swings with it.

The report made the cause obvious. Our booking calendar is a third-party widget from Calendly, and the way it was installed, it loaded roughly 3 MB of its own code the moment the page opened, for a calendar that sits near the bottom of the page and that most visitors never reach. Everything a visitor actually came for, the headline, the services, the phone number, was waiting behind a scheduling tool.

The fix was a few lines of code that leave the widget alone until the booking section is about to scroll into view, and only then fetch it. Nothing visible changed for the visitor except that the calendar now appears a moment after they scroll to it. We ran Lighthouse again the same morning.

Page	Mobile score	Main content shown	Weight
Home, before: Lighthouse, 04:21 UTC	56	19.4 s	3,777 KiB
Home, before: PageSpeed Insights, 07:18 UTC	35	12.8 s	3,762 KiB
Home, before: Lighthouse, 12:21 UTC	74	5.0 s	3,777 KiB
Home, after the fix: Lighthouse	98	2.0 s	721 KiB
Demonstration build: roofing	73	4.8 s	833 KiB
Demonstration build: restaurant	78	4.3 s	674 KiB
Demonstration build: salon	80	4.1 s	534 KiB

Seventy-four to 98 against the last reading before the fix; 35 to 98 against the worst. Call it 24 points, 3 MB and three seconds off the main content, from one script, in one morning, on a site that did not otherwise change. That is the most useful sentence on this page, because it is what the fix usually looks like: not a rebuild, one thing loading before it needs to.

The other three rows are the honest part we would rather not print. The demonstration builds, which are fictional businesses we made to show what a site could look like, not anyone's real company, score 73 to 80, with the main content taking 4.1 to 4.8 seconds to appear. That is nearly double Google's 2.5-second target and not as fast as pages we made from scratch should be. We opened all three to look. None of them carries a hero photo or a video, which is the usual suspect, so it is not that. Each one loads its display typeface from Google Fonts and its headline is the largest thing on the first screen, which is where we will look first, but we have not yet traced it. When we have, this page will say what it was and what it cost.

How to check yours in five minutes, and what it usually finds

Go to pagespeed.web.dev. It is PageSpeed Insights, Google's free tool, and it does not need an account. Enter your home page address and run it. Read the mobile result first, because that is where your visitors are and where the scores are worst. It runs the same Lighthouse audit we ran, on Google's machines rather than ours, and when Google has enough real-visitor data for your site it shows that too, which is the number Google's ranking systems care about.

Then read the list of things it found. From what the Lighthouse audits report on sites like the ten above, most of a bad score usually comes down to three things. Usually, not always; the report tells you which apply to you.

1. Third-party scripts loading up front. Chat widgets, booking embeds, review carousels, map embeds, tracking pixels, the fonts service. Each one is somebody else's code, loading on your visitor's phone before your own content, often for a feature halfway down the page. This was our 24 points. The fix is to load them later, or only when needed, or to remove the ones nobody uses.

2. Oversized images and video. A photo straight off a phone is often several thousand pixels wide and several megabytes; the space it fills on a mobile screen is a few hundred pixels. A background video in the header is the same problem multiplied. Several of the heaviest sites in our table are almost certainly this. The fix is resizing and compressing what is there, and not loading pictures below the first screen until the visitor scrolls toward them.

3. No caching or compression. The server sends every file at full size, every visit, with no instruction to the browser to keep a copy. This one is usually a setting at the host or a content delivery network, not a change to the site at all, and it is the cheapest of the three to fix.

Whoever built your site can do any of these. If nobody is maintaining it, that is the gap, not the score.

How to decide

Three questions, in order.

Is your mobile score under 50, or does your main content take more than twice Google's 2.5 seconds? If yes, it is worth an hour of a competent person's time this month. From what we see in the audits, that hour usually finds one script or one image, and either is a same-day fix. If your score is in the 70s or 80s and the main content is under three seconds, you have better things to spend money on, and anyone selling you a rebuild for speed alone should be asked to show you the report.

Do you know who is watching it? A score is a moment. The widget that costs you 24 points next spring will be the one your marketing person adds in March. If nobody checks, nobody knows. That is part of what a maintenance arrangement is for; our Care Plan is from $199 a month and includes managed hosting and security, monthly edits, and uptime and performance monitoring, which means the number is looked at, not assumed. Whoever you use, ask whether performance is on their monthly list.

Is speed the only thing wrong? Be honest. If the site is also thin, hard to find on Google, or not producing calls, a speed fix polishes a page that is not doing its job. Our Site & Business Audit is $750 one-off: a written report in 3 business days, 190+ checks on every page including speed, indexing, security, schema, local pack and conversion. It will tell you whether you have a one-script problem or a whole-site one, and only in the second case should a rebuild be on the table. When it is, our sites start at $999 for a Starter build, 1 to 3 pages, mobile-first, with a lead form, click-to-call, on-page SEO and Google setup, live in days. Rebuild because the audit says so, not because a score did.

---

Common questions