We measured 139 small business websites pulled from US local search results. The median took 8.9 seconds to render its main content on a phone — Google calls 2.5 seconds "good". Four sites out of 138 met that bar. The median page weighed 3.5 MB, of which 1.2 MB was JavaScript. Every domain and score is in the dataset below.
How we picked the sites
Not a curated list, and not our own clients: we wanted the sites a customer actually finds. Twelve local service queries across twelve US cities — plumber in Austin, dentist in Scottsdale, hair salon in Las Vegas and so on — top twenty organic results each. From those we kept only the businesses' own websites, dropping directories, marketplaces, review sites and news; national chains were kept but flagged separately in the data.
That produced 160 unique domains. 21 did not open to our crawler — most were behind bot protection, which is a finding of its own and not a speed result. The remaining 139 were identified by platform from their page source and measured with one Lighthouse mobile audit each through the PageSpeed Insights API on 20 August 2026. One site returned no paint at all and is excluded from the statistics, leaving 138.
What we found
| Measure | Median | Worst | Best |
|---|---|---|---|
| Largest Contentful Paint | 8.9 s | 64.4 s | 0.8 s |
| Lighthouse performance | 57 | 19 | 99 |
| Page weight | 3.5 MB | 28.1 MB | — |
| JavaScript shipped | 1189 KB | 6369 KB | — |
Three numbers are worth stating on their own. 4 sites (3%) met the 2.5-second threshold. 6 (4%) scored 90 or above. And 34 (25%) scored below 50 — the range Lighthouse paints red, where a visitor on a mid-range phone is waiting long enough to reconsider.
By platform — and why we are not naming a winner
| Platform | Sites | Median score | Median LCP | Median weight | Median JS |
|---|---|---|---|---|---|
| WordPress | 65 | 57 | 8.3 s | 3.5 MB | 1189 KB |
| Not identified | 41 | 63 | 8.8 s | 3.5 MB | 810 KB |
| Squarespace | 19 | 50 | 17.8 s | 3.8 MB | 1902 KB |
| Wix | 6 | 72 | 6.2 s | 2.4 MB | 1094 KB |
| Duda | 4 | 66 | 6.2 s | 3.4 MB | 808 KB |
| Webflow | 2 | 58 | 5.8 s | 3.8 MB | 2059 KB |
Only the first two rows carry enough sites to mean much. Wix, Duda and Webflow had six sites or fewer each — we publish those rows for completeness, not as a comparison, and neither should anyone quoting this. "Not identified" means our detection found no platform signature: mostly hand-built or headless sites, sometimes a CMS we did not test for.
What the numbers do not show is a platform that makes sites fast. Slow sites appear on every row, including rows where the platform does most of the work for you. That points away from the logo on the login screen and toward how the site was assembled — which matches what the weight column says.
Where the seconds go
A median of 1189 KB of JavaScript on a brochure site is the finding that explains the rest. Almost none of it exists because a visitor asked for something: it is a theme, a page builder, a chat widget, three tracking scripts, a booking embed, a slider and a font loader — each added by someone solving one problem, none of them looking at the total. The heaviest page we measured shipped 28.1 MB.
None of that is a moral failing, and none of it is fixed by switching platforms. It is what happens when nobody owns the budget for the page as a whole. The diagnosis, per symptom, is in why is my website slow.
For contrast: sites built to a budget
Ours are in the same measurement world, on the same scale — published per project with the scorecard, measured 2026-08-11:
- GebaShop (e-commerce) — 100 desktop, 99 mobile
- SG Training Fit (e-commerce) — 100 desktop, 90 mobile
- MB Beauty (beauty & pmu) — 100 desktop, 90 mobile
We are not claiming the median site could hit those numbers with a plugin. We are pointing at the mechanism: those pages ship almost no JavaScript because nothing was added that a visitor did not need. That is a decision made once, at the start, and it is why our builds are static-first.
What to do with this if it is your site
- Measure it. PageSpeed Insights, free, two minutes, mobile tab first. A score is not the goal, but it tells you which half of this study you are in.
- Subtract before you rebuild. Unused plugins and apps, the chat widget nobody answers, the slider nobody scrolls, tracking scripts from a campaign that ended. Most of the median 3.5 MB is removable without touching the design.
- Right-size the images. The single biggest win on most of the sites we measured, and it changes nothing visually.
- Then decide about rebuilding. If every tweak claws back a little and the ceiling is still low, patching has a limit — a performance rescue from $1,900 keeps the design and replaces only the slow front end. If the design is the problem too, that is a redesign, and it costs differently.
The data, and how to check us
The full dataset is public: every domain, its detected platform, the query it was found through, and all measured values — download the CSV. Anyone can re-run any row through PageSpeed Insights and compare.
Limits, stated plainly. These are lab measurements — one Lighthouse run per site, so individual scores carry run-to-run variance and should not be used to rank two specific sites; the population-level medians are what this study supports. The sample is twelve service categories in twelve US cities, not a random sample of all small businesses. Platform detection reads page signatures and can miss a migrated or headless setup, which is why "not identified" is its own row rather than being guessed at. Field data would be a better lens, but only 24 of these domains had enough traffic to appear in Chrome's field dataset at all — itself a fact about how small these businesses are.
Questions about the method, or want the numbers behind a specific row? Ask by email — we will answer in writing.