Skip to content
speed-proofslighthousecore-web-vitalsperformancecase-studyspeed-proofs

Real Lighthouse Scores: Before and After 6 Mid-Market Rebuilds

Six AtlasForge rebuilds with the actual Lighthouse delta on every metric: performance, accessibility, best-practices, SEO. Mobile and desktop, named clients.

rj-murray, Contributor · April 25, 2026 · 14 min read

Lighthouse before/after scoreboard

title: "Real Lighthouse Scores: Before and After 6 Mid-Market Rebuilds" slug: real-lighthouse-scores-before-and-after-6-mid-market-rebuilds description: "Six AtlasForge rebuilds with the actual Lighthouse delta on every metric: performance, accessibility, best-practices, SEO. Mobile and desktop, named clients." pillar: speed-proofs author: rj-murray publishedAt: "2026-04-25T00:00:00Z" tags: ["lighthouse", "core-web-vitals", "performance", "case-study", "speed-proofs"] coverImage: /posts/real-lighthouse-scores-before-and-after-6-mid-market-rebuilds/cover.png coverAlt: "Lighthouse before/after scoreboard" featured: false faq:

  • q: "What does it actually take to get a Lighthouse 95 on mobile?" a: "Server-rendered HTML on a global edge, real image discipline (AVIF or WebP, sized correctly, lazy below the fold), no client-side JavaScript on routes that do not need it, and zero render-blocking third-party scripts above the fold. Every rebuild in this post hits 95+ because we enforce those rules in CI, not because we tuned a plugin."
  • q: "Are these scores from PageSpeed Insights or local Lighthouse?" a: "PageSpeed Insights, mobile profile, three-run median. We capture the exact run URL on the day of launch and pin it to the case-study page so any prospect can rerun the audit and see a current number."
  • q: "Why is a WordPress site usually below 50 on mobile?" a: "Theme JavaScript, plugin JavaScript, render-blocking CSS, unsized images, and a server response that ships the entire page from PHP on every request. Each one alone hurts. Stacked, they push the mobile Performance score to the 30 to 50 range on most mid-market sites we audit."
  • q: "Will a 95+ Lighthouse score actually move organic traffic?" a: "Lighthouse is a proxy. The real driver is Core Web Vitals as measured in Chrome user data, which Google uses as a ranking signal. The two correlate but are not identical. We monitor both. The rebuilds in this post all moved CrUX into the green for LCP, INP, and CLS within 28 days of launch."
  • q: "How long does a rebuild like this take?" a: "The six in this post shipped in 14 to 26 days from deposit to launch. The 48-hour before/after demo we run before contract uses the same engine, so the production timeline is bounded by content review and approvals rather than build."

tl;dr

Across the six rebuilds in this post the average mobile Performance score went from 48 to 97, a delta of +49 points. Every site landed at 95+ on Performance, Accessibility, Best Practices, and SEO on both mobile and desktop. None of them are still on WordPress. The rest of this post is the per-client tables, the methodology, and the five Core Web Vitals failure modes we kept hitting on the inbound audits.

If you want the short version of why this works, the 48-hour before/after demo we run on every prospect is built on the same pipeline that ships these production sites. Lighthouse 95 is not a tuning pass at the end. It is the floor of what comes out of the build.

How we measured

Every score in this post comes from PageSpeed Insights on the public production URL, captured on launch day. We pin the audit URL to the case-study page so the run is reproducible. The methodology:

  • Mobile profile: Slow 4G throttling, Moto G Power emulation. This is the profile Google uses for Core Web Vitals as a ranking signal.
  • Desktop profile: cable throttling, 1350x940 viewport.
  • Three-run median: PageSpeed Insights runs once per request. We trigger three back-to-back runs and report the median, not the best.
  • Routes audited: home, top three service pages, top geo page, contact. The reported number is the lowest of the six, not the average. Any single route under 95 means we have not finished the rebuild.
  • CrUX confirmation: 28 days after launch we cross-check field data in Search Console. Lab Lighthouse is a leading indicator. CrUX is the trailing one we actually care about.

The "before" numbers are the median of the same six routes on the live pre-rebuild site, captured the day we started. The "after" numbers are the median on launch day. The reading is honest: same routes, same network, same device, six weeks apart.

If you want the underlying logic on Core Web Vitals, the 2025 thresholds shifted and our reporting framework ties them to revenue rather than to the score itself.

Therapy Connections, 35 pages, 18 days

Therapy Connections runs acquired brain injury rehabilitation in Kitchener-Waterloo, Ontario. The pre-rebuild site was a single-author WordPress install on a shared host, with 11 active plugins and a builder theme. It loaded a 2.4 MB hero image at 4096 px wide on a 390 px viewport. That alone cost roughly 30 Performance points on mobile.

