Name the delay
“The page is slow” might mean a long load, a delay after a click or uneven animation. Those problems do not necessarily share a cause. Reviewing this website’s visual behaviour has been a reminder to separate the user’s observation from what an individual technical measurement says.
Choose one journey: open the page, perform a particular action and wait for its visible result. Record the device, browser and conditions. A useful baseline describes the problem well enough to repeat the same trial after a change.
Compare like with like
Heavy tests running at the same time can change the result. A warm cache and a fresh load are different situations too. Compare under controlled conditions and repeat the trial. Do not select only the best run or compare numbers collected in different ways.
Understand what the metric measures. A short JavaScript execution time does not by itself mean the graphics have finished or the user has seen the change. Likewise, checking a mobile viewport on a computer does not establish performance on a real phone. Stating that boundary makes the result more useful.
Change what the evidence supports
If the observation points to a particular bottleneck, make a small targeted change and repeat the same trial. Check that usability has not deteriorated along the way. If the result does not support a fix, the next step may be better measurement rather than more code. The value of optimization is not the number of changes but whether the user’s experience demonstrably improves.
A useful next step
A useful experience without motion too