Lighthouse performance audits: what to fix first

Short answer: Lighthouse is useful, but its headline number is one controlled lab observation. It is not a permanent grade for your website and it does not prove rankings, enquiries or revenue. Use it to identify a measured bottleneck on an exact page, make one bounded repair, rerun the same conditions and then check real-user evidence where it is available.

Start with the page's business job

A homepage, booking page and long article do different work. Before changing fonts, motion or images, record what the page must let a visitor do: understand the offer, read the content, call, submit a form, book or buy. Verify that journey on a real mobile device. A technically fast page with a broken form is not a successful repair.

Keep the test details with the receipt: URL, date, mobile or desktop profile, throttling, Lighthouse version and whether the run was local or hosted. Without that context, two scores are not a clean before-and-after comparison.

Lab data and field data answer different questions

Lighthouse simulates a visit under defined conditions and explains what happened in that run. Google's Chrome User Experience Report aggregates eligible real-user experiences over time. A page can look healthy in one lab run and still have weak field data, or have no page-level field sample at all.

Read both honestly. If field data is absent, call it absent rather than passing the page. If a template has field evidence only at origin level, do not pretend it proves every URL. The Web Vitals guidance explains the current user-experience metrics and how they are measured.

Let the trace choose the repair order

Images, fonts, scripts, server response, CSS, embeds and analytics tags can all be expensive. There is no universal rule that images are always first or that branding is never responsible. Open the diagnostics and trace for the exact page.

• Large image cost: serve the display dimensions the page needs, choose an appropriate format and quality, and avoid lazy-loading the likely largest above-the-fold image.
• Server delay: verify cache behaviour, application work and origin response before changing the visible design.
• JavaScript work: remove unused code where safe, delay non-critical third-party work and keep the primary journey usable before optional scripts finish.
• Font cost: inspect actual files, weights and layout shifts. WOFF2, subsetting, font-display and selective preloading can help when the evidence supports them.
• Layout shift: reserve image, embed and component space and inspect late-loading banners, fonts and consent tools.

Keep motion accessible

Motion is a design decision with a performance and accessibility cost. Respect the visitor's prefers-reduced-motion setting, avoid motion that blocks reading or interaction, and keep the page understandable when animation code fails. If an effect creates meaningful main-thread work or repeated layout changes, simplify it or move it out of the critical path.

Do not keep animation merely because it looks polished, and do not delete it merely to chase a number. Record its purpose, measured cost and accessibility treatment. That turns an opinion into a reviewable decision.

Run a controlled repair

1. Save the initial trace and test conditions.
2. Name the largest verified bottleneck and the customer-facing risk it creates.
3. Change one bounded area where practical.
4. Rerun the same page and conditions more than once; note run-to-run variation.
5. Check that the page still renders, reads and completes its primary action on mobile.
6. After deployment, watch field evidence and real error or conversion signals over an appropriate window.

If several faults must be repaired together, label the work a repair bundle. The result can show that the bundle improved the measured experience, but it cannot prove which individual change caused the movement.

What not to claim

A Lighthouse score does not establish that Google will rank the page, that a customer will enquire, or that the score will remain the same after content, tags, hosting or test conditions change. Core Web Vitals are part of the broader page-experience picture, while relevance and helpful content still matter. Google's page experience documentation is the right source for the current search guidance.

Likewise, a short A/B test does not prove that a font or animation changes sales. If a commercial experiment is justified, define the primary outcome, allocation, minimum sample, conversion lag and safety guardrails before reading the result.

A practical handoff

A useful performance repair package contains the initial evidence, affected URLs or templates, proposed change, accessibility check, rollback, repeated lab results, available field evidence and the next review date. That is what a client can inspect and own.

See our website performance guide for the wider maintenance workflow, or review the website service scope. If you want a page-specific starting point, the site audit records what is observed and what would be changed first; it does not promise a score.