Skip to content

02Note

Measure before you optimize

Every performance project we run starts with one number users can feel, measured the same way every time.

Performance1 min read
Chart of a load time falling after a fix, with the difference measured.

A performance project that starts with a fix usually ends with an argument. We start with a number instead: the metric a user would notice, measured on the device or network they actually have.

Pick the metric users feel#

For a mobile app that is usually time to interactive on a cold start, or dropped frames on the one list everybody scrolls. For the web it is Largest Contentful Paint and Interaction to Next Paint from real users, not a lab score on a fast laptop.

Make it repeatable#

A number you can only get once is a rumor. We script the measurement, run it in CI against a fixed device or throttled profile, and keep the history. When a change lands, the chart says whether it helped.

Only then do we open the profiler. Most of the time the answer is boring: too much work on startup, a list rendering everything, a waterfall of requests that could run together. Boring fixes, measured, are the ones that stick.