Why is my website slow when its Lighthouse score is good?

What does a speed score actually tell you?

Lighthouse runs a controlled assessment that helps reveal opportunities in the page it tests. Field measurements describe visits made by real people. The two answer different questions: a lab test helps reproduce a technical problem; field data helps establish how broadly people encounter it. Google’s measurement guidance explicitly describes reasons those results can differ.

Core Web Vitals cover loading, responsiveness and visual stability. Largest Contentful Paint (LCP) measures when the largest visible content element is rendered; a good result is 2.5 seconds or less. Interaction to Next Paint (INP) measures how long an interaction waits for the next visual update; a good result is 200 milliseconds or less. Cumulative Layout Shift (CLS) measures unexpected layout movement; a good score is 0.1 or less. These industry thresholds are assessed at the 75th percentile of visits, not as an average. They are not SystemVale performance results, and they do not measure every important business action.

A booking might meet these thresholds while its availability lookup takes too long. Keep a separate measurement for the customer’s actual outcome, such as time from selecting a date to seeing available appointments.

Which customer journeys should you measure first?

Start with three tasks that matter to the business: finding the right item, submitting a qualified enquiry, or completing an authenticated workflow. Write the start and finish of each task. A route name alone is insufficient if the delay happens after someone clicks a button.

For each journey, capture device class, page type, authenticated state, release version and the operation that was slow. Use broad categories rather than personal identifiers. Do not put names, email addresses, search text or access tokens into performance telemetry.

Prioritise repeated delays that prevent a valuable task from completing. A lightly visited administrative screen may still matter if it blocks every support agent. Traffic is one input; task importance, severity and the cost of recovery belong beside it.

• Loading: when can the person see enough to begin?
• Interaction: does a click or keystroke produce timely feedback?
• Completion: when does the requested result actually arrive?
• Recovery: what happens when the request fails or times out?

How do you find the cause of a slow visit?

Reproduce the same journey on an ordinary phone and a constrained connection. Start from a fresh visit, then repeat with a warm cache. Test both signed-out and signed-in states where relevant. Record the environment so another engineer can reproduce the observation.

Use the browser’s network and performance tools to trace the delay. Check whether the browser is waiting for a response, downloading too much, or spending time processing JavaScript. For a slow server response, follow the request into application and database traces. A frontend change cannot eliminate a database query that dominates the wait.

Change one suspected cause at a time. Temporarily disabling a third-party widget in a test environment can reveal its contribution, but the final decision must consider the function that widget provides.

What would a useful investigation look like?

Consider an illustrative appointment portal. The landing page performs well, but customers report that changing the appointment date feels slow. A trace shows the interface requesting the profile, then the office list, then availability, even though availability does not depend on the first two responses.

The proposed fix is to remove unnecessary sequential requests and cache information that is safe to reuse. The team also provides clear progress feedback and preserves the selected date when the availability service fails. This addresses both waiting time and recovery.

That is a hypothetical diagnostic example, not a client result. The useful lesson is the sequence: identify the exact task, trace its dependencies, change the bottleneck and verify the entire interaction. A redesign or a new hosting plan would have been premature.

How should you choose and release the fix?

Write a short hypothesis before implementation: “The availability lookup waits for unrelated requests; running those requests independently should shorten the wait without increasing failed bookings.” Attach the trace and specify the checks that would disprove the hypothesis.

Give each proposed fix an owner, an expected effect and a rollback condition. For caching changes, include correctness and freshness checks. For smaller bundles, test the features that were deferred. For infrastructure changes, compare errors and saturation alongside response time.

Release to a limited audience when the system supports it. Compare similar devices and traffic periods, and annotate the release. A simple before-and-after comparison can be distorted by a campaign, an outage or a quieter day; it is evidence to interpret, not automatic proof of causation.

How do you stop the same problem returning?

Create a small performance budget for each important journey. A budget is an agreed limit for something the team can monitor, such as initial JavaScript, an API response time or the completion time of a representative flow. Set it from a measured baseline and customer needs rather than borrowing an arbitrary number.

Run repeatable checks during development, but keep field monitoring after release. Assign someone to investigate regressions; an alert without an owner becomes background noise. Review error rates, failed tasks and support complaints together with speed.

If you do not have enough field data, say so. Use controlled tests and observed customer sessions while building a privacy-conscious measurement baseline. Do not report a tiny sample as a reliable picture of all visitors.