A practical way to connect mobile performance with your own analytics, enquiries and revenue — without relying on a generic conversion promise.
Written by Kasun Jayasekera, founder of aibuiltmysite.
A slow page can create friction before a visitor reaches the phone number or form. The effect varies by audience, device and traffic source, so measure it with your own field data rather than applying a generic loss percentage.
The math
Start with a baseline: mobile visits, completed calls or forms, and the loading metrics reported by real visitors. Segment the data by device and landing page so a slow high-traffic page is not hidden inside a site-wide average.
After a performance change, compare equivalent periods and account for campaign, season and traffic-mix changes. Multiply any measured change in qualified enquiries by your own close rate and average job value; label the result as an estimate, not a guaranteed return.
Why most sites are slow
- Hero images uploaded at 4MB instead of 200KB.
- Render-blocking JavaScript in the head.
- Hosted on a generic shared server in the wrong country.
- Web font sprawl (six families, one used).
- Animation libraries imported globally, used on one button.
How fast is fast enough
Use current Core Web Vitals guidance and test both lab and field performance. Lighthouse is a diagnostic snapshot, not a guarantee of real-user speed or business results.
What we do by default
- Cloudflare Pages hosting — global edge, no shared-server lottery.
- Image optimisation as a build step (AVIF + WebP fallbacks, responsive sizes).
- One web font family, two weights max, swap not block.
- Server-side render where it counts; client-side only where interactivity demands it.
- JS bundle budget: under 100KB compressed for the first paint.