You Are Recording the DevTools Performance Profile Wrong

The team optimised the page for two weeks using the DevTools Performance panel, shipped, and the real user metrics did not move. The profile had been honest. The recording had been of a state no user experiences: warm cache, full speed CPU, logged in session, mid scroll. The two seconds it showed were real and irrelevant, and the optimisation followed them, which is how a correct tool produces a wasted fortnight.

The Performance panel is the best instrument for frontend latency, and it is also the easiest instrument to lie with, accidentally, because every setting is a claim about the user, and the defaults claim a user who does not exist.

This was Chrome 133, and the discipline below is the difference between a profile and a measurement.

The cold start you never record

The default recording happens after you have been on the page for minutes, with the cache warm and the JavaScript compiled. Your users' worst and most common first impression is the cold load: empty cache, first parse, first compile. A profile that does not include the cold start is a profile of the return visit, which is usually the fast case.

Record with the cache disabled in the panel's network settings, and reload inside the recording so the trace contains the full cold path. The difference between the warm and cold traces is precisely the work your first time user pays, and it is routinely the largest gap in the whole profile, invisible in every warm recording.

The CPU your users do not have

The second default lie is full speed. The panel's CPU throttling exists because your development machine is the fastest device that will ever run your code, and the median phone is a fraction of it. A main thread task that is forty milliseconds on your laptop is two hundred on the mid range Android, which is the device your p75 lives on.

Record at the throttling level that matches the device you optimise for, commonly four to six times, and read the long tasks under that lens. The hotspots reorder under throttling, because parse and compile scale with CPU while network does not, and the reordering is the point. Optimising from an unthrottled profile is optimising for the one device that was never slow.

The state that is not the user's

The third lie is session state. Logged in, mid scroll, with data already fetched, the page renders a fragment of the real cost. The first paint for a logged out visitor, or the first render with an empty then filling dataset, has a different shape, and the skeleton to content transition is where the layout shifts and the late work live.

Record the states separately: logged out cold, logged in cold, and the interaction you care about, and label the recordings, because an unlabelled trace is a fact without its context, and the context is half the diagnosis.

The interaction, not just the load

Load profiles get the attention, but the interaction profile is where the responsiveness complaints live. Record the tap, the scroll, the input, and read the gap between the input event and the first frame of response, which is the INP story. A profile of the load will never show the handler that blocks for three hundred milliseconds on the variant tap, and that handler is the complaint.

Use the panel's interaction markers and the long task annotations, and reproduce the exact gesture the user reported, because "the page is janky" becomes a named task with a stack when the gesture is in the trace.

The comparison discipline

A profile is a sample of one run, and one run is noise. The discipline that turns it into evidence is the pair: record the same scenario before and after the change, with the same throttling, cache state and session, and compare the specific numbers, the long task durations, the time to first frame, the interaction latency. The delta is the claim you are shipping, and without the before recording the after recording is an anecdote.

Repeat each scenario a few times, because the first recording includes the tool's own warmup, and report the median, because the outlier run is the browser doing something else, not your code.

The traps in reading

Two reading traps waste the most time.

The waterfall's longest bar is not always the cause. A long task can be long because it waits on a layout triggered earlier, and fixing the bar without the trigger reproduces it elsewhere. Read the call stack and the causation, not the bar lengths alone.

And the network row and the main thread row must be read together. A script that is cheap to run but late to arrive is a delivery problem, and a script that arrives early and burns the main thread is a code problem, and the two have opposite fixes. The panel shows both, and the diagnosis is in their alignment.

What I now do

The Performance panel measures the state you record, and the defaults record a state no user meets. Disable the cache, throttle the CPU to the device you optimise for, record the cold and the interaction separately and labelled, and compare before against after on the same scenario, because the delta under the user's conditions is the only number that ships.

The warm, unthrottled, mid session profile is a portrait of your laptop, and your laptop was never the complaint. The field view that confirms the lab is the p75 in your average latency is fine and your users are not.

There is one more setting worth naming because it silently invalidates recordings: the difference between a recording made with the page focused and one made while the tab was backgrounded, because browsers throttle timers and rAF in background tabs, and a profile captured from a tab you switched away from shows artificial long gaps that are the browser's politeness, not your code. Keep the tab focused for the whole recording, and discard any trace where you looked at another window, because the cheapest way to corrupt a profile is to keep working while it runs.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud