State of Small Business Websites 2026: A Developer's View of the Data

We scanned 292 B2B small-business websites in April 2026 with the production pipeline behind DeepAudit.

Of those, 191 returned a valid mobile verdict. Here is the whole result, with denominators, because the denominators are the part people drop when they quote it.

Median mobile LCP across the valid tests: 10.5 seconds.

That is the number to remember. Not a threshold pass rate, but the fact that on a median small-business B2B site, the largest thing on the page took more than ten seconds to show up on a phone.

These are Lighthouse lab results, not Core Web Vitals

The original title of this article said "96.9% Fail Core Web Vitals." That was wrong, and since this is the page most likely to be cited, it needs correcting at the top rather than in a footnote.

Google's Core Web Vitals are LCP, INP, and CLS, measured from real users in the field.

We measured LCP, FCP, and CLS in a single Lighthouse lab run per site. FCP is not a Core Web Vital. We never captured INP. We have no field data at all.

So the accurate claim is: *96.9 percent of the sites returning a valid mobile lab test failed at least one threshold we configured.* That is still a serious finding. It is a different finding from the one the old headline advertised.

Where the sites came from, and what that limits

The 292 domains came from a ZoomInfo B2B prospect list in our sales pipeline, weighted toward construction, trades, and small professional services.

Purposive, not random. We did not go hunting for bad sites, which removes one bias, but this is a snapshot of one pipeline and not an estimate for the small-business web.

Each site was measured once. Lighthouse varies with server load, caching, and test conditions. We did not repeat the runs, so treat the exact percentage as a snapshot rather than a population constant. A site at 2.49 seconds and a site at 2.51 seconds land on opposite sides of a threshold, and we have not quantified how many sat that close to the line.

How the pages were captured

Each page opened in Chromium via Puppeteer, and the scanner inspected the rendered DOM after a bounded wait.

That is one browser stage of page processing. It is not Googlebot. Google runs its own crawl, render queue, indexing, and ranking systems, and no third-party audit reproduces them. We used to say we render "the way Googlebot does," and that was marketing, not engineering.

The study ran the rule set as it existed in April 2026, roughly 60 checks. The current system is larger, which means a scan today will not reproduce this study exactly. If we want a longitudinal comparison, we have to version the rules, the Chromium build, and the Lighthouse version and hold them still. We had not done that. That is a real gap in the methodology and we are naming it rather than claiming the method is "frozen."

LCP: the most common failure, and the cause is not in this dataset

165 of 191 valid tests exceeded four seconds, median 10.5.

Now the part where the earlier version of this article overreached. It listed causes "in order of frequency": oversized hero images, three synchronous scripts in the head, fonts blocking text. The dataset has 41 columns and none of them record any of that. No LCP element type, no image bytes, no script counts, no font-display values. Those were educated guesses presented as measurements, and in a research post that is not acceptable.

What we can say is how to actually diagnose it. LCP is a composite. Split it:

• Server response time
• Delay before the LCP resource is even discovered
• Time spent downloading it
• Render delay after it has arrived

One page we did inspect by hand used a 2400x1600 PNG at 3.2 MB as its hero, and that image became the LCP element. For that page, image delivery was obviously where the work was. We are not going to extrapolate a six-second 4G download time from it, because transfer time depends on throughput, latency, caching, and contention we did not record.

Framework helpers make the fix easier, not automatic. Next.js can generate responsive widths and modern formats, though its image API has moved on since this study and WebP, not AVIF, is the default output. Which image deserves priority is a question about your page, and only a trace answers it.

Third-party scripts and fonts: real issues, wrong prescriptions

We did encounter pages loading several early third-party scripts during manual review. We did not record that as a dataset column, so we will not give you a population statistic for it.

And "defer every third-party script" is bad advice. Some scripts have consent, ordering, attribution, or security requirements, and moving them breaks things quietly. Inventory the requests, find which ones block parsing or eat the main thread, delete what nobody can justify, and move the rest as late as their actual function allows. Then regression-test consent and attribution, because that is what breaks.

