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.

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:

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)

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.

Published benchmark protocol v1.0 — 2026-08-09. No model has been selected and no result has been measured. The proposed dataset will be synthetic. Model IDs, prompts, code, raw outputs, prices, and test dates must be frozen before results are written.

An AI document workflow can look excellent in a demo and still create more work than it removes. The model may extract most fields correctly while confidently corrupting a small number of consequential values. It may succeed on clean PDFs and fail on rotated photos. It may produce valid JSON while assigning a phone number to the wrong record. It may appear inexpensive per request while creating an expensive review queue.

This benchmark evaluates the complete document-to-record workflow: input handling, extraction, validation, abstention, human escalation, correction, and recovery. The initial task is intentionally narrow enough to reproduce with synthetic data.

Key Findings

The current findings are methodological and will remain separate from future measured results:

1. Aggregate accuracy is not a deployment decision. A workflow needs field-level correctness, consequential-error rates, abstention behavior, latency, cost, and human-review burden.
2. The validator is part of the system. Schema checks, date/amount constraints, identifier patterns, duplicate detection, and cross-field rules can catch failures that a model-level score hides.
3. Safe failure needs a measurable definition. “Human in the loop” is too vague. The benchmark must report which documents are escalated, how often bad records pass automatically, and how many correct records are needlessly reviewed.
4. Synthetic data protects clients but narrows generalization. The first release can be open and privacy-safe, but it cannot prove performance on every real document distribution.

No model ranking, accuracy percentage, price, or time saving will appear until the frozen harness has produced raw output.

Methodology

Task definition

The proposed workflow converts a mixed-format small-business intake document into a structured record with these fields:

• Document type
• Organization/person name
• Email address
• Phone number
• Service or request category
• Request date
• Currency amount when present
• Free-text summary
• Source document identifier
• Extraction confidence or abstention state

The exact schema will be published as JSON Schema. Every output must either validate against it or enter an explicit failure state. The system may not silently drop an input.

Proposed dataset

Create 300 synthetic documents with deterministic ground-truth JSON records. No client or real-person data will be used.

The generator will vary names, phone formats, dates, currency formatting, field order, optional fields, duplicate documents, and plausible distractor values. Random generation will use a published seed so the corpus can be recreated.

The adversarial stratum is not a cybersecurity penetration test. It is a reliability set containing ambiguity and instruction-like document text that should not override the extraction task.

Systems under test

The initial study may compare:

• A rules-only baseline
• One or more current multimodal language-model APIs
• A hybrid workflow using OCR/rules before a language model
• The same model with and without deterministic validation/retry logic

Final systems will be selected immediately before collection because models and pricing change. The article will record provider, exact model identifier, API version, region if relevant, request parameters, prompt/template hash, structured-output mode, retry policy, and public price source on the test date.

No provider will be described as the “best AI model.” The result applies to this task, corpus, configuration, and date.

Run controls

1. Freeze the dataset, ground truth, schema, scorer, and primary metrics before running models.
2. Use a clean API session and the same input representation for comparable systems.
3. Set deterministic parameters where the API supports them and record unsupported controls.
4. Run each document once for the primary cost/latency analysis.
5. Run a pre-registered stability subset multiple times to measure output variation.
6. Preserve raw requests/responses after removing credentials and provider-restricted data.
7. Log retries, timeouts, schema failures, refusals, and provider errors.
8. Price each run from measured token/image usage and the provider's dated public price—not from memory.
9. Manually review scorer disagreements before final aggregation without changing ground truth after seeing a model label.

Primary metrics

Field exact-match accuracy

For normalized fields such as phone, email, date, amount, and category:

fieldAccuracy = correct extracted fields / scorable ground-truth fields

Normalization rules are published in advance. For example, phone formatting punctuation may be ignored while digits and extension must match.

Record perfect-match rate

recordPerfectMatch = records with every required field correct / all records

This deliberately produces a stricter view than field-level accuracy.

Undetected consequential error rate

Define consequential fields before testing—for example identity, contact destination, date, and currency amount.

undetectedConsequentialError = bad consequential records accepted automatically
                               / records accepted automatically

This is the primary safety metric for an auto-entry decision. A workflow that escalates every record could have a low undetected-error rate while providing no automation value, so it must be read with review burden.

Review burden

reviewRate = records sent to human review / all records
falseReviewRate = fully correct records sent to review / fully correct records

The final artifact will also time a defined review procedure on a sample. It will not invent universal wage savings.

Abstention quality

Treat an explicit “cannot determine” or validation failure as abstention. Report:

• Recall of bad records into review
• Precision of the review queue
• Coverage: percentage accepted automatically
• Risk-coverage curve as the confidence/review threshold changes

Latency and cost

Report median, 95th percentile, minimum, and maximum end-to-end latency. Report measured API cost per document and per 1,000 documents for this corpus and date. Keep provider pricing inputs visible so the calculator can be updated.

Acceptance scenarios

Instead of one arbitrary pass/fail line, publish three user-editable scenarios:

