A roofer rang us last September. His old WordPress site took 6.4 seconds to render the phone number on a customer's iPhone in a Sunderland loft conversion. The customer hung up and rang the next number on the list.
That's the unsexy reason every site we ship at Built Local is engineered to render the hero, the phone number, and the call button in under a second on throttled 3G. This is how we do it - and the two embarrassing mistakes we made first.
The benchmark we hold ourselves to
Every site gets tested in Chrome DevTools with the network throttled to "Slow 3G" (400 kbps down, 400ms RTT) and CPU throttled 4x. The pass condition: Largest Contentful Paint under 1,000ms, Total Blocking Time under 50ms, no layout shift. We don't ship until it passes on three pages: the homepage, a service page, and a town page.
For context, the median UK small business website measured by HTTP Archive in 2025 was 4.2s LCP on the same throttling. We're shipping 4x faster than the median, on purpose, because the customer ringing from a loft doesn't care about the median.
The image budget
Images are 80% of every page weight problem. Our rule on every local web design build:
- Above-the-fold imagery: 80KB total, hard cap. One hero, maybe a logo. That's it.
- AVIF first, WebP fallback, JPEG never. AVIF averages 50% smaller than WebP at the same perceptual quality.
- Explicit width and height attributes on every image. No layout shift, ever.
- Hero image preloaded with
<link rel="preload" as="image" fetchpriority="high">in the route head. - Everything below the fold:
loading="lazy", no exceptions.
The 80KB hero cap is the one rule clients push back on most. They want a 2MB drone shot of their best job. We compress, art-direct, and ship a 60KB AVIF that looks identical at the viewport size it'll actually be seen at. You can read more on why we won't ship stock imagery in our stock-photo field note.
The edge runtime
Every Built Local site runs on Cloudflare Workers. The HTML for a town page like /web-design-in/sunderland renders at the edge node closest to the visitor - for a North East roofer's customer in Washington, that's the Manchester or Newcastle PoP, not a server in Virginia. Time-to-first-byte is consistently under 80ms in the UK.
We don't use SSR-then-rehydrate for marketing pages. We ship server-rendered HTML and a tiny hydration bundle (under 30KB gzipped) that only attaches handlers to the mobile menu and the contact form. The phone tap-to-call link works before the JS has even started downloading.
The two mistakes we made first
Mistake 1: lazy-loading the hero image
We had a phase in early 2024 of loading="lazy" on everything, including the hero. LCP got worse, not better - the browser deprioritised the most important image on the page. Fix: loading="eager" and fetchpriority="high" on the hero, loading="lazy" on everything else.
Mistake 2: shipping Google Fonts the normal way
The <link rel="stylesheet" href="fonts.googleapis.com..."> pattern adds two extra DNS lookups, two TLS handshakes, and a render-blocking CSS file. On 3G that's 800ms of dead time. We self-host the woff2 files now, with font-display: swap and a <link rel="preload"> for the one weight that's used above the fold.
What this means for UK local web design
You don't need to be a developer to use this. If you're hiring someone, ask them three questions:
- What's your target LCP on throttled Slow 3G?
- What format are images served in?
- Are you using a global edge runtime, or a single-region origin?
If they don't have an answer to all three, they're building a site for a desktop reviewer, not a customer in a loft. That's the difference between commodity web design and local web design for tradespeople that actually generates the call.
If you'd rather skip the audit and have us build the thing, our £99 + £49/month plan ships every site with this performance budget baked in. See how the 72-hour build works or read the pillar guide to UK local web design for the long version.