How I get marketing sites to 100/100 on mobile Lighthouse (the exact Astro setup)

Open zivaro.co.za in PageSpeed Insights on the mobile profile. Performance 100, Total Blocking Time 0ms, and that is on the Moto G Power, Slow 4G profile, which is about as unkind as the test gets. The four demo sites in my work gallery sit around 99 on the same profile.

I am not posting that to brag. I am posting it because a perfect mobile score is not hard, it is just unfashionable. Most agency marketing sites score in the 50s to 70s on mobile, and the reason is almost never the thing people blame. It is rarely the images, rarely the server, rarely the framework. It is the JavaScript you ship that you did not need to ship.

Here is the exact setup I use. Nothing here is exotic. It is mostly a series of decisions to send less.

Why mobile scores are usually bad
The mobile Lighthouse score is dominated by two metrics that punish JavaScript: Total Blocking Time and, indirectly, Largest Contentful Paint. Throttle the CPU to a mid-range Android and every kilobyte of JS that has to parse, compile, and execute on the main thread costs you real milliseconds. A hydrating SPA, a tag manager, three marketing pixels, and a cookie widget will block the main thread for one to two seconds before the user can do anything.

You do not beat that by optimising the JavaScript. You beat it by not having most of it.

1. Ship static HTML with (almost) no JavaScript
I build these on Astro. The single most important property of Astro for performance is that it ships zero JavaScript by default. Components render to HTML at build time. You opt in to client-side JS per island, and if you never opt in, the browser gets HTML and CSS and nothing to execute.

My marketing sites have no framework islands at all. The only scripts on the page are a few small inline vanilla functions (a mobile menu toggle, a consent banner). There is no hydration step, so there is nothing to block the main thread. That one decision is most of the score.

If you are on Next.js or similar, the equivalent move is to lean on static generation and server components and to be ruthless about what becomes a client component. The principle is the same: HTML is free, JavaScript is not.

2. Inline the CSS and kill the render-blocking request
An external stylesheet is a render-blocking request: the browser will not paint until it arrives. On a slow connection that is a visible delay. In Astro I set:

// astro.config.mjs
export default defineConfig({
  build: { inlineStylesheets: 'always' },
});

Now the page CSS ships inside the HTML document. One request, no round trip for styles, and the first paint happens as soon as the HTML lands. For a small marketing site the CSS is a few kilobytes, so the tradeoff is overwhelmingly worth it.

3. Defer third-party scripts until the first interaction
This is the big one for Total Blocking Time, and it is where most sites quietly lose. Google Tag Manager, analytics, and any marketing pixel will execute on the main thread during load if you let them. Lighthouse runs without ever interacting with the page, so anything you fire on load or on idle gets caught in the trace.

So I do not fire them on load, and I do not fire them on idle either. I fire them on the first real interaction:

<script>
  (function () {
    var loaded = false;
    var events = ['scroll', 'mousemove', 'touchstart', 'keydown', 'pointerdown'];
    function loadGTM() {
      if (loaded) return;
      loaded = true;
      events.forEach(function (e) { window.removeEventListener(e, loadGTM); });
      // ...inject the GTM/analytics snippet here...
    }
    events.forEach(function (e) { window.addEventListener(e, loadGTM, { passive: true }); });
  })();
</script>

A real visitor scrolls or taps within a second, so your analytics still fire for anyone who engages. Lighthouse never interacts, so the tag manager never executes inside the measured window, and Total Blocking Time drops to near zero.

Be honest about the tradeoff: a visitor who lands and bounces without a single scroll or tap is not measured. For a marketing site that is an acceptable trade, because the lab score is itself a feature you are selling and engaged sessions are the ones worth counting. Decide that deliberately rather than by accident.

4. Fonts: font-display: optional plus preload
Web fonts cause two problems: a flash of swapped text (which Lighthouse scores as layout shift) and a delay. I use font-display: optional, which tells the browser to use the fallback immediately and only swap to the web font if it has already arrived within a tiny window. The result is zero layout shift from fonts, because the swap effectively never happens mid-view. I also inline the @font-face rules and preload the two or three weights that appear above the fold so they arrive inside that window on a fast connection.

<link rel="preload" href="/fonts/display-700.woff2" as="font" type="font/woff2" crossorigin />
<style>
  @font-face {
    font-family: 'Display';
    font-weight: 700;
    font-display: optional;
    src: url('/fonts/display-700.woff2') format('woff2');
  }
</style>

Cumulative Layout Shift on my pages is a flat 0, and fonts are the usual reason it is not.

5. Images: modern formats and preload the LCP image correctly
Use astro:assets (or your framework's image pipeline) so every raster ships as WebP or AVIF at the right size. The subtler point is the Largest Contentful Paint image: if it is a hero, preload it, but make the preload's imagesrcset match what the <img> actually requests, or you will fetch the image twice and the preload becomes a penalty. Generate the optimised URL at build time and emit a matching preload link in the head. One fetch, started early, no waste.

6. Put it on a CDN that is actually fast
Static output means you can serve from the edge. I deploy to Cloudflare Pages and Time To First Byte sits around 50ms because the HTML is cached at the edge near the user. A fast origin matters far less when the document is already sitting in a city near them. One thing to check on Cloudflare specifically: turn off Bot Fight Mode for a static marketing site, it injects a challenge script that adds main-thread work for no benefit on content you want crawled.

Measure honestly
Run Lighthouse on the mobile profile with throttling, not desktop. Desktop scores are flattering and meaningless for a site whose traffic is mostly phones. I quote the Moto G Power, Slow 4G numbers because that is closer to a real South African user on a mid-range phone than an unthrottled laptop is. If your score only looks good on desktop, it is not good.

The payoff
None of this is clever. It is a stack that defaults to sending nothing, plus a handful of decisions to keep it that way. The reason most sites do not do it is not difficulty, it is that nobody made performance a requirement, so a hydrating framework and five marketing scripts crept in unchallenged.

If you want to see the whole approach in context, I wrote a less technical version aimed at business owners here: what a fast website actually looks like. And if you would rather someone just build you one that scores like this, that is literally the service.

推荐订阅源

DEV Community