Start with an actual task
Open your website on a phone and complete the task you want a customer to complete. Find a service, compare the relevant information and submit an enquiry. Notice where the interface hesitates, moves unexpectedly or makes you wait without explanation. Those moments are a more useful starting point than a single headline score.
Repeat the task on a slower connection and on a device that is less powerful than your development machine. Record the page, action and observed problem. This gives the team a concrete issue to reproduce instead of a vague request to make the website faster.
Use lab and field data for different questions
Lab tests provide repeatable conditions for diagnosing a page. Field data describes experiences collected from real users. Google’s Core Web Vitals guidance covers loading, responsiveness and visual stability. Use these signals together with your own task observations; neither a good score nor one fast test guarantees a good customer journey.
When comparing tests, keep the device profile, connection and URL consistent. Record multiple runs instead of treating small variations as a trend. If field data is unavailable for a low-traffic page, document that limitation and use controlled checks to guide the first round of work.
Reduce the work the browser has to do
- Size and compress images for the space where they appear.
- Reserve space for images and embedded content before they load.
- Review third-party scripts and remove tools with no clear owner or purpose.
- Keep essential content accessible without waiting for decorative interactions.
- Check that menus, form fields and buttons respond while the page is still loading.
Treat every new integration as a tradeoff. A chat widget, heatmap tool or campaign tag may be useful, but it should have an owner who can explain its value. Keep a lightweight inventory of scripts, where they run and when they were last reviewed.
Set a budget before the next feature arrives
A performance budget is an agreed constraint that makes tradeoffs visible. Choose limits suited to the experience: image transfer size, script cost, the number of third-party tools or the time needed to complete an important interaction under consistent test conditions. Establish the baseline first, then decide which changes should require review.
For a service page, prioritise useful text, navigation and contact access. For a catalogue, make category browsing and product selection dependable. Rendering strategy should follow those tasks. Keep content that can be delivered directly in the initial page separate from interactions that genuinely need client-side code. Review whether an integration needs to run everywhere or only on the page where it provides value.
- Record the tested URL, device profile, connection and tool version.
- Set an owner for each budget and third-party integration.
- Check a representative mobile journey before approving a release.
- Reserve image space and verify font loading does not disrupt the task.
- Compare against the baseline using the same conditions.
Read a Lighthouse result without overclaiming
A Lighthouse report is a lab observation of a particular page under particular conditions. Keep its performance, accessibility, best-practices and SEO scores separate. A strong performance score does not establish complete accessibility, prove a ranking outcome or demonstrate an improvement in enquiries. Likewise, a high SEO score is not a comprehensive search strategy.
When sharing a report, preserve the URL, capture date and device or test mode where they are available. Put the screenshot next to an explanation of what was tested and what remains unknown. Do not combine the best numbers from unrelated captures into a single result. If the test conditions differ, describe the observations individually rather than calling them a before-and-after comparison.
Connect changes to meaningful outcomes
Define the conversion event before changing the page. A submitted enquiry is different from clicking the submit button; a qualified lead is different from either. Check that your event fires at the correct stage and does not duplicate when a visitor refreshes.
Annotate releases and compare comparable periods, accounting for changes in traffic sources, campaigns and demand. If speed and enquiries improve together, describe the observation without claiming that one change explains everything. Use controlled experiments where the traffic and decision justify them.