2026 Managed Small-Business Website Performance Benchmark: Research Protocol

Published research protocol v1.0 — 2026-08-09. No performance results have been collected yet, and no client-specific comparison is approved for publication. The tables below deliberately say “pending” rather than implying a result. Results will be added as a dated update after the runs and permissions are complete.

Small-business website performance comparisons often collapse several different questions into one score. A lab run can help debug a page under simulated conditions. Chrome User Experience Report data summarizes eligible real-user experiences over a rolling period. A conversion report describes what visitors did after arriving. Those are all useful, but they are not interchangeable.

This study is designed to answer a narrower question: under a documented, repeatable protocol, how do a set of actively managed small-business websites behave across common page types on mobile and desktop, and which implementation characteristics explain the largest differences?

The goal is not to declare a universal “fastest platform.” The goal is to publish a dataset, repeatable collection method, and interpretation guide that a business owner or web operator can use to ask better questions about performance.

Key Findings

This is a pre-results draft, so the current findings concern measurement quality rather than site winners and losers:

1. A single lab score is not enough. Google documents that PageSpeed Insights includes both lab and field data, that they represent different conditions, and that datacenter/network conditions can vary. The study will use repeated lab runs and will not average lab and field metrics together.
2. Core Web Vitals need percentile and population context. The “good” thresholds apply at the 75th percentile of real visits. A green lab score cannot prove that the 75th percentile of real users has a good experience.
3. The unit of comparison must be defined. Comparing one homepage with another site's contact page would confound page purpose, content weight, and interaction design. This protocol groups like page types and reports each URL separately.
4. Public pages are not automatically approved case-study material. Client names and site-level commentary will remain unpublished unless Rob records approval. If approval is not granted, the public article will use anonymized site identifiers or a Mendola.Tech-owned test fixture.

No claim about relative speed, conversion impact, or business outcome will be added until the raw runs exist and the limitations are reviewed.

Methodology

Research questions

The first release will answer five questions:

1. What are the median mobile and desktop lab measurements for each tested URL?
2. How much does the same URL vary across repeated runs?
3. Which pages have eligible CrUX field data, and what does that field data show separately from the lab runs?
4. Which observable page characteristics—HTML size, JavaScript transfer, image transfer, request count, font loading, or third-party scripts—coincide with the largest lab differences?
5. Which recurring implementation changes appear most actionable for small-business sites?

The study will not claim that performance caused a ranking, lead, or revenue change. Those would require different data and a stronger causal design.

Proposed sample

The current Mendola.Tech public site lists six managed deployments. They are a logical operational sample because their architectures and maintenance context can be documented. Their inclusion in a named benchmark is still subject to approval.

Proposed site	Publicly listed service type	Benchmark inclusion status
Camo Krew Aluminum	Managed website	Approval not yet recorded
A Able Painting Company	Managed website	Approval not yet recorded
Kaines Construction LLC	Managed website	Approval not yet recorded
Southern Drywall Services	Managed website	Approval not yet recorded
Mendola Painting	Managed website	Approval not yet recorded
You'll Hook 'Em	Managed website	Approval not yet recorded

If one or more clients do not approve named inclusion, the study will either anonymize the identifiers or replace the sample with controlled, Mendola.Tech-owned fixtures. It will not quietly remove weak performers after seeing their results.

Page selection

For each included site, select up to three canonical URLs that represent comparable user intent:

• Homepage
• Primary service page
• Contact or estimate page

Record the exact canonical URL, HTTP status, test date, and any redirect. Exclude a URL only for a pre-registered reason such as an outage, access block, active deployment, or missing comparable page type. Keep an exclusion log.

Collection protocol

For every URL and device profile:

1. Confirm the canonical URL and final HTTP status.
2. Record the deployment/commit identifier when Mendola.Tech controls the code.
3. Run five PageSpeed Insights lab tests for mobile and five for desktop across at least two collection sessions.
4. Preserve the raw JSON response for every run rather than copying only the headline score.
5. Record Lighthouse version, test timestamp, strategy, reported location/environment, and category configuration.
6. Extract performance score, Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Total Blocking Time (TBT), Speed Index, First Contentful Paint (FCP), and Time to First Byte (TTFB) where present.
7. Extract transfer size, request count, unused JavaScript diagnostics, and image-delivery diagnostics where available.
8. Record CrUX URL-level or origin-level field data separately, including whether the URL had sufficient eligible data.