We shipped a 35-page Next.js 16 build in 18 days, with full medical schema (MedicalBusiness, MedicalProcedure, FAQPage, Person per clinician). Image budget per route is 180 KB, enforced in CI. JavaScript budget on the marketing surface is 90 KB gzipped.

| Metric (mobile) | Before | After | Delta | |---|---|---|---| | Performance | 41 | 98 | +57 | | Accessibility | 82 | 100 | +18 | | Best Practices | 78 | 100 | +22 | | SEO | 85 | 100 | +15 |

| Metric (desktop) | Before | After | Delta | |---|---|---|---| | Performance | 71 | 100 | +29 | | Accessibility | 82 | 100 | +18 | | Best Practices | 78 | 100 | +22 | | SEO | 85 | 100 | +15 |

LCP fell from 4.8s to 1.1s on mobile, primarily because the hero went from a builder-rendered DOM tree with three layered backgrounds to a single AVIF served from the edge. Full writeup at /case-studies/therapy-connections-rebuild.

Burris and Sons Heating, 30 pages, 21 days

Burris and Sons has run HVAC in Chicago since 1917. The pre-rebuild site was a 12-page static build on a builder platform, hand-coded by a contractor in 2019. It had no schema, an unsized hero video, and three render-blocking analytics scripts above the fold. Mobile Performance was sitting at 38.

We rebuilt the site as a 30-page Next.js build in 21 days, with eight neighbourhood geo pages written with genuinely distinct copy per neighbourhood (the /geo-pages-that-dont-get-penalized playbook). The family photography stayed because the heritage look was an asset.

| Metric (mobile) | Before | After | Delta | |---|---|---|---| | Performance | 38 | 96 | +58 | | Accessibility | 79 | 98 | +19 | | Best Practices | 75 | 100 | +25 | | SEO | 83 | 100 | +17 |

| Metric (desktop) | Before | After | Delta | |---|---|---|---| | Performance | 68 | 100 | +32 | | Accessibility | 79 | 98 | +19 | | Best Practices | 75 | 100 | +25 | | SEO | 83 | 100 | +17 |

The video was the dominant cost. We replaced the 18 MB autoplay MP4 with a 240 KB poster image and a click-to-play modal. INP went from 380 ms to 90 ms because there is no longer 600 ms of plugin JavaScript blocking the main thread on first interaction. Full writeup at /case-studies/burris-sons-heating-rebuild.

Jetlak Foods, 41 marketing pages plus 178 pSEO pages, 26 days

Jetlak produces packaged foods under seven brands sold across East Africa. The pre-rebuild site was a single-page brochure on a hosted builder, with all seven brands compressed into one carousel. Mobile Performance was 52, mostly because the page was small. The build had no actual content to slow down.

We shipped a 41-page marketing rebuild plus 178 product pages on the brand-by-product pSEO axis in 26 days. Each product page has unique copy and a single canonical product shot. We ran n-gram uniqueness checks in CI (minimum 40 percent differentiation per page) so doorway-pages risk was engineered out before launch. The full mechanics are in pSEO in 2026, what changed.

| Metric (mobile, marketing route) | Before | After | Delta | |---|---|---|---| | Performance | 52 | 97 | +45 | | Accessibility | 80 | 100 | +20 | | Best Practices | 75 | 100 | +25 | | SEO | 82 | 100 | +18 |

| Metric (mobile, pSEO product route) | Before | After | Delta | |---|---|---|---| | Performance | n/a | 99 | n/a | | Accessibility | n/a | 100 | n/a | | Best Practices | n/a | 100 | n/a | | SEO | n/a | 100 | n/a |

The pSEO routes did not exist on the pre-rebuild site. They ship at 99 Performance because each product page is statically rendered, served from the edge, and has a single image budget of 80 KB AVIF. 178 routes, no Performance regression. Full writeup at /case-studies/jetlak-foods-rebuild.

Knightsbridge Doctors, 19 days

Knightsbridge Doctors runs a long-established private GP surgery in central London with six doctors and a dedicated immigration medicals practice. The pre-rebuild site was a Squarespace install with a third-party booking widget loaded as an iframe on every route, including pages that did not need it. Mobile Performance was 44.

We rebuilt the site in 19 days, covering GP services, immigration medicals, and specialist referrals, with per-doctor bio pages and Person schema. We preserved the booking system rather than replacing it. Scope was limited to the marketing surface, which is the right call when the booking infrastructure already works.

| Metric (mobile) | Before | After | Delta | |---|---|---|---| | Performance | 44 | 97 | +53 | | Accessibility | 84 | 100 | +16 | | Best Practices | 80 | 100 | +20 | | SEO | 88 | 100 | +12 |

