Case study · Landscaping
A 23-second mobile load on an ageing WordPress site. We locked the “before”, rebuilt it to our full standard — and it's live.
Perth, WAWebsite rebuild & performanceLive · ongoing
The situation
Perth Landscaping Experts is an established landscaping business whose website had quietly become a liability. On mobile, the largest content took 23.3 seconds to paint — nine times Google's “poor” threshold. Desktop layout shift was in the red too. Organic traffic was falling as well — sessions down from 37,000 to 17,100 year-on-year and conversions from 961 to 441, both about 54% — but that slide had started almost a year before the rebuild and has a different cause, which we come back to below.
What was at stake
A 23-second mobile load means almost nobody waits — they're gone before the page appears. Whatever traffic the site still won was landing on a page most phones gave up on, and an ageing WordPress install with no active programme behind it only gets slower and harder to change. The speed had to be fixed before anything else could be measured fairly.
What we did
Before touching anything, we captured the full old-site baseline — Lighthouse, Core Web Vitals and a year of analytics — and froze it to evidence. That's how every Salty case study works: we prove the “after” against a real “before”, not a vibe.
This build is our reference implementation of the Salty website standard — Next.js served from Cloudflare's edge, AVIF imagery, a clean component system and Core Web Vitals engineered in from the start. Our comparable landscaping build on the same standard runs 94 on mobile and 99 on desktop, with a sub-one-second desktop paint.
Not just fast — complete. Analytics and consent, session heatmaps, structured data, security headers, sitemaps, an AI-crawler policy, a conversion-focused copy layer and accessibility baked in. The things most rebuilds skip, we ship as standard on every site.
The proof
| Metric | Before | After | Change |
|---|---|---|---|
| Largest Contentful Paint — mobile | 23.3s | 3.3s | 7× faster |
| Performance — desktop | 64 | 98 | +34 |
| Performance — mobile | 67 | 92 | +25 |
| Cumulative Layout Shift — desktop | 0.263 | 0 | eliminated |
| Largest Contentful Paint — desktop | 4.1s | 0.8s | −3.3s |
Before = the old WordPress site, frozen the morning of cutover (2026-07-15). After = the live Next.js site later the same day (PageSpeed Insights, 2026-07-16), after a same-day performance pass — image budgets, responsive image rungs and hero preloading — took the day-0 reading from a volatile 4.2s to a stable 3.3s across consecutive runs. Organic traffic isn't in this table: its decline began almost a year before the rebuild, and the rebuild was never the fix for it.
The result
The rebuild is live: a 23-second mobile load is now about three, desktop paints in under a second, the layout no longer shifts, and every old URL was kept, so no page was lost in the move. What it did not do is turn the traffic around, and we won't pretend it did. Search Console shows the decline set in from August 2025, almost a year before the cutover, and that the site's average position improved while its impressions fell — the pattern of Google showing a site for fewer searches, not of a slow site losing its rankings. That calls for content and search work, not a rebuild. The rebuild made the site fast and measurable, and that's the floor the rest stands on.
What this means for you
Speed is the floor, not the finish. A proper rebuild means capturing where you started, engineering the performance in, and shipping every standard — measurement, schema, conversion, accessibility — so the site earns from day one and improves provably from there. We treat the “before” as sacred, because it's what makes the “after” mean something.
More proof
Book a 30-minute audit. We'll capture your real numbers today — and show you exactly what a rebuild would change.