Skip to content
AscendQ.ca — Websites, Apps & SEO Systems
Start Project

Performance 10 min read

Why Your Lighthouse Score Is Stuck (and the Site Architecture That Fixes It)

Lighthouse Performance: 54
Total Blocking Time: 2,140 ms
Largest Contentful Paint: 5.8 s
"Reduce unused JavaScript — potential savings of 1,240 KiB"

There is a specific kind of frustration in running Lighthouse after a weekend of optimizing and watching the score move from 58 to 61. The images are WebP, the caching plugin is on, you minified everything the tutorials told you to minify — and the report still leads with "Reduce unused JavaScript" like you did nothing. Here is the uncomfortable truth most optimization guides skip: past a certain point, your score is not capped by your settings. It is capped by your architecture.

We test local business websites continuously with Google's PageSpeed API for our public Website Performance Index, so we see this pattern across hundreds of real sites, not hand-picked examples. The sites stuck in the 40s–60s are overwhelmingly built the same way — and the sites at 95–100 are built a fundamentally different way. This post explains the difference, how to tell which side you are on, and what a rebuild actually changes.

You're In The Right Place If…

  • Performance score plateaus in the 40s–60s on mobile no matter what you optimize
  • "Reduce unused JavaScript", "Eliminate render-blocking resources", and "Minimize main-thread work" top every report
  • Total Blocking Time stays above 1,000 ms even after image and caching fixes
  • Every optimization plugin you add moves the score a point or two, then it drifts back
  • Desktop looks acceptable but mobile is dramatically worse

The Ceiling: Why Tuning Stops Working

Lighthouse's Performance score is dominated by what happens on the browser's main thread before the page is usable. Largest Contentful Paint measures how long until the main content renders; Total Blocking Time measures how long scripts lock up the page; Cumulative Layout Shift measures how much things jump around. Image compression and caching improve the download side of that story — but they do nothing about the execution side.

If your site ships a JavaScript framework, a page builder runtime, a theme's script bundle, three plugin bundles, and a tag manager, the browser must download, parse, compile, and execute all of it before the page settles. On a mid-range phone, that is seconds of main-thread work — and no image format changes it. That is the ceiling: you cannot tune your way out of work the architecture forces the browser to do.

How To Tell If You've Hit The Architecture Ceiling

Open your Lighthouse report and look at the diagnostics, not just the score. The architecture ceiling has a recognizable signature.

  • Total Blocking Time over ~600 ms that survives every plugin-level fix
  • "Reduce unused JavaScript" reporting hundreds of KiB from your theme, builder, or framework bundles — code you cannot remove without removing the platform
  • "Minimize main-thread work" showing multiple seconds, mostly Script Evaluation
  • Mobile scoring 25–40 points below desktop (weaker CPUs expose execution cost)
  • The waterfall shows a long chain: HTML → CSS → framework JS → app JS → content appears

What The 95–100 Sites Do Differently

The sites that score 95–100 in our Performance Index share one property: the server sends finished HTML. The browser receives content it can paint immediately — no framework boot, no client-side rendering, no builder runtime. This is static-first architecture: pages are pre-rendered at build time (using a static site generator such as Astro, Hugo, or Eleventy), CSS is purged to only what each page uses, and JavaScript is reduced to small, optional islands — a menu toggle, a form, a widget — instead of an application the whole page depends on.

On this foundation, the optimizations that were fighting the ceiling suddenly compound: fonts preload, images are sized and lazy-loaded, third-party scripts are deferred, headers cache aggressively — and there is no multi-second JavaScript tax underneath undoing the gains. This site is built exactly this way, scores 100/100, and still runs analytics, custom fonts, live data, and lead-capture forms. The architecture does not forbid functionality; it forbids paying for functionality the page is not using.

Rebuild Vs. Keep Tuning: An Honest Decision Rule

A rebuild is not always the answer, and anyone who says otherwise is selling something. Our honest rule: if you are on a heavy platform but scoring 75+, keep tuning — remove plugins, defer scripts, optimize the critical path; you have headroom. If you are stuck under ~65 on mobile with the diagnostic signature above, tuning buys single digits while a static-first rebuild typically moves the site into the 90s — because it removes the cost instead of rearranging it.