The benchmark will not certify a high-consequence deployment. It shows the tradeoff curve and the evidence a decision-maker would still need.

Results table (blocked pending execution)

Every aggregate will be accompanied by a breakdown for each input stratum. A strong clean-PDF result must not conceal failure on mobile photos or ambiguous documents.

Operational decision framework

After results exist, a business can use four gates:

1. Validity: Does the workflow produce the required schema and preserve every input?
2. Reliability: At the chosen automation coverage, is the undetected consequential-error rate acceptable for this task?
3. Operability: Can the business handle the review queue, outages, retries, corrections, and audit records?
4. Economics: Using its own labor inputs, does the measured review burden plus API/tooling cost improve the current process?

Passing the first three gates does not prove the fourth. The companion calculator will use measured review minutes and user-entered labor values rather than claiming a universal ROI.

Limitations

• Synthetic documents cannot represent every real layout, handwriting style, language, domain vocabulary, fraud pattern, or image condition.
• A 300-document corpus may be too small to estimate rare failure rates precisely.
• Model APIs, hidden system behavior, prices, and availability can change after the test date.
• Repeated API calls may not be deterministic even when temperature or seed controls are available.
• The benchmark measures one extraction workflow, not general reasoning ability.
• The defined “consequential” fields reflect the proposed task and must change for other business processes.
• A validator can catch malformed or implausible values but cannot guarantee that a plausible value belongs to the correct real-world entity.
• Privacy, retention, contractual, legal, and sector-specific requirements are outside the benchmark and need separate review.
• The study cannot authorize fully automatic use in financial, legal, medical, employment, safety, or other high-consequence decisions.

What Mendola.Tech adds

Mendola.Tech's contribution will be an open, end-to-end reliability harness built around operational decisions rather than a model-demo score. The repository will include the synthetic corpus generator, ground-truth records, JSON Schema, prompts/configuration hashes where permitted, scoring code, raw-output format, validation rules, review-threshold calculator, and reproducible reporting command.

The unique perspective comes from treating AI as one component in an automation system. API integration, schema validation, retries, human escalation, auditability, and failure recovery are measured alongside the model response because those are the parts that determine whether a workflow can actually be operated.

Sources

• NIST AI Risk Management Framework — National Institute of Standards and Technology; accessed 2026-08-09. Supports lifecycle risk management and incorporating trustworthiness into AI design, use, and evaluation.
• NIST AI Resource Center — NIST; accessed 2026-08-09. Supports testing, evaluation, verification, and validation as operational AI practices.
• NIST AI RMF Core — NIST; accessed 2026-08-09. Supports repeatable/documented evaluation, reliability validation, limitation documentation, safe failure, monitoring, and contextual interpretation.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — NIST AI 600-1; accessed 2026-08-09. Supports applying risk-management actions to generative-AI systems based on context, requirements, and risk tolerance.
• Effectiveness of the AI RMF — NIST AI Resource Center; accessed 2026-08-09. Supports evaluating whether processes, indicators, measurements, and expected outcomes actually improve AI risk management.

Open formula and worksheet v1.0 — 2026-08-09. No market-average prices, client savings, or ROI claims are included. The formulas below are the complete calculation model; an interactive version can be added later without changing the underlying method.

“How much does a small-business website cost?” is usually answered with a launch quote or a monthly plan. Neither number is useful on its own if the decision spans several years.

A website has to be created or migrated, hosted, secured, updated, measured, corrected, and recovered when something breaks. Someone also has to write changes, resize photos, answer provider questions, check forms, monitor search visibility, and decide what happens when the original builder is no longer available.

This calculator turns those responsibilities into visible inputs. It does not assume that a managed service is always cheaper than a one-time build or do-it-yourself platform. It makes the break-even conditions inspectable.

Key Findings

1. Launch cost and operating cost should be compared over the same period. A low initial price can coexist with high internal labor. A larger project can be economical when a business already has someone capable of operating the site. The calculator keeps those cases separate.
2. Labor is a first-class input. Content changes, vendor coordination, troubleshooting, measurement, and routine checks consume time whether the work is done by an owner, employee, freelancer, or managed provider.
3. Maintenance and recovery are not optional line items just because they are omitted from a quote. Software updates, access controls, backups, and recovery preparation are real operating responsibilities. The model records who owns them and what budget is assigned.
4. No default can represent every business honestly. The published calculator should open with blank or clearly labeled illustrative inputs, never with an unexplained “industry average.”

Methodology

Model objective

The calculator compares website operating models over a user-selected horizon using the same responsibility categories. It is a planning model, not a survey of market prices.

The default horizon proposed for the interface is five years because it is long enough to expose recurring labor and rebuild assumptions. Users can change the horizon from one to ten years.

Core formula

For a horizon of Y years:

TCO(Y) = Initial + Recurring(Y) + InternalLabor(Y) + PlannedChanges(Y)
       + Measurement(Y) + MaintenanceAndRecovery(Y) + Transition(Y)

