The Performance panel records exactly what the browser was doing, moment by moment, letting you pinpoint precisely which function calls are responsible for jank, long tasks, or slow interactions ā replacing guesswork with measured evidence.
1The Performance Profiler | JavaScript Tutorial - In-Depth Guide Part 1
The Performance panel records a timeline of everything the browser did during a session ā JavaScript execution, rendering, painting ā letting you see exactly where time was spent, rather than guessing.
// DevTools workflow:
// 1. Open Performance panel
// 2. Click record
// 3. Perform the slow interaction
// 4. Stop recording, analyze the resultsRecording a Session
2The Performance Profiler | JavaScript Tutorial - In-Depth Guide Part 2
The 'flame chart' visualizes function calls as stacked horizontal bars ā wider bars represent functions that took longer, and stacking shows which functions called which.
// Flame chart reading:
// - Horizontal position = when it ran
// - Width = how long it took
// - Vertical stacking = call hierarchy (who called whom)Reading the Flame Chart
3The Performance Profiler | JavaScript Tutorial - In-Depth Guide Part 3
DevTools flags 'long tasks' (any single task blocking the main thread for more than 50ms) with a red marker, since these are specifically what cause visible jank and delayed input response.
// A red-flagged bar in the timeline means:
// This single task blocked the main thread for 50ms+,
// preventing rendering and input handling during that windowIdentifying Long Tasks
4The Performance Profiler | JavaScript Tutorial - In-Depth Guide Part 4
Clicking on a specific bar in the flame chart reveals exactly which function it represents, its exact duration, and a link to jump directly to that line of source code.
// Clicking a wide bar shows:
// Function: calculateLayout (utils/layout.js:142)
// Self time: 340ms
// Total time: 410ms (including nested calls)Drilling Down to the Culprit
5The Performance Profiler | JavaScript Tutorial - In-Depth Guide Part 5
'Self time' (time spent in that function alone, excluding calls it makes to others) versus 'total time' (including everything it calls) tells you whether to optimize the function itself or one of the things it calls.
// High self time -> optimize THIS function's own logic
// High total time, low self time -> the bottleneck is in what it CALLSSelf Time vs Total Time
6Step-by-Step Breakdown
The Performance panel records a timeline of everything the browser did during a session ā JavaScript execution, rendering, painting ā letting you see exactly where time was spent, rather than guessing.
The 'flame chart' visualizes function calls as stacked horizontal bars ā wider bars represent functions that took longer, and stacking shows which functions called which.
DevTools flags 'long tasks' (any single task blocking the main thread for more than 50ms) with a red marker, since these are specifically what cause visible jank and delayed input response.
Checkpoint: What duration threshold does DevTools typically use to flag a "long task" that blocks the main thread?
- āAbout 50 milliseconds
- āAbout 1 full second
Clicking on a specific bar in the flame chart reveals exactly which function it represents, its exact duration, and a link to jump directly to that line of source code.
'Self time' (time spent in that function alone, excluding calls it makes to others) versus 'total time' (including everything it calls) tells you whether to optimize the function itself or one of the things it calls.
Checkpoint: If a function has high total time but low self time, where is the actual performance bottleneck likely located?
- āIn one of the functions it calls, not the function itself
- āIn that function's own code specifically
Next, we'll explore 'The Memory Profiler'.
Level Up š
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Long Tasks Delay Keyboard and Screen Reader Interaction Just Like Mouse Interaction
A long task blocking the main thread doesn't just cause visible jank for sighted users ā it equally delays the browser's ability to process keyboard navigation and update the accessibility tree, so profiling and fixing long tasks benefits all users, including those relying on assistive technology.
SEO Implications
- 1
Performance Profiling Directly Supports Core Web Vitals Optimization
Identifying and fixing long tasks found via the Performance panel directly improves Interaction to Next Paint, one of Google's Core Web Vitals and a documented search ranking signal.
Best Practices
Record a Focused Session Around Just the Slow Interaction
A shorter, targeted recording (start right before the slow action, stop right after) produces a much easier-to-read timeline than a long, noisy recording covering unrelated activity.
Distinguish Self Time from Total Time Before Deciding What to Optimize
Optimizing a function with low self time but high total time wastes effort ā the real bottleneck lies in whatever it calls, and that's where profiling attention should go instead.
Frequent Bugs
Assuming a wide bar in the flame chart representing high TOTAL time means that specific function's own code is slow, when its self time is actually low and the real cost is in a nested call.
Check the self time versus total time breakdown for the selected function before deciding where to focus optimization effort.
Recording an overly broad performance session covering unrelated page activity, making it hard to isolate the specific slow interaction being investigated.
Start recording immediately before triggering the specific slow interaction and stop immediately after, keeping the timeline focused and easy to read.
Real-World Examples
Diagnosing a Janky Scroll Handler
A page felt sluggish while scrolling, and the team needed concrete evidence of exactly which function was responsible before attempting any fix.
// Recorded a Performance session while scrolling, found a long task
// flagged in red, clicked it, and discovered:
// Function: recalculateStickyHeaderPosition (self time: 180ms)
// -> was reading offsetTop on every single scroll event (forced reflow)