← All posts

Lighthouse 96-100: what actually moves site speed, and what is a myth

Why speed is the honest metric

Speed is the one claim on a portfolio you can verify yourself in one click - Lighthouse runs the same for everyone. The builds I still control score 96-100, and every score on my work page links to Google's own test, pre-filled. That transparency is only comfortable if you know what actually produces those numbers.

What moves the needle

  • A weight budget, enforced. The page has a byte allowance before design starts. Every asset negotiates for its bytes. Without the budget, weight only ever grows.
  • Image discipline. Right-sized derivatives for every breakpoint, modern formats, lazy-loading below the fold, and explicit dimensions so nothing jumps while loading. Images are 60-70% of most pages - this is where the biggest wins live.
  • No tag soup. Every marketing pixel, chat widget and heat-mapper is a script someone else controls on your critical path. Each one costs real milliseconds and most are never looked at. Audit quarterly, delete freely.
  • Layout stability. Cumulative Layout Shift is UX, not vanity: reserve space for everything that arrives late - fonts, images, embeds - so the page never jumps under the user's finger.

What is mostly myth

The minifier fight (gzip already does most of that work), switching frameworks for its own sake (a slow site rebuilt in a new framework is a slow site with new syntax), and "the server is slow" (usually the 4MB hero image is slow). Fix the visible weight first; the exotic optimisations are the last 2 points, not the first 40.

Why it is worth the discipline

Speed compounds quietly: better crawl budget, better ad quality scores, fewer bounced phones on hotel wifi, and a subconscious signal of competence. A fast site feels like a well-run company. A slow one feels like a queue.

Run your own site through the test - and if the number hurts, the fix is usually smaller than a rebuild.