Where:

Recurring(Y) = 12 × Y × monthly recurring fees

InternalLabor(Y) = Y × 52 × weekly internal hours × loaded hourly value

PlannedChanges(Y) = Y × annual planned change budget

Measurement(Y) = Y × annual analytics, reporting, and testing cost

MaintenanceAndRecovery(Y) = Y × annual maintenance, monitoring, backup,
                            and recovery-readiness cost

Transition(Y) = expected migration, rebuild, or provider-change cost
                within the selected horizon

The model does not add speculative “lost revenue from downtime” by default. A business can add a separate risk scenario, but it must enter its own downtime assumption and value rather than receiving a dramatic invented number.

Input worksheet

The interface must prevent double counting. For example, if hosting and routine maintenance are included in a managed monthly plan, the user marks those responsibility rows as included rather than entering them again.

Operating models

The calculator will provide blank comparison columns for:

• Do it yourself
• One-time build with internal operation
• Project-based freelancer
• Agency retainer
• Mendola.Tech managed website
• Custom model

These labels do not carry hidden cost assumptions. Users enter the actual quote or operating record for each option. Mendola.Tech's current public price may be prefilled only if it is pulled from the same repository source used by the pricing page and dated in the result.

Responsibility matrix

A cost comparison is incomplete unless it also shows ownership. The downloadable worksheet will require an owner for each responsibility:

An “unassigned” responsibility is not automatically converted to money. It appears as an operating gap next to the TCO result.

Output metrics

The calculator will produce:

• Total cost over the selected horizon
• Equivalent monthly cost over that horizon
• Initial cash requirement
• Recurring cash fees
• Internal labor hours and modeled value
• Percentage of total assigned to labor, tools/provider fees, planned changes, and resilience
• Count of unassigned responsibilities
• Break-even point between two selected models, when one exists
• A print/download summary containing all inputs, formulas, scope flags, and calculation date

Break-even formula

For two models with initial costs I₁ and I₂ and monthly operating costs M₁ and M₂, the simple cash break-even month is:

breakEvenMonth = (I₂ - I₁) / (M₁ - M₂)

This is shown only when the denominator is non-zero and the result is positive. The full calculator also includes internal labor and annual costs converted to a monthly equivalent. It will label the result as a planning estimate, not a guaranteed saving.

How to use the result

The lowest TCO is not automatically the best decision. A business may deliberately pay more for faster support, less owner time, clearer accountability, stronger recovery preparation, or access to deeper engineering. Another business may prefer a low-cash DIY model because the owner enjoys the work and already has the skill.

Use the result to ask four questions:

1. Which responsibilities are actually included?
2. Whose time is being consumed?
3. What happens after the launch period?
4. What happens when the site breaks or the provider relationship ends?

The calculator is successful if it makes those tradeoffs visible, even when the user chooses a competitor or a DIY option.

Limitations

• This is a deterministic planning model, not a forecast of leads, rankings, revenue, or business growth.
• User-entered labor value and time estimates can dominate the result and may be uncertain.
• Taxes, financing, inflation, discounts, and time value of money are excluded from the simple version.
• Complex e-commerce, regulated systems, custom applications, and paid campaigns need separate models.
• Recovery and security costs do not guarantee that an incident will be prevented or successfully resolved.
• Vendor prices and Mendola.Tech scope can change; every saved result must include its calculation date.
• The model does not assign universal market-average prices because no single average fits scope, geography, platform, or service level.

What Mendola.Tech adds

Mendola.Tech's contribution is a responsibility-based calculator tied to the way websites are actually operated. Instead of using a lead-generation quiz that hides assumptions and announces a predetermined winner, the artifact will publish the formula, let users edit every value, flag double counting, and show unassigned operational work.

The responsibility matrix comes from the overlap between website development, ongoing web operations, SEO/local visibility, analytics, infrastructure, and direct support in the Mendola.Tech service. The same worksheet can be used to evaluate Mendola.Tech, an agency, a freelancer, a builder platform, or an internal team.

Sources

• Small and Medium-Sized Business Resources — U.S. Cybersecurity and Infrastructure Security Agency; accessed 2026-08-09. Supports treating software updates, account security, and resilience as operational responsibilities rather than optional marketing features.
• Mitigations and Hardening Guidance for MSPs and Small- and Mid-sized Businesses — CISA; accessed 2026-08-09. Supports including backups, access control, and provider/customer responsibility in the operating model.
• Web Content Accessibility Guidelines (WCAG) 2.2 Quick Reference — W3C Web Accessibility Initiative; accessed 2026-08-09. Supports accessibility as an ongoing quality responsibility rather than a purely visual launch task.
• SEO Starter Guide — Google Search Central; accessed 2026-08-09. Supports the inclusion of crawlable structure, useful content, and ongoing search-quality work in the responsibility map.
• About PageSpeed Insights — Google for Developers; accessed 2026-08-09. Supports separating measurement/diagnostics from unsupported guarantees about real-user outcomes.