Six Government Sites: 7.27s in the Lab, 1.24s for Real Visitors. Our Own Site Has No Real Data at All.

A licensed plumber in Bristol, Rhode Island carries more government than almost anybody else on the street. A state trade licence that has to be renewed. A registration with the Secretary of State. Sales and use tax. Permits pulled at the town counter for work a homeowner will never see behind a wall. If you want to bid on public jobs, a federal registration on top of all of it. Every one of those obligations now has a website attached, and every one of those websites has to load on a phone, in a truck, in a cellar, between jobs.

That is a lot of somebody else's software to depend on. So we measured it. But first we measured our own, because it is not fair to grade Rhode Island's homework without showing ours.

Part one: the teardown of our own site#

We have now measured avalonpartner.com three times and published every result, including the ones that made us look bad. Same method each time: the PageSpeed Insights API, mobile strategy. In July we ran each page once. Since 8 August we run each page four times and take the median, because a single lab run is noisier than we originally treated it as being.

The number we stand behind hardest is the least glamorous one in that table: page weight. It is not a simulation or a score, it is a byte count, and the blog index put on 70 KiB in fifteen days. It is now 870 KiB. The lab estimates alongside it moved in the same direction — a second and a tenth slower, ten and a half Lighthouse points down — and we will treat those as directional rather than precise, for reasons Part Two makes embarrassingly clear.

Nobody decided to make that page heavy. We publish an article most days and the index carries every one of them. It got heavy the way a garage gets full, one honest addition at a time, and nothing in our process was watching the total. That is the whole failure mode. It is not incompetence, it is the absence of a number on a wall.

Part two: the same test, pointed at the government#

Then we took the identical tool and pointed it at six state, federal and municipal websites in a Bristol plumber's orbit. Two runs each on 23 August 2026, mobile, same API. The last row is us, for scale.

In the lab these look bad. RI Commerce ships 3,290 KiB to a phone. SAM.gov blocks the main thread for eight and a half seconds on a simulated mid-range Android. Five of the six have a lab LCP over Google's 4.0-second "poor" line.

Then look at the fourth column. Five of the six are rated Fast by Google's Chrome User Experience Report — twenty-eight days of measurements from actual Chrome visitors on actual phones and actual connections. Across all six, the median lab estimate is 7.27 seconds and the median real-visitor figure is 1.24 seconds. On these six sites, today, the simulator was pessimistic by a factor of 5.86.

As a general rule, if you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts. Since field data represents what real users are experiencing, it's the most accurate way to really understand what your users are struggling with and what needs to be improved.

Two honest qualifications before anyone quotes that 5.86 at a client. It is a property of these six particular origins, not a correction factor you can carry to another website — high-traffic government sites draw a visitor population skewed toward fast US connections. And "rated Fast" is a statement about the 75th percentile. One visitor in four is slower than the number in that column, with a tail nobody publishes. RI Commerce's 3.29 MiB is still costing somebody data and battery. What the field data disproves is the claim that these sites are unusable. It does not prove the bloat is free.

The government sites have field data for one boring reason: enough people use them. Google only publishes real-visitor data for pages and origins above a traffic threshold it does not disclose, and says so plainly in the CrUX methodology. Tax deadlines, licence renewals and permit lookups generate that traffic without anybody trying.

Does Part One survive Part Two?#

Fair question, and the honest answer is: partly.

If a lab estimate can be pessimistic by a factor of six, then our blog index moving from 4.05s to 5.15s is not proof that a single real human waited a second longer. It is not nothing either — it is the same harness, on the same page, run the same way, fifteen days apart, and the direction is consistent. But it is a signal, not a verdict, and we should have said so the first two times as well.

The 70 kilobytes are different. That is not an estimate. Those bytes exist, they cross somebody's network, and they are billed to somebody's data plan. That is the finding from Part One that we will act on.

Part three: what this means for a plumber in Bristol#

Now look at the last row of the table again. Our site has no field data. None. We do not have enough traffic to qualify, so every speed number we have ever published about ourselves is a simulation.

Your plumbing company's website is almost certainly in the same position. That has two consequences and they pull in opposite directions.

The first is comforting. If somebody has waved a red performance score at you — one of the businesses in our July Fall River survey scored 33 — that number is a simulation of a hypothetical visitor on a throttled mid-tier Android. It is a diagnostic. It is not a report card, and it is not evidence that your customers are suffering.

