A stakeholder says a page in your web app "feels slow". Walk through the profiling workflow you would follow in the browser, from that complaint to a verified fix.

## Why the workflow matters more than the tricks Performance work fails in a predictable way. Someone hears "the app is slow", remembers an optimization they read about, applies it, and ships. Sometimes the page gets faster; nobody can say why, and the next complaint restarts the cycle. A profiling workflow replaces guessing with a loop that produces evidence at every step: reproduce, quantify, record, isolate the dominant cost, change one thing, re-measure. Interviewers ask for this walkthrough because it separates people who have actually made a page faster from people who have collected tips. ## Step 1 — Turn the complaint into a scenario and a number "Feels slow" is a symptom report, not a bug. Extract four things from whoever reported it: - **Which page or flow**, exactly, and with what data (an empty account and a ten-thousand-row account are different products). - **Which moment feels slow** — the page taking too long to appear at all, or the page appearing and then not responding to a click. Load problems and interaction problems have entirely different causes and entirely different fixes; conflating them is the single most common way an investigation goes nowhere. - **On what device and network**, and whether it happens on the first visit or every visit. "Only the first time" points at download and parse cost; "every time" points at work the page redoes. - **What the target is.** Write it down: "the product list should show its content in under 2.5 s on a mid-range phone over a slow connection". You cannot verify a fix against a feeling. ## Step 2 — Make the environment representative A trace only tells you the truth about the machine and build you recorded. Before recording: - Profile a **production build**. Development builds carry unminified code, development-only warnings, and a hot-reload client — costs no user ever pays, and they can easily dominate the trace. - Use **realistic data volumes**, not a seeded fixture with five rows. - Apply **CPU and network throttling** and start from a **cold cache**, so the recording resembles the device and connection the complaint came from. - Record in a **clean browser profile** with extensions disabled; extensions inject scripts and their cost lands in your trace. ## Step 3 — Record the scenario, and read the trace largest-first Record only the scenario in question, and keep it short — a sixty-second recording is hard to read and the profiler's own overhead grows with it. Then read the trace from the top down, not from the first thing you recognize: 1. Over the span you care about, where did the time actually go? 2. Was the main thread solidly busy, or idle waiting on bytes? 3. What is the single largest contributor, and roughly what share of the total is it? That last question is the whole game. If a page takes four seconds and you find a 40 ms function you know how to make ten times faster, fixing it perfectly buys you 36 ms — invisible. The dominant cost sets the ceiling on any improvement, so it is where the effort goes even when it is the less interesting problem. ## Step 4 — One hypothesis, one change State the hypothesis so it can be wrong: "the hero image is discovered late because it is referenced from a stylesheet, which is why the largest paint lands at 3.4 s", or "parsing the 900 KB analytics bundle is the 700 ms block before first paint". Then make **one** change. Batching five changes and observing a faster page tells you the batch helped; it does not tell you which part helped, which part did nothing, and which part quietly made things worse. ## Step 5 — Re-record the same scenario Same build type, same throttling, same cache state, same data. Compare the same span you measured before. Two outcomes are useful: the number moved and the trace shows the specific cost you targeted shrinking, or it did not move and you revert the change. A change that costs complexity and buys nothing measurable is a net loss, and reverting it is a result, not a failure. ## Step 6 — Repeat, and know when to stop Removing the biggest cost reshapes the trace: work that was hidden behind it becomes the new bottleneck, and it is frequently something you would never have guessed from the first recording. So loop. Stop when you have hit the target you wrote down in step 1, or when the next fix costs more engineering and risk than the milliseconds are worth — that judgment is part of the job, not a cop-out. ## Failure modes worth naming out loud Optimizing before measuring; measuring an environment no user has; fixing the *recognizable* cost instead of the *dominant* one; changing several things at once; declaring victory from a single lucky run; and improving a number while the moment the user actually cares about lands at exactly the same time as before.