The practical middle path many businesses miss: you do not have to rebuild everything at once. The marketing site (home, services, location pages — the pages Google actually ranks) can be rebuilt static-first while a booking system or store stays on its existing platform under a subpath or subdomain. That splits the project into weeks, not months, and puts the fast architecture exactly where the SEO value is.

The Fix, Step By Step

  1. 1

    Run Lighthouse on mobile and read the diagnostics, not the score

    Use PageSpeed Insights (mobile tab). Note Total Blocking Time, "Reduce unused JavaScript" savings, and "Minimize main-thread work". These three tell you whether you have a tuning problem or an architecture problem.

  2. 2

    Exhaust the cheap wins first

    Compress and correctly size images (WebP/AVIF), lazy-load below-the-fold media, preload your fonts with font-display: swap, defer or delay analytics and tag managers, and remove plugins you do not use. Retest after each change so you know what moved.

  3. 3

    Measure your JavaScript tax

    In the report, open "Reduce unused JavaScript" and "Minimize main-thread work". If the biggest offenders are your platform's own bundles — theme, page builder, framework runtime — you have found the ceiling. No setting removes the platform's cost.

  4. 4

    If you are under ~65 mobile with a high JS tax: plan a static-first rebuild

    Pre-render pages to static HTML with a build step (Astro, Hugo, Eleventy), purge unused CSS, and ship JavaScript only as small islands where interaction genuinely needs it. Keep dynamic systems (booking, store) where they are and rebuild the marketing pages first.

  5. 5

    Lock the gains in

    Add immutable caching headers for hashed assets, keep third-party scripts deferred, and put Lighthouse in your deploy checklist so regressions are caught the day they ship — scores decay when nobody is watching.

From the trenches

How we hit this on a real production site

Our public Website Performance Index tests local business websites with Google's PageSpeed API on an ongoing basis. Across the sites tested so far, the pattern is blunt: page-builder and plugin-heavy sites cluster in the 40s–60s on mobile with multi-second Total Blocking Time, while the small group of pre-rendered, static-first sites cluster above 90 — the gap is architectural, not effort-based. Many of the low scorers have clearly been "optimized": compressed images, caching plugins, minification. The ceiling held anyway.

This site is our own proof: built static-first with Astro and a purged Tailwind build, it scores 100/100 while running analytics, custom fonts, live API-driven content, chat, and lead forms. Every client site we build ships on the same foundation — the score is a byproduct of the architecture, not an afterthought. If your site is stuck at the ceiling and you would rather skip the rebuild learning curve, that is exactly the work we do.

Frequently Asked Questions

Is a 100/100 Lighthouse score actually necessary?

No — Google's ranking systems care that Core Web Vitals pass, not that you hit 100. But sites stuck in the 50s usually fail Core Web Vitals on real devices, and the same architecture that passes them comfortably tends to land in the 90s anyway. Treat 100 as evidence of headroom, not the goal itself.

Can WordPress or a page builder ever score 90+?

Yes, with discipline: a lightweight theme, few plugins, aggressive script deferral, and good hosting — or a static export in front of it. But you are working against the platform's default cost the entire time, and every new plugin re-opens the fight. Static-first gets the same result as the default state.

Why is my mobile score so much worse than desktop?

Lighthouse's mobile test simulates a mid-range phone with throttled CPU and network. JavaScript execution cost is 4–6× higher there, so the JS tax your desktop hides becomes the dominant factor. A big desktop/mobile gap is itself a signal that script execution — architecture — is your bottleneck.

Will a rebuild hurt my existing SEO?

Done properly, no — it usually helps. Keep the same URLs (or 301 every old URL to its successor), preserve titles, content, and internal links, and resubmit your sitemap. The speed and crawlability gains typically outweigh any short-term churn within weeks.

How long does a static-first rebuild take?

For a typical business marketing site (5–25 pages), weeks — not months — especially when content is migrated rather than rewritten. Complex applications stay on their existing stack; the rebuild targets the pages that need to rank and convert.

Still stuck? Send us the exact error.

Paste the exact error message you're seeing and where it happens. We'll take a look — if it's quick we'll point you at the fix, and if it's deeper we'll tell you honestly what it takes.

Reach the Summit

Rather have someone just fix it?

This is literally what we do all day — websites, SEO, performance, and the weird errors in between.

Start the Conversation