← back to the receipts

Reproducible by anyone

How we tested

The whole argument rests on one distinction: lab scores can be gamed; field Core Web Vitals cannot. Here is exactly how each number on this site was produced, so you can run it yourself.

01

Field reality — Core Web Vitals (CrUX)

the un-gameable number

For every domain we query Google PageSpeed Insights (which serves CrUX). We take the 28-day 75th-percentile of real Chrome users: LCP, INP, CLS. A site "passes" Core Web Vitals only if p75 LCP ≤ 2.5s AND INP ≤ 200ms AND CLS ≤ 0.1. This is the metric Google uses for ranking; no client-side script can change it without genuinely making the page faster for real users.

GET https://www.googleapis.com/pagespeedonline/v5/runPagespeed
  ?url=https://www.<dealer>/&strategy=mobile&category=performance&key=<key>
# read loadingExperience.metrics.* (p75); fall back to originLoadingExperience
02

Lab score — Lighthouse, controlled

what marketing screenshots show

We run Lighthouse (mobile, simulated throttling) and take the median of N runs to cut variance. Lab scores are reproducible but synthetic: they reward deferring or hiding work, even when the user's real experience is unchanged. We report lab beside field precisely to show the gap.

npx lighthouse <url> --only-categories=performance \
  --throttling-method=simulate --chrome-flags="--headless=new"  # ×N, take median
03

Isolation — does the layer itself do anything?

allowed vs. blocked

To test a speed layer in isolation we load the same page twice — once with the layer's scripts allowed, once with them blocked at the network — 12 runs, median-of-3. If the layer worked, blocking it would make the page measurably worse. On the DealerInspire dealer we tested, blocking Auto Genius left LCP unchanged and TTI slightly faster: the layer relocates main-thread work, it doesn't remove it.

lighthouse <url> --block-url-patterns="*autogenius*" ...   # blocked
lighthouse <url> ...                                       # allowed
04

Fair A/B — control vs optimized, same conditions

isolating the rewrite

To measure our own edge rewrite honestly, we serve BOTH the original and the optimized HTML from the same localhost origin, so each pays the identical cross-origin sub-resource cost. The delta is then purely the rewrite. (Comparing an optimized localhost page against the live origin would unfairly penalize the optimized side — a trap we hit and corrected.)

control  = origin HTML + <base href> only
optimized = + critical CSS + non-blocking sheets + deferral
# both served from localhost, Lighthouse median of 5

Provenance

  • · Field + lab data pulled 2026-05-29 via PageSpeed Insights API (CrUX dataset).
  • · Auto Genius figures transcribed from their marketing sheet (Exhibit A on the home page); illegible rows omitted, not invented.
  • · “What's possible” deltas are our edge-rewrite fair A/Bs (median of 5), image optimization off.
  • · Thresholds are Google's published “good” p75 bars: LCP ≤ 2500ms, INP ≤ 200ms, CLS ≤ 0.1.

Internal evidence build · Spif.io · 2026-05-29. Field data: Google PageSpeed Insights / CrUX (real-user 28-day p75). Auto Genius figures transcribed from their own marketing sheet (shown as Exhibit A). Lab numbers are synthetic and gameable; field numbers are what Google ranks on.