For a long time, I assumed that high Lighthouse scores were mostly the result of tuning. Compressing images, deferring scripts, fixing layout shifts, adjusting themes, swapping plugins, and repeating the cycle every time a new warning appeared. Over time, that assumption stopped matching what I was seeing in practice. The sites that consistently scored well were not the ones with the most optimization effort. They were the ones where the browser simply had less work to do. At that point, Lighthouse stopped feeling like an optimization tool and started feeling like a diagnostic signal for architectural choices. What Lighthouse Actually Measures What Lighthouse Actually Measures Lighthouse does not evaluate frameworks or tools. It evaluates outcomes. How quickly meaningful content appears. How much JavaScript blocks the main thread. How stable the layout remains during load. How accessible and crawlable the document structure is. These outcomes are downstream effects of decisions made much earlier in the stack. In particular, they reflect how much computation is deferred to the browser at runtime. When a page depends on a large client-side bundle to become usable, poor scores are not surprising. When a page is mostly static HTML with limited client-side logic, performance becomes far more predictable. JavaScript as the Primary Source of Variance JavaScript as the Primary Source of Variance Across audits I have run and projects I have worked on, JavaScript execution is the most common source of Lighthouse regressions. This is not because the code is low quality. It is because JavaScript competes for a single-threaded execution environment during page load. Framework runtimes, hydration logic, dependency graphs, and state initialization all consume time before the page becomes interactive. Even small interactive features often require disproportionately large bundles. hydration logic Architectures that assume JavaScript by default require ongoing effort to keep performance under control. Architectures that treat JavaScript as an explicit opt-in tend to produce more stable results. Static Output Reduces Uncertainty Static Output Reduces Uncertainty Pre-rendered output removes several variables from the performance equation. There is no server-side rendering cost at request time. There is no client-side bootstrap required for content to appear. The browser receives predictable, complete HTML. From Lighthouse’s perspective, this improves metrics such as TTFB, LCP, and CLS without requiring targeted optimization work. Static generation does not guarantee perfect scores, but it significantly narrows the range of failure modes. Static generation A Case Study A Case Study Before rebuilding my personal blog, I explored several common approaches, including React-based setups that rely on hydration by default. They were flexible and capable, but performance required continuous attention. Each new feature introduced questions about rendering mode, data fetching, and bundle size. React-based setups Out of curiosity, I tried a different approach that assumed static HTML first and treated JavaScript as an exception. I chose Astro for this experiment, because its default constraints aligned with the questions I wanted to test. What stood out was not a dramatic initial score, but how little effort was required to maintain performance over time. Publishing new content did not introduce regressions. Small interactive elements did not cascade into unrelated warnings. The baseline was simply harder to erode. I documented the build process and architectural trade-offs in a separate technical note while working through this experiment on a personal blog with perfect Lighthouse score. Trade-offs Matter Trade-offs Matter This approach is not universally better. Static-first architectures are not ideal for highly dynamic, stateful applications. They can complicate scenarios that rely heavily on authenticated user data, real-time updates, or complex client-side state management. Frameworks that assume client-side rendering offer more flexibility in those cases, at the cost of higher runtime complexity. The point is not that one approach is superior, but that the trade-offs are reflected directly in Lighthouse metrics. Why Lighthouse Scores Tend to Be Stable or Fragile Why Lighthouse Scores Tend to Be Stable or Fragile What Lighthouse surfaces is not effort, but entropy. Systems that rely on runtime computation accumulate complexity as features are added. Systems that do more work at build time constrain that complexity by default. That difference explains why some sites require constant performance work while others remain stable with minimal intervention. Closing Thoughts Closing Thoughts High Lighthouse scores are rarely the result of aggressive optimization passes. They usually emerge naturally from architectures that minimize what the browser must do on first load. Tools come and go, but the underlying principle remains the same. When performance is a default constraint rather than a goal, Lighthouse stops being something you chase and becomes something you observe. That shift is less about choosing the right framework and more about choosing where complexity is allowed to exist.
