10 Lighthouse Tricks That Actually Move the Needle
Stop chasing vanity scores. These ten targeted optimizations have the highest ROI for real-world Lighthouse performance improvements in React and Next.js apps.
By ShipReady · Updated
A Lighthouse score is a means, not an end — the goal is a page that feels fast to real users. But a handful of changes reliably move both the score and the experience. Here are ten, roughly in order of return on effort.
First, know what the score is
The Lighthouse performance score is a weighted average of a handful of lab metrics, measured on one simulated device with throttled network and CPU. Two consequences follow, and both explain the frustration people have with it.
- It is variable. Run it three times on the same page and you will get three numbers, sometimes several points apart, because it depends on what else your machine is doing. Compare medians across runs, never a single before-and-after pair.
- It is not what ranks. Google's page experience signals use field data from real Chrome users, not this lab run. A green score with failing field data is entirely possible — see Core Web Vitals for the distinction.
Use it as a diagnostic that surfaces problems cheaply, then confirm in the field. Chasing the number itself is how people end up optimising a simulated Moto G rather than their actual customers.
The high-ROI wins
- Serve images in AVIF or WebP and size them to their rendered dimensions.
- Give the hero image priority so it is not lazy-loaded behind everything else.
- Preconnect to third-party origins your critical assets load from.
- Code-split so a route ships only the JavaScript it needs.
- Defer or async non-critical scripts (analytics, chat widgets).
- Set font-display: swap and preload your primary font to kill invisible-text delay.
- Send long cache headers on static assets so repeat visits are near-instant.
- Remove unused CSS and JavaScript — dead code still costs parse time.
- Lazy-load anything below the fold, including offscreen images and iframes.
- Reserve space for media and embeds so nothing shifts as the page settles.
Notice what is not on the list: micro-optimizations that shave milliseconds no user will feel. And notice what the list mostly is — server and delivery configuration, not clever code. That is why several of these are visible from outside the app.
The three that usually account for most of it
If you only have an hour, these are where it goes.
| Fix | What it moves | How to do it |
|---|---|---|
| Hero image format, size and priority | LCP, often by a full second | Serve AVIF or WebP at the rendered dimensions, and mark the hero priority (Next.js) or fetchpriority="high" so it is not queued behind everything else. |
| Defer non-critical third-party script | INP and total blocking time | Chat widgets, analytics and tag managers rarely need to run before first paint. async, defer, or load them after interaction. |
| Reserve space for media | CLS, to near zero | Width and height, or an aspect ratio, on every image, iframe and embed. This is the cheapest fix on the list and the one most often skipped. |
Notice that none of these require touching application logic. That is the general shape of the thing: the largest wins in web performance are usually about what you send and when, not about how the code is written.
The ones an outside scan can confirm for you
ShipReady does not run Lighthouse and does not produce a performance score. It checks the passive hygiene behind several items above, on every page it crawls: text served uncompressed, static assets with no cache headers, render-blocking scripts, images with no width and height, and redirect chains. Those are configuration facts, so a scan can state them with evidence rather than estimate them.
For the rest — bundle size, unused CSS, third-party cost — run Lighthouse locally and then check the field data, because that is what actually ranks.