Write the comparison question first
Name the change and the outcome you expect to inspect before running the test. For example, a component adjustment may aim to reduce movement during a particular page journey. Choose the relevant observation instead of treating the overall performance score as a complete explanation. Record the page revision used for the baseline.
Define what counts as a valid run: the intended URL, page state, device configuration and completed journey. Record excluded runs and the reason, such as an unrelated connection failure, rather than quietly dropping inconvenient results. Do not set the acceptance rule after seeing which run looks best.
Keep the important conditions stable
Use the same tool configuration, viewport, network and CPU settings, cache policy and interaction sequence for the baseline and candidate. Note any tool or browser version change. If the page depends on login, consent choices or personalization, use equivalent states and document them without putting private information in the report.
The official web.dev explanation describes lab testing as a controlled environment intended to support reproducibility. That does not mean every run is identical. Background work and external resources can still vary. Record conditions clearly enough that another reviewer can repeat the comparison and understand its limitations.
Repeat the scenario and retain the distribution
Run a small planned series under the same conditions, keeping the individual results rather than only a selected screenshot. Report a summary such as the median together with the number of runs and the observed range. There is no universal run count that makes a small local test representative of every visitor.
Where possible, change only the feature being evaluated. If several unrelated changes land together, report them as a combined release and avoid attributing the entire difference to one edit. If the candidate’s results overlap substantially with the baseline’s variation, call the finding inconclusive rather than inventing a precise improvement.
Illustrative example: a changed component
Imagine a fictional page component is adjusted and the reviewer compares three baseline runs with three candidate runs. The baseline observations are 2.8, 3.0 and 3.2 seconds for the chosen metric; the candidate observations are 2.7, 2.9 and 3.1 seconds. The medians differ by 0.1 seconds, but the ranges overlap.
The reviewer records a small observed difference under these settings and plans further investigation if the decision needs stronger evidence. The report does not claim that all visitors gained 0.1 seconds or that conversions increased. These teaching numbers illustrate interpretation; they do not describe a measured customer result or establish statistical significance.
Pair performance evidence with functional checks
Repeat the essential user action after the candidate change. Verify that content remains readable, controls work and the expected result appears. A lower timing caused by omitting a necessary feature is not automatically an improvement. Record both performance evidence and any functional regression in the release decision.
Keep the baseline report, candidate report, revision identifiers and settings together. After deployment, use available field evidence within its stated scope and collection period to examine broader experience. A local comparison supports a bounded technical conclusion, not a guaranteed search ranking or business outcome. Your audit record should preserve that distinction.