Every claim, with the raw data behind it.
Anyone can post a screenshot. Here is the actual PageSpeed Insights JSON behind our numbers, measured on Google infrastructure and archived. Open any file and check it yourself.
Measured on July 8, 2026 (UTC) · Lighthouse 13.4.0 · Google PageSpeed Insights API.
| Page | Device | Score | LCP | CLS | Raw proof |
|---|---|---|---|---|---|
| villexweb.com home | Mobile | 98 | 2.4 s | 0 | View JSON |
| villexweb.com home | Desktop | 99 | 0.8 s | 0 | View JSON |
| villexweb.com industry page (home services) | Mobile | 98 | 2.4 s | 0 | View JSON |
| villexweb.com industry page (home services) | Desktop | 100 | 0.4 s | 0.001 | View JSON |
| villexco.com home (our in-house build) | Mobile | 100 | 1.3 s | 0 | View JSON |
| villexco.com home (our in-house build) | Desktop | 100 | 0.3 s | 0 | View JSON |
These are lab measurements run on Google infrastructure. Mobile runs simulate a mid-range phone on a slow mobile connection; desktop runs simulate a desktop computer on broadband. Field data (what real visitors experience) accumulates in Google CrUX as traffic grows.
The gates every build must pass
These are not promises. They are automated checks a build has to clear before it is allowed to ship.
A script checks every generated page against strict weight budgets, including every rendered image. If anything is oversized, the build fails and cannot deploy. Speed is enforced by machine, not by good intentions.
Every animated element must sit inside a choreography group, and every page must render its full content even if scripts never load. The build fails if either rule is broken, so motion can never hide your content.
An always-on monitor confirms each live site is reachable, loads within budget, and has not drifted from its performance baseline. If something degrades, we know before you do.
Want the full results page?
The results page carries the same proof with context, and the Trust Center explains how we handle claims.