Single-Run Lab Audits of 96 Local Business Sites: What the Numbers Actually Say

In March 2026 I ran a PageSpeed Insights API audit on 96 Ottawa-area service business websites: plumbers, electricians, HVAC companies, cleaners, contractors. I re-ran the same panel on November 3, 2026. This post covers what I measured, how, what I found, and where the method falls short.

What I measured

I built the list from Ottawa-area business directory listings across 16 localities, covering home and trade service categories. Directory sourcing means the panel represents businesses that list publicly - it is not a census of every business in the city. I audited 97 sites on March 18, 2026, then excluded my own agency's site from every statistic, so all figures are computed on the remaining 96.

Each site got one PageSpeed Insights API v5 lab run, mobile and desktop, using standard Lighthouse mobile emulation. Published results are aggregate-only and do not include business names or site URLs.

What I found in March

The headline number: median mobile PageSpeed score of 65.5 out of 100. Half the panel sits below that, half above.

The distribution is what I found more interesting than the median:

Most sites scored in Lighthouse's 50-89 "needs improvement" band. Ten reached the 90-100 "good" band, and nineteen fell below 50 into the "poor" band. These are lab performance classifications, not direct measurements of customer experience.

Desktop median performance was 86, compared with 65.5 on mobile - a 20.5-point difference under the respective lab test conditions. This audit did not measure the businesses' actual visitor device mix.

Four specific defects showed up again and again:

1. Unused JavaScript and CSS. 66 of 96 sites (68.8%) had JavaScript or CSS flagged as unused during the audited page load. Among flagged sites, the estimated time cost was a median of roughly 460ms for JavaScript and 440ms for CSS. Code unused during a Lighthouse run may still support later interactions, so these are investigation leads, not confirmed waste.
2. Redirect chains. 47 of 96 sites (49%) were flagged for avoidable redirect hops, median estimated cost around 780ms per flagged site. These are Lighthouse heuristic flags with estimated savings, not measured page-load measurements.
3. Largest Contentful Paint. 72 of the 96 sites with a measurable value took longer than 4 seconds to paint their largest element - the threshold Google labels "poor" for LCP (the "good" threshold is 2.5s, "needs improvement" runs to 4.0s). The median was 6.3 seconds.
4. Layout stability was the exception. Median Cumulative Layout Shift of 0.004, with only 3 of 96 sites exceeding Google's 0.1 CLS threshold (the "poor" threshold is 0.25). Layout shifts during these lab runs were generally low; this does not establish layout stability throughout real user sessions.

The Q4 re-measure

On November 3, 2026 I re-ran the same panel. 88 of the 96 cohort sites produced a measurable mobile score. Of the 8 that did not: five domains no longer resolve at all (a 5.2% mortality rate in about seven and a half months), one failed measurement outright, and two more return HTTP errors at their bare root and did not yield a mobile score (five other root-error sites did measure fine once their redirects were followed). Among the 88 sites measured in November, the median mobile score was 71.0, compared with 65.5 across the 96 measured in March. On the paired subset of 88 sites measurable in both editions, the 90+ share rose from 9.1% to 26.1%, and the under-50 share fell from 20.5% to 15.9%.

These summaries use different denominators and single-run measurements, so they do not establish how much individual sites improved or whether owners made changes.

Honest limitations

I want to be direct about what this data can and cannot claim, because benchmark posts usually are not.

These are single-run lab measurements. One Lighthouse run per site, on one day. Run-to-run variance of a few points is normal for PageSpeed, so treat every exact value as indicative, not gospel. A 65.5 median is a solid cohort signal; a claim that any individual site scores exactly 63 rather than 67 is not supportable from this method. Medians and distributions over 96 sites absorb that noise far better than single scores do.

Lab is not field. These LCP figures describe this lab audit only. Google's field Core Web Vitals data - measured on real visitor devices, on real networks, weighted by actual traffic - can differ, sometimes a lot. A lab run tells you what a synthetic Moto-class device on a throttled connection experienced once. It is excellent for finding defects (unused code, redirect chains) and weaker for claiming what your customers experienced last Tuesday.

Heuristics, not byte counts. "Unused code" and "redirect" findings are Lighthouse heuristic flags with estimated time savings, not measured bytes. The estimates are useful for ranking fixes; they are not invoices.

Scope. Directory-sourced panel, one city, one vertical cluster, aggregate-only reporting. I am not ranking or naming anyone - a slow score on a single-run audit is a lead, not a verdict.

Why I published the method alongside the numbers

If you are benchmarking a local market, the numbers are only useful if the reader can reproduce or at least question the method. Every figure here traces to one PSI v5 lab run per site on a stated date. The full dataset, distribution tables, edition history, and citation formats live on the study's canonical page: peakspire.ca/ottawa-website-benchmarks. This post carries a canonical URL pointing there so search engines treat the study page as the source of record.

If you take one thing from this: if your site scores in the 50s or 60s on mobile, you are near the local median, not an outlier. The recurring diagnostics offer starting points for investigation, not a guaranteed score improvement or a conclusion about whether a rebuild is needed.