Speed can interrupt a customer journey, but the effect on enquiries or sales depends on the audience and task. Measure the actual experience before assigning a universal percentage loss to every second.
Record a useful baseline
Choose representative pages: the homepage, an important service or product, an article and the enquiry or checkout journey. Record URL, date, device profile, connection conditions and whether the result comes from a controlled lab test or real-user data. Use the same conditions when comparing a change.
A lab run is useful for diagnosis. Field data describes the experience of actual visits over a period and may not be available for a new or low-traffic site. Do not label a new site as passing field Core Web Vitals solely because Lighthouse reports a high score.
Understand the metrics
Core Web Vitals describes loading, responsiveness and visual stability through LCP, INP and CLS. Lighthouse’s performance score is a separate lab summary. A low total blocking time in a lab is useful information, but it is not the same measurement as field INP.
See Google’s Core Web Vitals guidance for the measurement context. A strong technical result does not guarantee a particular search position or a successful enquiry journey.
Fix the measured bottleneck
Inspect the largest visible content, image sizes, fonts, render-blocking resources and unnecessary script work. Check hosting response, compression and caching where relevant. Prioritise a shared-template problem when it affects several important pages.
For example, an oversized hero image may need a correctly sized responsive version rather than a lower-quality version sent to everyone. A site-wide animation may add work without helping the customer. Make a controlled change and repeat the test rather than applying unrelated optimisations at once.
Connect the result to the task
Suppose a hypothetical product page improves its loading metric after image changes. That shows a technical improvement under the test conditions. It does not by itself prove that the change caused an increase in sales. Compare enquiry or purchase completion over a suitable period and account for traffic mix, promotions and seasonality.
Watch for usability problems that a speed score does not explain. A fast page can still have an unclear offer, a tiny control or a form that never reaches the intended mailbox. Technical performance and a complete user journey need separate checks.
Keep the improvement repeatable
Record what changed and set sensible image, script and testing practices for future updates. Re-test when a new plugin, major design change or third-party service alters the page. Avoid chasing a perfect score at the expense of useful content or accessibility.
Our technical SEO review covers performance in the wider search and site context. For ongoing checks and software care, see website maintenance.
