My Lighthouse Score Is Bad, What Should I Fix First?

You ran Lighthouse, got a red 43, and a page of warnings you don't understand. Here is the short answer: don't fix everything. Two problems cause most low scores on vibe-coded apps, and they are huge images and a heavy JavaScript bundle. Fix those two first, re-run, and the number usually jumps. Everything else on the report is minor by comparison.

Why the report looks so scary

Lighthouse grades one page load against dozens of audits and shows every single one, passing and failing, in one long list. It does not tell you which failures actually cost you points and which are rounding error. A red "eliminate render- blocking resources" and a red "serve images in next-gen formats" look equally urgent on screen. They are not.

Your AI agent built a page that works, and "works" was the goal. It dropped in the full-size hero image you gave it, pulled in whatever libraries got the feature done, and never went back to trim any of it, because you didn't ask it to and the demo looked fine. That is why the two big offenders are almost always image weight and bundle size.

How to read your own report

1. Run the audit somewhere honest. Open Chrome DevTools, go to the Lighthouse tab, choose Mobile, and run it. Or paste your URL into PageSpeed Insights. Mobile matters because that is where most first users land, and it scores harder.
2. Ignore the score for a second and scroll to Opportunities and Diagnostics. Each row shows an estimated savings in seconds or kilobytes. That number is your priority order. A row saving 3.2 s beats ten rows saving 0.1 s each.
3. Look at the three headline metrics: LCP (how long the biggest thing takes to appear), CLS (how much the page jumps around while loading), and TBT (how long the page is frozen by JavaScript). LCP is usually the image problem. TBT is usually the bundle problem.

The fix

1. Shrink the images first. Find the largest image on the page (Opportunities will name it). Resize it to the size it actually displays at, export it as WebP, and add loading="lazy" to anything below the fold. This alone often moves the score more than anything else. See optimising huge images.
2. Cut the JavaScript. Check "Reduce unused JavaScript" for the biggest culprits. A heavy chart, animation, or date library loaded on every page is the usual cause. Load it only where it is used, or drop it. See making your bundle smaller.
3. Fix layout shift. If CLS is red, give images and embeds explicit width and height so the page stops jumping. This is quick and cheap points.
4. Re-run and stop when it is good enough. Beta does not need a 100. Get mobile into the green (90+) or a solid amber, confirm the page feels fast on a phone, and move on.

The trap to avoid

Do not chase the score to 100 by fixing tiny audits, and do not paste the whole report into your agent and say "make these pass." You will spend an afternoon on 0.1-second savings, and the agent may add caching headers or config it doesn't understand to silence a warning while the 3-megabyte hero image sits untouched. Fix the two big things by hand, then re-measure. The score follows the seconds, not the other way round.

Where this fits

A slow first load is one of the quietest ways to lose a beta user: they don't complain, they just close the tab. Lighthouse is a decent smoke alarm, but it buries the two fixes that matter under thirty that don't. The free Readiness Report runs against your real pages and tells you, in order, what is actually costing you load time, and whether you are fast enough for a first audience. If you would rather have the fixes done and verified, that is what the Finishing Pass is for. Worth pairing with how fast your app needs to be for beta.