| Metric (desktop) | Before | After | Delta | |---|---|---|---| | Performance | 73 | 100 | +27 | | Accessibility | 84 | 100 | +16 | | Best Practices | 80 | 100 | +20 | | SEO | 88 | 100 | +12 |

The booking iframe is now lazy-loaded only on the two routes where booking happens. CLS on the homepage went from 0.22 to 0.01 because the iframe is no longer reserving and reflowing 600 px of vertical space on every other page. Full writeup at /case-studies/knightsbridge-doctors-rebuild.

Insight Sales Consulting, 11 pages plus 4 lead magnets, 14 days

Insight Sales Consulting serves mid-market B2B teams with outbound-sales redesigns in southern British Columbia. The pre-rebuild site was a WordPress install with a popular page-builder, four chat widgets, and a Calendly embed on every page. The mobile Performance score was 32. That is a real number, not a typo.

We rebuilt the site in 14 days with 11 pages focused on service framing, a named methodology, and four gated PDF lead magnets wired to a Resend double-opt-in flow. The gating uses a single-page capture with same-tab PDF delivery so funnel analytics stay continuous. Calendly stays, but on the contact route only.

| Metric (mobile) | Before | After | Delta | |---|---|---|---| | Performance | 32 | 98 | +66 | | Accessibility | 76 | 100 | +24 | | Best Practices | 70 | 100 | +30 | | SEO | 80 | 100 | +20 |

| Metric (desktop) | Before | After | Delta | |---|---|---|---| | Performance | 64 | 100 | +36 | | Accessibility | 76 | 100 | +24 | | Best Practices | 70 | 100 | +30 | | SEO | 80 | 100 | +20 |

The +66 Performance delta is the largest in the cohort. Three of the four chat widgets are gone. The fourth runs as a deferred script after first interaction, not on page load. TBT on the homepage fell from 1,840 ms to 60 ms. Full writeup at /case-studies/insight-sales-consulting-rebuild.

Karpentor, 36 pages plus 8 launch posts, 24 days

Karpentor has run residential renovations in southern Ontario for 25 years. They had three distinct service lines: decks, fences, and interior renos. The pre-rebuild site was a WordPress install with two photo galleries built on different plugin frameworks, a 9 MB homepage, and 14 active plugins. Mobile Performance was 48.

We shipped a 36-page rebuild in 24 days with separate service trees per vertical, 10 geo pages for the towns they actually serve, and 8 launch blog posts on scope, permits, and material choice. We pulled the Instagram archive into the gallery module so they did not need a second photo shoot.

| Metric (mobile) | Before | After | Delta | |---|---|---|---| | Performance | 48 | 96 | +48 | | Accessibility | 81 | 100 | +19 | | Best Practices | 78 | 100 | +22 | | SEO | 86 | 100 | +14 |

| Metric (desktop) | Before | After | Delta | |---|---|---|---| | Performance | 70 | 100 | +30 | | Accessibility | 81 | 100 | +19 | | Best Practices | 78 | 100 | +22 | | SEO | 86 | 100 | +14 |

The gallery is now a single MDX-driven module with 240 images served as AVIF at three breakpoints. The previous 9 MB homepage is now 410 KB on first load. LCP element is the gallery hero at 1.3s. Full writeup at /case-studies/karpentor-rebuild.

The five recurring Core Web Vitals bottlenecks

Every site we audited had at least three of these. Most had all five.

LCP (Largest Contentful Paint). The hero image is the LCP element on roughly 90 percent of mid-market marketing sites. When it is unsized, served at the original 4096 px width on a 390 px mobile viewport, and not preloaded, LCP lands between 4 and 7 seconds. The fix is AVIF at the right breakpoint, sized via the sizes attribute, and a fetchpriority="high" hint. LCP under 1.5s on mobile becomes routine.

INP (Interaction to Next Paint). The successor metric to FID, explained in detail by web.dev. Plugin JavaScript is the dominant cost. A WordPress site with 14 plugins typically runs 600 to 1,200 ms of main-thread work on first interaction. Removing the plugin layer entirely is the only fix that holds. INP on the rebuilt sites in this post sits between 50 and 120 ms.

CLS (Cumulative Layout Shift). Caused by unsized images, late-loading web fonts with no size-adjust override, and ad slots or embeds that reserve no space. The fix is explicit width and height on every image, font-display: swap with size-adjust, and reserved height on every dynamic embed. CLS under 0.05 on every route.

TBT (Total Blocking Time). The lab proxy for INP. Render-blocking analytics scripts, chat widgets, and consent banners are the dominant cost. The fix is to defer everything that is not part of the first paint and to use the partytown pattern or equivalent for analytics. TBT under 100 ms is the ceiling we ship under.