The primary lab statistic will be the median of the five runs. The dataset will also report minimum, maximum, and range so readers can see instability. A mean may be included as a secondary value, but it will not replace the individual runs.

Performance thresholds

The article will use Google's documented Core Web Vitals definitions and “good” thresholds on the final test date:

Field metric	Current “good” threshold to verify on test date	Interpretation
LCP	At or below 2.5 seconds	Loading experience
INP	At or below 200 milliseconds	Interaction responsiveness
CLS	At or below 0.1	Visual stability

These thresholds are evaluated at the 75th percentile in field data. Lighthouse's TBT is a lab diagnostic and will not be relabeled as field INP.

Results table (publication blocked pending measurements)

Site ID	Page type	Device	Median performance score	Median LCP	Median CLS	Median TBT	Field-data status
Pending	Pending	Mobile	Not measured	Not measured	Not measured	Not measured	Not checked
Pending	Pending	Desktop	Not measured	Not measured	Not measured	Not measured	Not checked

The final article will link to machine-readable CSV/JSON, raw reports, the collection script, a data dictionary, and the exclusion log. The repository will include a command that reruns the same extraction against a user-supplied URL list.

Interpretation rules

• Describe the measured URL and date, not an entire company or platform.
• Use “in these runs” rather than turning a sample result into a universal claim.
• Treat differences smaller than normal run-to-run variation cautiously.
• Explain large payloads in context. A portfolio page with original photography serves a different job than a sparse contact page.
• Separate implementation observations from causal claims.
• Do not infer search ranking, conversion rate, or revenue from performance data alone.
• If a live deployment changes during collection, rerun the affected set or document the version split.

What the benchmark can reveal

The most useful output is not a leaderboard. It is a pattern library. Examples of potentially actionable patterns include oversized hero images, render-blocking fonts, excessive third-party scripts, client-side rendering that delays primary content, missing intrinsic image dimensions, and slow server response.

Those remain candidate explanations until the measurements are collected. The final analysis will connect each observation to the raw diagnostic that supports it and, when practical, rerun the URL after a controlled fix.

Limitations

• The proposed sample is a convenience sample of sites associated with one operator, not a representative sample of all small-business websites.
• PageSpeed/Lighthouse lab results vary with test infrastructure, network conditions, page state, and tool versions.
• CrUX field data may be unavailable for lower-traffic URLs and represents eligible Chrome users rather than all visitors.
• Page types and content requirements are not perfectly identical across businesses.
• A cross-sectional test cannot show long-term maintenance drift.
• Performance measurements do not establish search, lead, or revenue outcomes.
• Named client publication requires approval even if the pages and metrics are publicly observable.
• The thresholds and tooling can change; the final article must record versions and recheck documentation on the run date.

What Mendola.Tech adds

Mendola.Tech's contribution will be the repeatable dataset and operating context: multiple real small-business page types, repeated raw runs instead of cherry-picked screenshots, explicit separation of field and lab data, version/date records, and implementation notes from the person maintaining the sites.

The practical addition is a reusable collection harness and results template that another operator can apply to their own URL list. If named client permission is not available, the method and open test fixture will still be publishable without inventing or exposing client outcomes.

Sources

• How the Core Web Vitals thresholds were defined — Google/web.dev; accessed 2026-08-09. Supports the LCP, INP, and CLS thresholds and the 75th-percentile interpretation.
• About PageSpeed Insights — Google for Developers; accessed 2026-08-09. Supports the distinction between lab and field data, the CrUX time window, and test-environment variability.
• Core Web Vitals workflows with Google tools — Google/web.dev; accessed 2026-08-09. Supports separating field monitoring from lab diagnostics and using the tools for different stages of performance work.
• Web Vitals — Google/web.dev; accessed 2026-08-09. Supports the current stable Core Web Vitals set and metric lifecycle.