Getting to a 100 Lighthouse Score, Realistically

A 100 Lighthouse score is a satisfying number to screenshot, but chasing it as a goal in itself tends to produce diminishing, sometimes counterproductive work. The version of "100" that actually matters is the one where real users on real networks and real devices experience a fast site - which is a slightly different, more disciplined target.

Set a performance budget before you build

Agree on a JavaScript weight ceiling, an image weight ceiling, and a target Largest Contentful Paint before the first line of a new feature gets written - not as a post-launch audit item. Budgets set after the fact become negotiations; budgets set before the fact become constraints engineers design around from day one, which is far cheaper than retrofitting performance later.

Images are still the biggest lever

Across the audits we run, oversized and unoptimized images remain the single largest contributor to slow page loads - more than framework choice, more than third-party scripts. Modern formats (WebP/AVIF), correct sizing at the breakpoint, and lazy-loading below the fold routinely account for the largest single jump in Lighthouse's performance score of anything on this list.

Audit third-party scripts quarterly

Analytics pixels, chat widgets, and marketing tags accumulate silently over a product's life and rarely get removed even after the campaign or tool they supported is gone. A quarterly audit of what's actually still in use - and cutting what isn't - is one of the highest-return, lowest-effort performance tasks available, and it's the one teams skip most often.

Measure on the device your users actually have

Testing performance on a developer's high-end laptop over office fiber tells you almost nothing about the experience on a mid-range phone over a throttled connection - which, for most consumer products, is the median real-world case. Test against that baseline, not your own hardware, and the priority order of fixes usually changes.