76
Google performance score
Slow first paint, heavy main thread
Case Study · Irrigation The old site wasn't heavy.
The old site wasn't heavy.
It was busy.
Same words. Same photos. Same phone number. We didn't strip anything out — we just stopped the site from fetching twenty scripts off four other people's servers before a single word could show up.
The starting line
Green scores, quietly bleeding speed.
The old WordPress site loaded a tag manager, a widget host, a font service, and an accounts endpoint — every one a DNS lookup and a round trip standing between the visitor and the headline.
20
External scripts before first paint
Loaded off other people's servers
4
Third-party origins
Four handshakes before "hello"
The signature move
The HTML was never the problem.
The obvious story is "the old site was bloated and we made it smaller." That story's false — the new homepage is actually 1,400 bytes larger. It was slow because of what it fetched. So we killed the waterfall.
Before · WordPress3.2s to first paint
20 external scripts · 4 third-party origins
After · BDX build0.3s to first paint
0 external scripts · 0 third-party origins · 133 KB critical path
Fonts self-hosted. CSS inlined. 1,015 bytes of JavaScript, inline. Nothing to fetch means nothing to wait for.
Core Web Vitals
What a visitor actually waits for.
Lab metrics, emulated desktop, custom throttling — measured minutes apart on the same content.
MetricBeforeAfterChange
First Contentful Paint 1.6 s 0.3 s −81%
Largest Contentful Paint 2.5 s 0.5 s −80%
Speed Index 2.0 s 0.4 s −80%
Total Blocking Time 120 ms 0 ms −100%
Cumulative Layout Shift 0.001 0.017 both pass
Where the time went
Not a checklist — the handful of calls that produced the numbers.
◆
Static, not assembled per visitor
Astro renders every page at build time and throws the JavaScript away — 24 pages of pre-built HTML on Cloudflare's edge. No database query, no plugin chain between a click and the page.
◆
The font bill, paid down
The old site pulled Acumin from Adobe Typekit — a render-blocking third-party request on every page. Replaced with Archivo, self-hosted, pinned to one width axis: 188 KB → 68 KB, served from the same origin as the HTML.
◆
Images treated as a budget
Source photography came in at 38.3 MB — one sprinkler photo alone was 4.1 MB. Re-encoded through Astro's pipeline into responsive AVIF/WebP: a phone now pulls a 113 KB hero instead of a 677 KB one.
◆
Rankings kept alive
Google had 11 URLs indexed against the old site. Every one 301s to its new home — verified 11/11 — so the accumulated ranking equity carried across instead of 404-ing.
Astro staticCloudflare edgeSelf-hosted ArchivoInlined critical CSSResponsive AVIF/WebP301 redirect map
The numbers
Same content. A very different score.
100Performance
96Accessibility
100SEO
100Best Practices
Google Lighthouse 13.4.0 — emulated desktop
76→100 Performance score — and every category green, on the same words and photos the old site already had.
Your site is probably fetching things it shouldn't.
We'll pull it apart on a free strategy call and show you exactly what's costing you customers.