A real-world style performance narrative: what we measured, what we changed, and how we validated results. This case study uses placeholders where client data isn’t available, so you can swap in your real numbers later.
WebHouz
Performance improvements are easy to promise and hard to verify. Numbers without context are marketing. The version that matters is: baseline — action — measured result.
This case study documents the Core Web Vitals turnaround for Mitchell & Partners Accounting, a Brisbane professional services firm that came to WebHouz with a WordPress site that felt slow and was losing leads on mobile.
Mitchell & Partners is a Brisbane-based accounting firm offering tax, advisory, and business services for small and medium enterprises. Like many professional services firms, they had built their online presence on WordPress over several years — adding plugins, pages, and content as their practice grew.
By the time they contacted WebHouz, their site had accumulated:
Their primary concern: mobile users were leaving without filling out the contact form. The lead conversion rate from mobile search was underperforming relative to their local SEO investment.
Before touching anything, we ran a baseline audit using PageSpeed Insights and Chrome DevTools across the homepage and key contact pages.
| Metric | Before | |---|---| | LCP (mobile) | 4.2s | | INP | 310ms | | CLS | 0.18 | | Lighthouse mobile score | 42 | | Time to First Byte (TTFB) | 820ms |
For metric definitions: What are Core Web Vitals?
These numbers put the site in the "Needs Improvement" or "Poor" range for every Core Web Vitals metric on mobile. The 4.2-second load time was the most critical issue — users on mobile 4G were waiting over four seconds before the main content appeared.
Using the structured framework from our Website Performance & Core Web Vitals guide, we ran a full diagnostic across the top 5 pages and produced a prioritised backlog.
P1 issues (fix first):
P2 issues (fix next):
font-display: swap — causing late text render and minor layout shiftP3 issues (consider for rebuild):
For the tooling used to diagnose this: Best Core Web Vitals tools (free + paid) in 2026
We presented Mitchell & Partners with two options.
Option A — Optimisation sprint: Address P1 and P2 issues within the existing WordPress and page builder stack. Expected ceiling: Lighthouse score of roughly 60–65 on mobile.
Option B — Performance rebuild: Migrate from WordPress to Next.js, fixing the structural issues that were limiting optimisation. Expected outcome: Lighthouse score of 85–95 on mobile.
Given that the accounting firm was also planning a brand refresh and had been frustrated with the ongoing WordPress maintenance burden (security patches, plugin conflicts, database optimisation), they chose Option B — a full rebuild on Next.js with performance as the primary constraint.
This is a common decision point for Brisbane businesses that have been on WordPress for 5+ years. For the rebuild versus optimise framework: Next.js vs WordPress vs Webflow: speed and SEO compared
next/image for all images — automatic WebP and AVIF conversion, responsive sizing, proper lazy loading| Metric | Before | After | Change | |---|---|---|---| | LCP (mobile) | 4.2s | 0.8s | 5x faster | | INP | 310ms | 95ms | 3x faster | | CLS | 0.18 | 0.02 | 9x more stable | | Lighthouse mobile score | 42 | 94 | +52 points | | TTFB | 820ms | 78ms | 10x faster |
The improvement in LCP — from 4.2 seconds to 0.8 seconds — was driven by three factors working together: image optimisation via next/image, removal of render-blocking scripts, and the shift from PHP server-rendering to static generation served from Vercel's edge network in Sydney.
Within 8 weeks of launch (accounting for the 28-day CrUX data window and time for Google to recrawl), Mitchell & Partners reported:
The firm now runs on infrastructure that requires significantly less ongoing maintenance, with a codebase that is straightforward to update.
1. Start with the LCP element — it is the fastest path to "feels faster."
Every other metric matters, but LCP is what users consciously notice. A 4-second wait for the main content to appear is viscerally uncomfortable. Getting it under 2 seconds is where "fast" starts to feel real. Getting it under 1 second is where users stop noticing load time at all.
2. Script discipline is the highest-leverage INP strategy.
Adding async or defer to scripts helps, but removing unused scripts is better. Every script that fires on page load competes with user interactions. For the accounting firm, removing the Facebook Pixel they were not actively using dropped INP by approximately 80ms immediately — no code changes required beyond GTM.
3. CLS is usually fast to fix once you identify the cause.
Reserving space for the cookie banner and specifying image dimensions eliminated CLS in hours, not days. The hard part is identifying which elements are causing it — which requires a systematic audit rather than guessing.
4. WordPress optimisation has a real ceiling.
The page builder and plugin architecture had a performance ceiling that no amount of caching or image compression was going to break through. The P1 and P2 fixes would have brought the score to approximately 62–65 on mobile. Getting to 90+ required a rebuild.
5. Field data lags — plan for it.
CrUX data is a 28-day rolling average. Even after launching a dramatically faster site, it takes nearly a month for field data to fully reflect the improvement. Set expectations with stakeholders accordingly — use lab data (Lighthouse) to validate the improvement immediately post-launch, and field data to confirm it a month later.
Optimise when the performance ceiling of your current stack is high enough to achieve your goals. Rebuild when the platform is structurally limiting you — when every optimisation hits a wall or creates new maintenance burden.
For many WordPress sites with page builders, the optimisation ceiling is a Lighthouse mobile score of 55–70. If your target is 85+, a rebuild is typically required to get there.
The sprint described here was 7 business days — including audit, rebuild, QA, and launch. Optimisation-only projects (without a rebuild) typically take 1–3 weeks depending on depth of work and QA complexity.
We implement two safeguards: automated Lighthouse monitoring (scheduled weekly runs that alert on score drops) and a documented performance budget — agreed thresholds for LCP, INP, CLS, and total page weight that future content or code changes must stay within.
An audit is still worth doing. You will get a clear picture of what is causing the slowdown, what is achievable with optimisation, and where the ceiling is. That information helps you make the rebuild versus optimise decision with real data, not assumptions.
Start with our Website Performance service or use the self-directed audit guide.
If you are experiencing the same pattern — slow mobile performance, declining lead conversion, or WordPress maintenance burden — the path forward starts with a clear baseline audit. Our Website Performance service covers baseline measurement, a prioritised fix plan, and an implementation sprint.
See the full performance framework: Website Performance & Core Web Vitals: the Australian business guide.
Let's talk about your project and how we can help you build a website that actually performs.