A visitor reads a service page, compares options and sends an enquiry. The website can interrupt any of those steps: content appears late, a button responds slowly, or the form moves while someone is typing. Performance work should identify an obstacle and demonstrate that the change improves the relevant task.
A report score alone does not explain why someone left. Technical measurements, interface checks and reliable enquiry data answer different questions. Neither a faster page nor a high Lighthouse score promises a particular revenue increase.
Start with pages and actions
Testing only the homepage leaves important journeys uncovered. Choose representative templates: the homepage, service, case study, article and enquiry form. For a shop, include the catalogue, product page and checkout.
Write down the action for each URL: understand the offer, open navigation, filter results, reach the brief, correct an error or submit the form. Include the mobile journey. An article receiving search traffic deserves attention even when the homepage looks fast.
Lab and field data
| Evidence | Useful for | Does not establish |
|---|---|---|
| Lighthouse under recorded conditions | Finding technical causes and comparing changes | That every visitor gets the same experience |
| CrUX data in PageSpeed Insights | Reviewing accumulated real-user experience | That today's change affected the whole reporting window |
| A browser interaction check | Finding a failure in a specific task | How frequently the audience encounters it |
| Enquiry analytics | Observing progress towards an enquiry | That speed alone caused a conversion change |
PageSpeed Insights field data covers the preceding 28 days. Check whether it represents the exact URL or the whole origin. Insufficient observations can mean no field data is available; that is an unknown result, not a pass. About PageSpeed Insights.
Which metrics to read
| Metric | What the visitor experiences | Good threshold |
|---|---|---|
| LCP | Appearance of the largest visible content element | At most 2.5 seconds |
| INP | Responsiveness to an interaction | At most 200 milliseconds |
| CLS | Unexpected movement of page elements | At most 0.1 |
These Core Web Vitals thresholds apply at the 75th percentile, with mobile and desktop assessed separately. They are not measured CoreWeb results. A standard Lighthouse page-load test does not measure real visitors' INP; TBT helps diagnose blocking but does not replace INP. Web Vitals measurement guidance.
Why one score above 90 is not enough
Lighthouse combines several measurements into its performance score. Conditions affect the result, and the same score can conceal different problems. Keep the report, tool version, device and network settings, and measurement date. Lighthouse performance scoring.
Agree on URLs, tasks, environment, cache state, third-party services and acceptance criteria. Repeat tests under the same conditions and retain the variation, rather than selecting the best run. Then check forms, navigation and content. Removing a service the business needs to improve a score requires a separate product decision.
Choose work from the diagnosis
| Observation | Investigate | Verify the change |
|---|---|---|
| Main image appears late | File size, displayed dimensions and request timing | Compare that element's loading before and after |
| Button responds late | Long JavaScript tasks and the interaction handler | Repeat the action on the same device |
| Text or form moves | Reserved space for images, fonts and banners | Inspect the moment of movement in a journey recording |
| Returning visits remain heavy | Cache headers and repeated requests | Compare cold and returning visits separately |
| A new service introduces a delay | Chat, analytics or another widget | Compare agreed configurations with and without it |
Prioritise a problem interrupting an important task on a visited template. Record the observation, suspected cause and verification method. A red report does not justify changing the CMS on its own. Establish the cause first. For architecture discussions, see the Nuxt and WordPress comparison.
A test record to share with your developer
Copy this checklist into the task:
- URL and visitor action.
- Date, website version and test environment.
- Device, browser, connection and cache state.
- Evidence type: lab measurement, field data or manual check.
- Field-data period and scope: URL or origin.
- Observed problem, initial measurements and report link.
- Change made, comparable repeat measurements and remaining limitations.
- Form, menu and other essential interaction checks after the change.
This makes the work reviewable: the reader can identify the original problem, the change and the evidence supporting the result.
Assess the business effect separately
First establish that enquiries are recorded correctly. Compare similar periods and traffic sources, and note changes to advertising, the offer and the form. A handful of enquiries is too little evidence to confidently attribute a difference to performance work.
Older industry studies can suggest a hypothesis, but their percentages are not a forecast for an individual corporate website. Good Core Web Vitals are also insufficient to guarantee leading search positions. Core Web Vitals and Google search results.
For a new website or rebuild, include pages, actions and test conditions in the project scope. Review our website development process and attach the relevant URLs and completed test record to your project description.