Performance profiling
Recording the browser's work so a vague slowdown becomes a specific script, long task, layout, paint, or network request.
See it
What it is
Performance profiling is recording a page while it loads or responds, then reading the timeline to see where the browser spent time. Chrome DevTools can line up network requests, main-thread tasks, JavaScript call stacks, style recalculation, layout, paint, screenshots, and interactions in one trace. The flame chart, a descendant of Brendan Gregg's flame graphs, turns 'the page is slow' into a particular task, function, or rendering step.
Reach for a profile after you can reproduce a slow load, animation, scroll, or click. Record the smallest useful window, select the bad frame or long task, and compare total time with self time so a wrapper function does not take the blame for work performed by its children.
Gotcha: the recording conditions can become the result. Development builds, browser extensions, warm caches, an open DevTools window, and profiler overhead all change timing. Profile a production build, keep the viewport and throttling fixed, repeat the run, and treat one trace as evidence about that run rather than a universal benchmark.
Ask AI for it
Profile this slowdown in the Chrome DevTools Performance panel against a production build. Reproduce one interaction per recording, add performance.mark() calls immediately before and after the app code in question, and capture screenshots, network activity, and the main thread. In the trace, identify the longest task and bad frame, expand the Bottom-Up and Call Tree views, and report the hottest function by self time as well as its parent by total time. Separate JavaScript, style recalculation, layout, and paint costs. Repeat three times with the same viewport, cache state, and CPU throttle, then change only the largest measured bottleneck and compare the marked duration before and after.