Lighthouse Auditing a Static Blog Until the Scores Hit 100

I decided to audit my blog with Lighthouse. The site is a static Astro build with Tailwind CSS, a handful of images, and IBM Plex Mono as the only font. Should be fast by default, right? The first run gave me a performance score of 56. Three iterations later, every page hit 95+ and most landed at 100. Here’s what I fixed and what I learned about Lighthouse along the way.

Don’t audit against astro preview

My first runs used astro preview, which serves the production build locally. The scores came back in the 50s and 60s. The network waterfall showed requests for things like @vite/client and the Astro dev toolbar JS — nearly 500KB of development-only code that doesn’t exist in production.

The fix was trivial: serve the dist/ directory with a real static server instead.

npx serve dist -p 4322

The same build, same files — performance jumped from 56 to 82 instantly. The Astro preview server loads Vite’s HMR and dev toolbar, and Lighthouse counts that overhead against you. Lesson learned: audit against the same setup your users hit.

The font payload was 920KB

Even at P82 I was below the 95 target. The biggest culprit was font loading. I was importing IBM Plex Mono through @fontsource/ibm-plex-mono like this:

import "@fontsource/ibm-plex-mono/400.css";
import "@fontsource/ibm-plex-mono/600.css";
// ... 6 variants total

Each import pulled in all Unicode subsets — Cyrillic, Cyrillic Extended, Vietnamese, Latin, Latin Extended. After the Vite build, the dist/_astro/ directory contained over 30 font files totaling 920KB. For an English-language blog with a Polish name, none of the Cyrillic or Vietnamese glyphs were ever going to render.

The fix was switching to Latin-only imports:

import "@fontsource/ibm-plex-mono/latin-400.css";
import "@fontsource/ibm-plex-mono/latin-600.css";
// ... Latin-only variants

The result: 6 font files, 104KB total. A 89% reduction with zero visual difference. Performance jumped again.

The projects page had a 629KB thumbnail

The /apps page lists 16 projects, each with a thumbnail. The SRF project thumbnail was the full srf-news.png screenshot — a 1242×2688 phone render weighing 629KB, displayed in a 56×56 container.

Lighthouse flagged this as the Largest Contentful Paint element with a 7-second load time. The browser was downloading a phone-screenshot-sized image to render a stamp-sized thumbnail.

I generated properly sized thumbnails with sips (macOS built-in):

sips -Z 96 -c 96 96 srf-news.png --out thumb/srf.png

Same image, same visual result in the 56×56 container, but now 15KB instead of 629KB. I repeated this for every project that used a full-resolution screenshot as a thumbnail. The /apps page LCP dropped from 7 seconds to 1.5.

Other small fixes that compound

A few mechanical improvements rounded out the scores:

• Added link rel="preconnect" for fonts.googleapis.com and fonts.gstatic.com so the browser can open the connection before the CSS resolves the font URL.
• Filled in the empty <meta name="theme-color" content=""> with the site’s dark background color (#212737) — a free SEO and PWA signal.
• Switched inline scripts to use is:inline so Astro doesn’t try to bundle them through Vite.

None of these individually moved the needle by 20 points. But together with the font and image fixes, they eliminated the remaining warnings.

Final scores

The accessibility scores sit at 92–96 due to pre-existing contrast issues on tag pills — the accent color on the card background doesn’t meet WCAG AA in light mode. That’s a theming fix for another day.

Update: Darkened the light mode accent from rgb(0, 108, 172) to rgb(0, 90, 155) — the contrast ratio on tag pills went from 4.48:1 (barely failing) to 5.8:1 (comfortably passing WCAG AA).

What I learned about Lighthouse

The biggest takeaway: Lighthouse measures what ships to the browser, not what you think you shipped. The astro preview server gave me scores in the 50s. A static file server gave me 82. The exact same production build, different delivery mechanism. If you’re trying to audit a static site and can’t figure out why the scores are bad, check what’s actually being served — there’s probably a dev middleware in the way.

The second takeaway: check your font loading. If you’re using a font package that supports 12 Unicode ranges and your site only needs Latin, you’re shipping 90%+ dead weight. Most fontsource packages have subset-specific entry points — use them.

The third: a 600KB image rendered at 50×50 pixels is 600KB of wasted bytes and a multi-second LCP penalty. Resize your thumbnails. It takes 30 seconds and gives you 30 points.