Every Optimization Behind a Perfect Lighthouse Score

I run Lighthouse on my site constantly. It stays at 100 on every local run and 100 in Vercel's Real Experience Score.

These scores do not come from a generic checklist. I achieve them by moving work from the browser to the build stage.

Here is exactly how I do it.

Move work to build time

Most guides tell you to lazy-load everything. I prefer to prerender. I use TanStack Start with prerendering enabled.

This turns the entire site into static HTML during the build. The browser does not have to execute heavy JavaScript just to show the first page. The HTML is already there when the user hits enter.

Precompute complex logic

My homepage has a world map with 5,000 dots. Usually, a library would parse GeoJSON and run math on the main thread. This blocks the page for 1,000ms.

I solved this by moving the math to a build script.

  • I generate a single SVG path string for all 5,000 dots.
  • One path is much faster for the browser to render than 5,000 separate circles.
  • I pre-calculate coordinate lookup tables so the browser does zero math at runtime.

The 1,000ms delay becomes a single, instant paint.

Optimize font loading

I use rel="preload" for my primary fonts.

A common mistake is forgetting the crossOrigin attribute. If you omit it, the browser fetches the font twice. This ruins your Largest Contentful Paint (LCP). I only preload the three fonts used above the fold.

Use the right tools for animation

I use SMIL for simple pulse animations on my map markers. It is cheaper than using React state to drive an animation loop. It lets the browser handle the work on the compositor thread.

For complex paths, I use motion. I keep it simple. I animate once on mount and avoid listening to scroll positions.

Stick to vectors and webp

If it is a logo or a shape, use an SVG. If it is a photo, use WebP. This keeps the file size low and prevents layout shifts.

Avoid over-engineering

I do not use an image CDN. I do not use complex code-splitting. My site is small, so route-level splitting is enough.

A perfect score can be a vanity metric. The real goal is to measure your performance and move as much work as possible away from the user's device.

My Portfolio: brodin.dev

Source code: github.com/NathanBrodin/Portfolio

TanStack Start prerendering: tanstack.com/start

Paper Shaders: shaders.paper.design

Full post: https://dev.to/nathan-brodin/every-optimization-behind-a-perfect-lighthouse-score-283n