Performance, With Evidence
We make a specific claim about how fast VeloCMS blogs load, so we publish the two kinds of evidence that back it: field data from real visitor browsers across every live site on the platform, and a dated lab measurement of velocms.org itself.
Neither number is cherry-picked. If a measurement comes back worse than we'd like, it stays on this page anyway — a page that only shows good numbers isn't evidence, it's marketing.
Platform-Wide Real User Monitoring
Every page load on a live VeloCMS blog reports Core Web Vitals via the browser's PerformanceObserver API. No cookies, no fingerprinting, no personal data — just timing. The numbers below are the p75 across every tenant site on the platform over the trailing 90 days.
90-day aggregate across every live VeloCMS blog · 1,662 samples · 2026-07-06 – 2026-10-04
2.39s
p75 · n=1,525
402ms
p75 · n=141
0.001
p75 · n=1,662
2.23s
p75 · n=1,535
821ms
p75 · n=1,540
Measurements are collected from real visitor browsers via PerformanceObserver — no cookies, no PII, no synthetic or internal traffic.
Our Own Lab Numbers
A point-in-time lab measurement of velocms.org itself, distinct from the continuous field data above. Lab numbers are reproducible and comparable across runs; field data reflects what real visitors actually experience across thousands of different sites, networks, and devices.
As of 2026-09-27
LCP: 841ms
Performance score: 81
LCP: 3.90s
Performance score: 76
Measured via Google PageSpeed Insights (Lighthouse under the hood), one desktop run and one mobile run against the production homepage.
Desktop tracks our internal sub-1s target; mobile currently does not — we show both rather than the one that looks better.
How We Measure
"RUM" (Real User Monitoring) is field data: actual visitor browsers reporting what they experienced, aggregated across every live site. "Lab" data is a single, reproducible Lighthouse run against one page under controlled conditions. The two rarely match exactly — lab measurements are simulated and consistent; field data is messy and represents real networks, real devices, and real distance from our servers. We publish both because each answers a different question: lab tells you what's achievable, RUM tells you what's actually happening.
Our Performance Budget
These are the thresholds in our Lighthouse configuration. Lab and field numbers above that miss them are tracked as defects.
| Metric | Budget |
|---|---|
| Largest Contentful Paint (LCP) | < 1000 ms |
| Interaction to Next Paint (INP) | < 100 ms (p75) |
| Cumulative Layout Shift (CLS) | < 0.05 |
| Total Blocking Time (TBT) | < 200 ms |
| First Contentful Paint (FCP) | < 800 ms |
| Speed Index | < 1500 ms |
Engineering Practices
How the platform is built. The numbers above show where it meets its budget today and where it does not.
Pages are rendered on the server; client JavaScript is added only for the parts that need interaction.
Database reads are cached on the server and refreshed when you publish, so a page does not re-query everything on every visit.
Images served through next/image are converted to AVIF or WebP, sized for each screen and lazy-loaded.
Our Lighthouse configuration sets 150 KB of script per route. Pages over that budget are tracked as defects, not hidden.