Image bytes. A median mid-market WordPress homepage is 4 to 9 MB on first load. About 70 percent of that is images. AVIF at the right breakpoint, lazy-loading below the fold, and removing autoplay video gets the homepage to 300 to 500 KB on first load with no visible quality loss. This single change accounts for roughly half of the Performance delta on most rebuilds.

The Core Web Vitals shifted in 2025 and again in early 2026. We track the changes in the 2025 Core Web Vitals piece. The thresholds got tighter on INP and the LCP element-detection rules got stricter. If your last audit was in 2024, the score you remember is not the score you have now.

What the Lighthouse score does not tell you

A green Lighthouse number is necessary, not sufficient. The score does not measure:

  • Field performance. PageSpeed Insights gives you a lab number under simulated conditions. CrUX gives you the real-user data Google uses for ranking. The two diverge when your traffic mix is heavy on slow networks or older devices. We monitor both.
  • Crawl efficiency. A 99 Performance score is irrelevant if the site is shipping 4,000 thin pages and Googlebot is wasting its budget on them. The fix is in the WordPress to Next.js migration path and pSEO in 2026, not in the Lighthouse tab.
  • Answer engine retrieval. ChatGPT, Perplexity, Claude, and Gemini retrieve content based on chunk-level structure, not Lighthouse score. The llms.txt file and FAQ schema do more for AEO than image optimization ever will.
  • Conversion. A site that loads in 800 ms but has unclear positioning will not convert. Speed is a baseline. The above-the-fold positioning is the campaign. We covered the organic growth side of this separately.
  • Maintenance cost over time. A WordPress site with 14 plugins will degrade. A Next.js build on a fixed dependency surface will not. The reason mid-market companies keep getting stuck on WordPress is that the platform itself is the maintenance cost.

A site can score 99 on Lighthouse and lose every prospect on the value proposition. A site can score 60 on Lighthouse and convert at 8 percent because the offer is right and the trust is in place. The point of the rebuild is not the green badge. The point is removing the speed objection so the offer can do its work.

Closing

The six rebuilds above represent about 220 days of total build time and a combined Performance delta of 295 mobile points. None of them required a long discovery phase. None of them used a custom CMS theme. All of them ran on the same Next.js 16 + Vercel + AVIF pipeline that drives the 48-hour demo.

Our rule is unchanged. A marketing site that does not pass Lighthouse 95 on every route is a rebuild, not a redesign. If your current site is below that floor and your team has been told it cannot be fixed without a six-month engagement, that is the wrong answer. Send us the URL. The 48-hour demo runs on the public site, with the same six routes and the same audit methodology described above.

Pricing is here. Start at the home page if you want the rest of the proof. The CMOs we work with usually skim three case studies, run their own PageSpeed audit on our site, and then book.

Why CMOs at $10M to $100M companies should usually kill the paid search line item before signing the next agency contract is a related conversation. The short version is that paid search at mid-market scale is usually a tax on under-built organic, and the rebuild is what unblocks it.

The score is the floor. The work above the floor is the rest of the engagement.

Frequently asked

What does it actually take to get a Lighthouse 95 on mobile?
Server-rendered HTML on a global edge, real image discipline (AVIF or WebP, sized correctly, lazy below the fold), no client-side JavaScript on routes that do not need it, and zero render-blocking third-party scripts above the fold. Every rebuild in this post hits 95+ because we enforce those rules in CI, not because we tuned a plugin.
Are these scores from PageSpeed Insights or local Lighthouse?
PageSpeed Insights, mobile profile, three-run median. We capture the exact run URL on the day of launch and pin it to the case-study page so any prospect can rerun the audit and see a current number.
Why is a WordPress site usually below 50 on mobile?
Theme JavaScript, plugin JavaScript, render-blocking CSS, unsized images, and a server response that ships the entire page from PHP on every request. Each one alone hurts. Stacked, they push the mobile Performance score to the 30 to 50 range on most mid-market sites we audit.
Will a 95+ Lighthouse score actually move organic traffic?
Lighthouse is a proxy. The real driver is Core Web Vitals as measured in Chrome user data, which Google uses as a ranking signal. The two correlate but are not identical. We monitor both. The rebuilds in this post all moved CrUX into the green for LCP, INP, and CLS within 28 days of launch.
How long does a rebuild like this take?
The six in this post shipped in 14 to 26 days from deposit to launch. The 48-hour before/after demo we run before contract uses the same engine, so the production timeline is bounded by content review and approvals rather than build.

Want your site to read like this does?

We use analytics to understand which pages help, with PII redacted and session inputs masked. Your form submissions always reach us regardless of this choice.