The second is not comforting at all. You cannot prove they are not, either. The Town of Bristol can point at 2.58 seconds of real evidence, and even that is only rated Average. You cannot point at anything. When you cannot measure the outcome, the responsible move is to fix the things that are broken whether the page loads in one second or ten.

We could not measure Bristol's plumbers directly today — more on why below. The nearest measured plumber data we hold is Fall River, from 13 July 2026: sixteen businesses holding 2,991 Google reviews between them at a 4.89 average, none below 4.3. Of the twelve whose speed we could measure, the median mobile LCP was 9.4 seconds, and only two of those twelve were field measurements rather than lab estimates — so treat that 9.4 with exactly the scepticism this article has been arguing for. What does not need any scepticism: five of thirteen live sites had a phone number you could not tap, and nine of thirteen had no contact form at all. Those findings do not depend on a stopwatch, and that is the point.

The free fix, and it takes ten minutes#

Open pagespeed.web.dev on your phone and enter your homepage. No account, no cost.

Now ignore the big coloured score. Look only at the panel at the very top, the one labelled with real-visitor data. One of two things will happen.

If it shows numbers, that is the truth about your website, and it is the only figure worth arguing about. Use it.

If it says there is not enough real-world data, you have learned something more useful: nobody can judge your site's speed, including whoever is trying to sell you a speed fix. Stop optimising for the simulator. Spend the same ten minutes making sure your phone number is a tappable link, that your homepage says "Bristol, RI" in the first sentence, and that your state licence number appears in plain text where a nervous homeowner can find it before they call. Those are free, they take minutes, and no lab score has any opinion about them.

What we could not measure, plainly#

Bristol's plumbers. Our own audit engine failed today. The Google Places API returned 403 PERMISSION_DENIED on every request, so business discovery never ran and we audited no Bristol plumbing company's website for this piece. That is our tooling breaking, not a finding about Bristol.

The seventh site. business.ri.gov — the Secretary of State's business portal, which is a genuine obligation for a plumbing company — returned no HTTP response at all from our environment. Our tooling records exit code 000, which does not distinguish a DNS failure from a refused connection, so we cannot tell you which happened and we are not going to guess. Unmeasured, not an outage.

The independence of our "runs." This one is uncomfortable. Four of the six government sites returned byte-identical results across both runs — same score, same LCP, same layout shift, same page weight. Three of our four homepage runs were identical too. That is the signature of PageSpeed serving a cached Lighthouse result rather than running a fresh one. So "median of two runs" is, for those sites, closer to one run reported twice. The places where we saw genuine variance — the Town of Bristol at 55 then 34, our article page at 80 then 94 — are the runs that were not cached. We are reporting the medians anyway because they are what we have, and flagging this because an article about not trusting a single lab number should not quietly rest on single lab numbers.

Everything about our own site is a lab estimate. Accessibility, SEO and best practices came back 100 on all three of our pages across all twelve runs, and cumulative layout shift was exactly 0 every time. The only opportunity Lighthouse names is still unused JavaScript: 115 KB on the homepage, 101 to 102 KB on the blog index, 108 KB on an article page. The homepage and blog index figures are unchanged since July and remain unaddressed. We have no July figure for an article page to compare against.

We publish our own bad numbers, and our own broken tooling, because a company that will not show you its own measurements has not earned the right to show you yours. The blog index is on the list. We will tell you what it does next, whichever direction it goes.

If you run a plumbing shop in Bristol and you want somebody to look at what the state, the town and Google are actually saying about you — no charge for the look — call 774.559.8992 or email Joshua.Amado@AvalonPartner.com.

Method. All 23 August figures measured via the Google PageSpeed Insights API, mobile strategy, on 23 August 2026. Avalon pages: median of four runs. Government sites: median of two runs, with the caching caveat above. "Real visitors" is Google's Chrome User Experience Report, the 75th percentile over a trailing 28-day window. Thresholds are Google's, not ours: LCP under 2.5s is good, over 4.0s is poor. Every 23 August figure in this article can be reproduced by pasting the same URLs into pagespeed.web.dev, though the CrUX window will have moved by the time you do. The July and August rows for our own site are historical and are no longer reproducible. The Fall River plumber aggregates come from our 13 July 2026 brief; the businesses are anonymised and their URLs are not published.