Measure before optimizing

Performance work starts with a user-visible problem, not a list of fashionable optimizations.

“The page is slow” might mean several different things:

• the main content appears late
• a click takes too long to produce a frame
• content moves while someone is reading
• scrolling or animation misses frames
• memory grows after a feature is closed

Each symptom needs different evidence. Network timing can explain a late resource, while a main-thread recording can explain blocked input. A heap snapshot will not diagnose a slow server response.

Build a repeatable baseline:

1. Write down the action and visible symptom.
2. Use a fresh load or a warm load intentionally; do not mix them.
3. Apply realistic network and CPU throttling when appropriate.
4. Record the smallest window that contains the problem.
5. Save the metric, trace, or screenshot that demonstrates it.

Then change one likely cause and record the same scenario again. If several variables change at once, an improvement does not tell you which change mattered.

Lab tools give repeatable diagnosis. Field data shows what real visitors experience across devices, networks, locations, and page states. Use field data to find important problems and lab recordings to reproduce and explain them.

As an experiment, profile the same page once with cache disabled and once with a warm cache. Label both recordings. The difference demonstrates why an unlabeled “before” measurement is weak evidence.