Fonts are the same story. font-display: swap shows fallback text quickly, which helps FCP. It can also *cause* layout shift when the fallback and final fonts have different metrics. It is a tradeoff, not a free win, and the three-line CSS fix hides a decision about subsetting, weights, WOFF2, preload, and fallback metrics.

FCP: 139 of 192, and it is not "worse than LCP"

The old version claimed FCP was worse than LCP. Our own table says otherwise: LCP failed on 86.4 percent, FCP on 72.4 percent.

FCP is when the browser paints any content. Not meaningful content, not useful content, any. It does not tell you the page is ready, and it does not identify a cause: navigation, redirects, TTFB, blocking CSS, fonts, and script execution all live inside it.

One pattern we saw by hand was an empty shell that built the whole page client-side after fetching its data. For a public marketing page, putting the main content in the initial response removes a long chain of things that all have to succeed before anything appears. For an authenticated app, a different architecture is fine. The URL's job decides, not a slogan about React.

Link names: 191 of 191

Every single page with valid accessibility data had at least one link that failed axe-core's link-name rule.

That means the link's purpose was not programmatically available. A screen reader user gets something useless.

<!-- no accessible name -->
<a href="/products"><svg aria-hidden="true">...</svg></a>

<!-- one possible fix -->
<a href="/products" aria-label="View our products">
  <svg aria-hidden="true">...</svg>
</a>

An aria-label is *one* fix. Visible text, visually hidden text, aria-labelledby, or a real alt on a linked image may all be better depending on the component. And passing axe is not the goal. A link labeled "Social icon" passes the rule and still tells the user nothing.

Icon-only social links were a recurring example in our manual review. We did not classify every failure, so we are not going to tell you they were "usually" the cause, and we are not going to blame developers for not reading component-library docs. The library ships an SVG. Naming the link is the application's job.

Run axe-core in CI. It catches programmatically detectable regressions. It does not establish WCAG conformance, and it does not replace tabbing through the page yourself.

CLS passed most often, and that is all we know

165 of 193 passed. That does not mean developers "internalized" CLS, which is a claim about people we never studied.

It means serious load-time shift was less common in this lab test than poor LCP or FCP. Field CLS can be worse, because shifts happen after load through ads, embeds, late content, and app transitions. When CLS is bad, use layout-shift attribution to find the actual element. Do not guess from the score.

What is actually reproducible

The 292-row anonymized dataset with 41 documented columns is public under CC BY 4.0. Open data, not open source: the audit code is not in that release.

You can recalculate every number in this post and disagree with our thresholds. You cannot re-crawl the original 292 domains, because they are anonymized, and we did not package the browser traces, the per-violation records, or the exact environment.

The calculations are reproducible. The crawl is not. That is the honest boundary, and it is smaller than "anyone can rerun this."

There is no four-keyword fix

The old ending said every finding was fixable in an afternoon by a developer who knew four keywords: priority, defer, font-display: swap, aria-label.

That paragraph was the most confident and least true thing in the article. Those four terms do not touch slow servers, bad caching, client rendering, render-blocking CSS, main-thread work, field INP, post-load CLS, or a genuinely misleading accessible name. And link labels do not make a site slow; that sentence only existed because it completed a rhythm.

What the study found is narrower and still worth your time: poor simulated mobile loading and missing accessible link names were close to universal in this sample. No single cause, no single fix.

For each page that matters: compare the initial HTML against the rendered DOM, run repeatable lab tests, check field data if you have enough traffic to have any, find the actual LCP element, split its delay into server, discovery, download, and render, inventory your third-party scripts, test the font tradeoff, run axe in CI, tab through the page, and measure again after you ship.

The scanner finds the condition. The trace finds the cause. The second measurement tells you whether you fixed it.

Run the audit on your own site, then go argue with it.