Performance and DevTools

Measure before optimizing

Start performance work from a user-visible problem and a recording rather than guessing from code alone.

Performance work starts with a problem a user can see. Not with a list of optimizations you read about last week.

“The page is slow” can mean five different things:

  • the main content shows up late
  • a click takes too long to change anything on screen
  • content jumps around while someone is reading
  • scrolling or an animation stutters
  • memory keeps growing after a feature is closed

Each one needs different evidence. Network timing explains a late resource. A main-thread recording explains a blocked click. A heap snapshot explains growing memory. None of them explains the others. If you open the Memory panel to debug a slow server response, you’ll learn nothing.

Build a baseline you can repeat

Before touching code, capture the problem in a way you can reproduce. My routine:

  1. Write down the exact action and the visible symptom. “Clicking Add to cart takes about a second to update the badge.”
  2. Decide whether you’re testing a fresh load or a warm one, and stick to it. Don’t mix the two.
  3. Turn on network and CPU throttling when the affected users are on slower devices.
  4. Record the smallest window that contains the problem. Start recording, do the action, stop.
  5. Save the metric, the trace, or a screenshot. This is your “before”.

Then change one likely cause and record the same scenario again, same conditions. If you change three things at once and the page gets faster, you don’t know which change did it. You also don’t know which two you can revert.

Lab data and field data

A recording on your laptop is lab data: controlled, repeatable, inspectable. It’s how you diagnose.

What your real visitors experience is field data: many devices, many networks, many cache states. It’s how you find out which problems matter. A page that’s fast on a MacBook over fiber can be painful on a mid-range phone on a train.

Use field data to pick the problem. Use lab recordings to reproduce and explain it. Then check the field data again after the fix.

Compare a cold and a warm load

Open the Network panel on any page and reload with “Disable cache” checked. Note the load time. Uncheck it and reload again. Label both numbers.

The gap between them is often huge. That’s why an unlabeled “before” measurement is weak evidence: nobody can tell which of the two situations it describes.

Lesson completed