A website speed test becomes useful when someone else can repeat it. Before looking at the score, record the page, the test conditions, and the visitor task. Those details let you distinguish a real change from an incomparable report.
Pick representative pages
Start with one important page per template: for example, a service page, a product detail page, and a content article. A fast homepage does not establish that the rest of the website uses the same images, scripts, or layout.
For each page, write a short purpose such as “choose a service and find the booking link.” You can then test the visible task as well as the loading measurement.
Run a controlled first pass
Use Google PageSpeed Insights for a public URL or PageVital's free snapshot to inspect performance alongside other page findings. Only test pages you own or have permission to assess.
Record this test note before changing anything:
Page and final destination:
Observation date and time:
Tool and device mode:
Lab or field data:
Page-level or origin-level data:
Metric or finding to investigate:
Unavailable measurements:
PageSpeed Insights shows Lighthouse lab diagnostics and, where sufficient data exists, CrUX visitor data. Its field results cover a trailing 28-day period and can fall back from a page to the origin. A new deployment therefore should not be judged from an unchanged historical field result alone. See Google's PSI documentation.
Investigate a specific delay
Avoid changing five unrelated settings because a score is low. Open the details and choose a question: what delayed the main image, what work blocked an interaction, or what caused content to move?
Use the browser's development tools to reproduce the issue. Test a proposed correction in a safe environment first, especially when changing caching, JavaScript loading, or a third-party integration. A faster page that breaks the visitor's task is not an accepted repair.
Compare observations fairly
Repeat the test with the same URL and device mode. Keep the conditions recorded even when the tool controls some of them. Run more than one comparable measurement when results vary, and retain the range rather than choosing only the most flattering result.
Use a note such as this for a fictional example:
After resizing the services-page image, the repeated mobile lab runs showed a lower LCP range than the recorded baseline. The booking link and layout were checked manually. Real-user data has not yet established a change for the observation period.
Do not convert Total Blocking Time into an INP number. The Core Web Vitals guide explains which metrics belong to each view.
Handle failed measurements honestly
A timeout is not a performance pass. Keep the failed attempt separate from the last usable evidence, note that the latest result is incomplete, and investigate whether the test service or target page caused the failure.
For sites you maintain repeatedly, use the monitoring workflow to preserve that distinction between attempts and evidence.