Start with a slow step that matters to your customers, then ask for evidence of its cause. A low PageSpeed score is a reason to investigate. It is not enough on its own to decide which work to buy, how much to spend or whether your website needs replacing.
For a business website, I would begin with the page people land on and the task they need to complete: finding a service, comparing a product, booking a call or sending an enquiry. The useful outcome is a faster, reliable journey with a repair you can verify.
Check which result you are looking at
PageSpeed Insights combines a controlled lab test with real-user data when available. Its field data covers a rolling 28-day period. Check whether it describes the individual URL or the wider origin: when a page lacks enough samples, the report can fall back to origin data. If neither has enough data, the field section is unavailable. That absence is not a failed speed test. PageSpeed Insights documentation.
Record the URL, mobile or desktop view, test date and data scope before discussing the result. A desktop report cannot settle a complaint about the mobile enquiry page. An origin-level result cannot establish which particular service page needs repairing.
The Lighthouse performance score is a weighted summary of metrics. It can vary between runs; its diagnostic suggestions do not directly add points to the score. Compare repeated tests under consistent conditions and ask which measured delay a proposed change addresses. How Lighthouse scoring works.
Name the problem the visitor experiences
Core Web Vitals distinguish three parts of the experience. Their good thresholds are assessed at the 75th percentile, with mobile and desktop considered separately:
- LCP, loading: 2.5 seconds or less for the largest visible content element to appear.
- INP, responsiveness: 200 milliseconds or less for interaction responsiveness.
- CLS, visual stability: a score of 0.1 or less for unexpected layout movement.
These are different measurements, not three ways of saying that a page loads slowly. Google's Web Vitals guidance.
Describe what happens in ordinary language: “The main photo appears late,” “The menu does not react when I tap it,” or “The button moves while I am trying to press it.” Give the developer a reproducible action and a device to test.
Also separate response from completion. INP concerns the next visual response to an interaction, not every later network operation. A form can acknowledge a click promptly while its submission still takes too long to finish. Test both the feedback and the completed request. What INP measures.
Prioritize the pages that support a buying decision
My first review would use a small, deliberate sample: a main advertising destination, an important service or product page, and the enquiry or checkout flow. Include another page when it uses a materially different layout or tool. Testing only the homepage leaves too much unknown.
For each issue, write down:
- Customer task: what the visitor is trying to do.
- Evidence: the exact page, symptom and relevant measurement.
- Reach: whether it affects one page or a shared component.
- Proposed change: what will be altered and what must still work.
- Acceptance: how the improvement will be checked.
Use actual traffic and enquiry evidence where you have it. Without that evidence, start with the pages you actively send prospective customers to and state that this is a practical priority, not a measured ranking of lost sales.
A broken enquiry button deserves attention even if a speed report looks healthy. If the page is usable but an optional element is slow, weigh the repair cost against the value of that element. Avoid commissioning every warning in a report as a separate job.
Ask for a bounded repair with a plausible cause
A useful proposal connects one observation to one change. If the main image appears late, ask the developer to establish whether the delay is in discovering it, downloading it or displaying it. Google specifically advises against lazy-loading the LCP image; a smaller file alone does not solve every rendering delay. LCP optimization guidance.
If a menu or filter feels unresponsive, ask for a recording of that interaction and an explanation of what blocks the response. If content jumps, ask which element changes position and how the layout will reserve its space. Those requests make the scope reviewable without requiring you to diagnose the code yourself.
For a third-party chat, map, booking tool or marketing script, discuss when customers need it and what depends on it before changing its loading behaviour. Test the essential function and the agreed measurement afterwards. Removing a useful feature solely to improve a score can leave the business with a worse website.
A concrete example from this portfolio's images
The cover for my Meta forms versus website forms article has two WebP versions in this site's build: a 1536 × 1024 file of about 161 kB and a 768 × 512 file of about 48 kB. These are verified file sizes, checked on 1 November 2026, not client performance results.
The page offers both through responsive image markup. The browser can choose a suitable source using the available sizes and display conditions; a phone is not unconditionally forced to use the smaller file. MDN's responsive images guide.
That gives a specific acceptance check: inspect the image actually requested at the agreed viewport, check its sharpness and confirm that the page layout stays intact. The existence of a smaller asset alone does not prove that visitors received it, that the whole page became fast or that enquiries increased.
The same principle applies to a proposed repair: define what should change in the delivered page, then verify that change.
Agree on checks before approving the work
A focused performance brief can be short:
- List the URLs and customer actions in scope, including the mobile flow.
- Save the baseline reports and the conditions used to collect them.
- Ask for the suspected cause, proposed repair, price and exclusions.
- Specify the functions to preserve, such as navigation, booking, form delivery and measurement.
- Repeat comparable tests after the change and complete the customer task yourself.
- Schedule a later review of real-user data where it is available, allowing for the rolling reporting window.
For example, a service page could be accepted only after the main content appears reliably, navigation responds, the form remains usable on a phone and a test enquiry reaches its intended destination. This is an example acceptance plan, not a claim that those checks establish a particular score or sales uplift.
If the enquiry goes missing, investigate form delivery separately. If the scope expands into new content, navigation and integrations, use a website redesign brief to make those additional decisions explicit.
Choose the next investment from the evidence
Google uses Core Web Vitals in its ranking systems, but good scores do not guarantee top search positions. Its guidance also cautions against pursuing a perfect score solely for SEO. Google's page experience guidance.
For a business owner, the decision is more concrete: which change makes an important customer task work better, at a cost you can justify? Start with that change, verify it, then decide whether another round of work is worthwhile. Keep any claim about more enquiries tied to actual business records and a comparison that accounts for changes in traffic or campaigns.
If you want help deciding what to repair first, send the website URL, the PageSpeed report and the customer action that feels slow through my contact page, or write to hello@davidbuka.com. I can review the website and its enquiry journey together and help define a focused scope.