Achieving 100/100 Mobile Lighthouse with Astro's Zero-JS Approach

Kent Weyers demonstrates a three-step process using Astro to hit perfect mobile Lighthouse scores. His method prioritizes static HTML, inlined CSS, and deferred third-party scripts for peak performance.

Developer Kent Weyers reports achieving a 100/100 mobile Lighthouse performance score for marketing sites, including zivaro.co.za, which registers 0ms Total Blocking Time on a throttled Moto G Power profile. This performance, he claims, significantly outpaces typical agency marketing sites, which often score in the 50s to 70s. Weyers attributes these results not to complex optimizations, but to a disciplined, three-step reduction of client-side JavaScript, emphasizing architectural choices over post-load tweaks.

Defaulting to Zero JavaScript with Astro

Weyers' primary tactic involves building sites with Astro, a framework designed to ship zero JavaScript by default. Astro renders components to static HTML at build time, requiring explicit opt-in for client-side JavaScript. For his marketing sites, Weyers avoids framework islands entirely. The only client-side scripts are small, inline vanilla JavaScript functions for basic interactivity like mobile menu toggles or consent banners. This approach eliminates the hydration step common in single-page applications, which often blocks the main thread during page load. The core principle, as Weyers states, is that "HTML is free, JavaScript is not." This choice alone accounts for a substantial portion of the reported Lighthouse score.

Inlining CSS to Eliminate Render-Blocking Requests

The second step addresses render-blocking requests caused by external stylesheets. Weyers configures Astro to inline all page CSS directly into the HTML document. This is achieved by setting inlineStylesheets: 'always' within the build object in astro.config.mjs. This consolidates the HTML and CSS into a single request, allowing the browser to paint the page as soon as the HTML arrives. On slow connections, this prevents a visible delay. For typical marketing sites with small CSS payloads, this trade-off of a slightly larger initial HTML document for a faster first paint is deemed overwhelmingly beneficial.

Deferring Third-Party Scripts Until Interaction

To minimize Total Blocking Time, Weyers defers the loading and execution of all third-party scripts. This includes common culprits such as Google Tag Manager, analytics platforms, and marketing pixels. Instead of firing these scripts on page load or when the browser is idle, they are triggered only upon the user's first real interaction with the page. Since Lighthouse tests typically run without user interaction, this strategy prevents these scripts from blocking the main thread during the initial load, directly improving the Total Blocking Time metric. This decision, Weyers claims, is where most sites "quietly lose" their performance battle.

What We'd Change

Weyers' approach is effective for specific types of marketing sites. However, its direct applicability diminishes for sites requiring significant client-side interactivity or complex integrations. A purely static Astro site with minimal JavaScript sacrifices dynamic user experiences common in modern web applications, such as real-time search, interactive data visualizations, or complex form validation without a full page reload. While the "island" architecture of Astro allows for selective client-side JavaScript, the discipline required to maintain a near-zero JavaScript footprint becomes a development constraint for feature-rich applications.

The strategy of deferring third-party scripts until the first interaction, while beneficial for Lighthouse scores, carries implications for data collection. Analytics and marketing pixels triggered only on interaction will miss users who visit a page but do not interact, leading to incomplete data sets for bounce rates, initial page views, and overall traffic measurement. This trade-off prioritizes performance metrics over comprehensive user behavior tracking, a decision that may not align with all marketing or business intelligence objectives. For sites heavily reliant on early-stage user tracking or A/B testing, a more nuanced approach to script loading (e.g., preloading critical scripts with rel="preload" or using web workers) might be necessary, even if it slightly impacts Lighthouse scores.

Kent Weyers' methodology demonstrates that achieving peak mobile Lighthouse scores is less about advanced optimization techniques and more about fundamental architectural choices that prioritize minimal client-side payload. His Astro-centric playbook, focused on static HTML, inlined CSS, and deferred third-party scripts, offers a clear path for marketing sites where initial load performance is paramount. This approach underscores a return to core web principles: every byte of JavaScript incurs a cost, particularly on mobile, and the most performant code is often the code that is never shipped.

The investor read

This signal highlights a growing market segment prioritizing raw performance and developer experience in static site generation, particularly for marketing and content-heavy sites. The emphasis on Astro reflects its traction as a modern alternative to heavier frameworks like Next.js or Gatsby for use cases where hydration is unnecessary. Investors should note the increasing demand for tools that enable "zero-JS by default" architectures, as businesses seek to improve core web vitals and reduce operational overhead. This trend points to potential investment opportunities in build tools, hosting platforms, and component libraries that natively support performant, static-first approaches. The trade-off between performance and comprehensive analytics also signals a potential market for privacy-preserving or highly optimized analytics solutions that minimize client-side impact.

Pull quote: “The core principle, as Weyers states, is that "HTML is free, JavaScript is not."”