A page can load quickly and still make someone wait to use it. The menu opens late. Search freezes while filtering. The back button returns to the wrong place. A consent banner arrives just as the visitor tries to select a link.
Those delays are part of the website, even when a performance report does not make them the headline.
I want performance work to explain a specific experience: which action was slow, what the browser was doing, and what changed after the fix. A score can point toward that investigation. It cannot describe the whole visit.
Start with a journey someone actually needs
For a service website, a useful test might be: open the home page, find a service, inspect its details, open contact information, and return to the previous page. For an application, it might include signing in, filtering records, editing one, and saving.
Write the journey down before changing code. Include the device, browser, network conditions, cache state, and relevant user state. Testing a cached page while signed out does not answer the same question as a first visit followed by an authenticated search.
Philip Walton’s explanation of lab and field data (opens in a new tab) is useful here. A lab run gives controlled conditions for investigation; field data reflects actual visits across different devices and circumstances. Disagreement between them is information to investigate, rather than a reason to pick whichever result looks better.
For a new site without enough field data, record that limitation. Use repeatable lab tests and real-device checks without presenting them as evidence from an audience the site does not yet have.
Keep the symptom separate from the suspected cause
Suppose a hypothetical product directory displays promptly, but changing a category filter produces a visible pause. “The site is slow” leaves too many possibilities open. “The page stops responding after a filter change, even when no network request is made” is a much better starting point.
A browser performance recording can reveal whether the time is going into JavaScript, style calculation, layout, painting, or another activity. A network waterfall answers a different question: what had to be transferred, when it started, and what it waited for.
Capture both before proposing a framework change. If a filter handler sorts and rebuilds thousands of rows on every keystroke, changing the image format will not address that pause. If the largest visible image is discovered late, rewriting the filter will not make the image appear sooner.
Dan Luu’s measurements on slower devices (opens in a new tab) are a useful reminder that a development machine can conceal expensive browser work. I would use that as a reason to test beyond my own laptop, not as a benchmark that predicts a particular site’s results.
Make one change that tests the explanation
For the directory example, imagine the trace shows repeated sorting of data that has not changed. A narrow experiment would move that sorting out of the input handler, then repeat the same interaction with the same records.
If the pause remains, the explanation was incomplete. Look again. If it improves, check what happened elsewhere: memory use, initial loading, stale results, and keyboard behavior. Moving work earlier can help an interaction while making startup worse.
Other changes need the same discipline. Loading a script later may reduce startup work but move the delay to the first person who needs it. Reserving image dimensions can prevent movement without reducing transfer time. Reducing a hero image’s bytes may improve loading while making it visibly poor on a large screen.
The question is whether the change improves the intended experience at an acceptable cost. “We deferred more JavaScript” is an implementation detail, not the result.
Read the metrics in context
Google’s Web Vitals guidance (opens in a new tab) currently centers on Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. Field assessments use the 75th percentile, with mobile and desktop considered separately.
Those metrics cover important aspects of experience. They do not establish that the right content loaded, a search returned useful results, or a form saved correctly. A fast failure is still a failure.
For a low-traffic site, avoid dressing a tiny sample in the language of statistical certainty. For a larger site, inspect relevant page types and device groups before relying on an aggregate. A healthy home page can conceal a slow directory that matters more to the visitor’s task.
A useful performance note contains the reproduction, environment, suspected cause, before-and-after evidence, and any tradeoff. That is more useful to the next developer than a screenshot of a score without the conditions that produced it.
Give the finished work a regression check
Once a specific problem is understood, preserve a way to catch it returning. That might be a repeatable interaction recording, a transfer-size budget for a route, or a check that a newly introduced dependency does not load on pages that do not use it.
Choose the check around the actual failure. A bundle budget will not detect every expensive loop. A screenshot will not prove responsiveness. A single measurement should not be treated as a stable baseline when repeated runs vary materially.
The test is finished when someone can complete the journey reliably under the conditions the site is meant to support—and the team has evidence for the improvement. The second click deserves as much attention as the first load.