The 96.9% Problem

We scanned 292 B2B small-business websites in April 2026.

Of those, 191 returned a valid mobile verdict. 185 of them failed at least one threshold. Six passed all three.

That is the 96.9 percent. Here is what it does and does not mean, because the number has been quoted more carefully than it was originally written.

What we actually measured

One mobile Lighthouse run per site, checking LCP, FCP, and CLS.

The median mobile LCP across the valid tests was 10.5 seconds. That is the number that should have led this article from the beginning. Not a percentage of a threshold, but how long the largest thing on the page actually took to appear on a phone.

What the number is not

This is where the original version of this post overstated its own research, so we are fixing it in place rather than quietly editing it.

These are Lighthouse lab measurements, not Google's Core Web Vitals. Google's current Core Web Vitals are LCP, INP, and CLS, collected from real users in the field. We measured FCP, which is not a Core Web Vital, and we never measured INP at all. We collected no field data.

So the honest claim is: *96.9 percent of the sites that returned a valid mobile lab test failed at least one of the thresholds we configured.* It is not "96.9 percent of small business websites fail Google's Core Web Vitals."

The sample was not random. The 292 domains came from an existing B2B prospect list in our sales pipeline. We did not go looking for bad websites, which rules out one kind of bias, but it is still a purposive sample of sales-visible US B2B companies. It is a snapshot of that group, not a census of the small-business web.

So there is no "97 percent chance your site fails." We have seen that framing quoted back to us, and it is not supported. We did not randomly sample the web, and we never recorded whether any of these businesses had audited their site before.

Poor LCP was the headline finding. The cause is not in this dataset.

165 of 191 valid tests produced a mobile LCP over four seconds, with a median of 10.5 seconds. That is a real, serious result.

But an earlier version of this article told you *why*: oversized hero images, three blocking tracking scripts, fonts hiding text for three seconds. We did not measure any of that. The published dataset has 41 columns and none of them record hero-image bytes, script counts, or font-display values. Those were plausible guesses dressed as findings, and they should not have been in a research post.

LCP is a composite. The delay can come from server response time, late discovery of the resource, the download itself, render-blocking CSS or JavaScript, client-side rendering, or a render delay after the asset has already arrived. Compressing a hero image is sometimes right. It is not the diagnosis for every page, and "defer your scripts" is not a one-word repair for a tag stack that a consent tool depends on.

The correct first step is boring: find the actual LCP element on your page, then work out which part of its loading path consumed the time.

Every evaluated site failed the link-name check

All 191 sites where the accessibility check ran had at least one link that failed axe-core's accessible-name rule.

That means the link's purpose was not available programmatically. It usually announces as something useless, or as a raw URL, to anyone using a screen reader.

Icon-only social links in footers were a recurring example in our manual review, but we did not classify every failure by cause, so we are not going to tell you it was "usually" the footer. And an aria-label is one fix, not the only one. Visible text, visually hidden text, aria-labelledby, or a proper alt on a linked image can all supply the name.

One more limit: axe-core is an automated tool. It finds specific, real problems. It cannot certify a site as accessible, and it does not replace tabbing through the page yourself.

What we did not measure

No rankings. No impressions or clicks. No leads, conversions, or revenue. No real-user performance data. And we never asked a single owner what they knew about their own site.

So we cannot tell you these failures cost anyone a customer. We can tell you the failures are there, and that they are nearly universal in this sample. Whether a specific one is costing *you* anything requires Search Console, field data, analytics, and a before-and-after.

We also cannot tell you these were struggling businesses or thriving ones. Appearing in a B2B prospect database means a company was visible enough to be sold to. It does not establish revenue, headcount, or reputation, and the original version of this article claimed all three.

What to actually do

Start with the pages that produce business, not with the score.

Check whether you have field data at all, in Search Console or PageSpeed Insights. Smaller sites often do not have enough Chrome traffic to qualify, and that absence is itself worth knowing.

Run the lab test more than once and take the median. One Lighthouse run is a weather report, not a climate.

Identify your actual LCP element, then split the delay into server time, discovery, download, and render delay. Fix the part the evidence points at.

Compare your initial HTML against the rendered DOM, because content that only exists after JavaScript is invisible to anything that does not run it.

Run an automated accessibility check, then put the mouse down and tab through the page.

Then measure what changed after you shipped.

Why the data is public

The full dataset is 292 anonymized rows across 41 documented columns, CC BY 4.0.

You can recalculate every number in this post, disagree with our thresholds, and check the arithmetic. What you cannot do is re-crawl the original 292 sites, because the domains are anonymized. So the calculations are reproducible; the original collection is not. That is a real limit, and it belongs in the open.

The finding that survives

Six sites out of 191 passed all three thresholds. Every evaluated site failed the link-name rule. The median phone visitor waited more than ten seconds for the main content to appear.

Those numbers do not need the exaggeration we gave them.

Run the audit on your own site. It uses the same class of browser-based checks this study used, though a scan today will not reproduce an April 2026 measurement exactly, since the site, the test environment, and our rules have all moved since.

And treat the report as a starting point, not a verdict. That applies to our tool as much as anyone's.