Chrome DevTools Performance Panel: Record and Analyze Web Vitals

Open Chrome DevTools by pressing F12 on Windows and Linux, or Cmd+Option+I on macOS. You can also right-click anywhere on the page and choose "Inspect", then navigate to the Performance tab. If the Performance tab is not visible in the tab bar, click the double-arrow overflow icon (>>) on the right side of the tab strip -- the panel is there but hidden due to narrow window width.

For the most usable timeline view, dock DevTools to the bottom of the browser window rather than the right side. A wider horizontal layout gives you more horizontal space in the timeline, making it easier to spot individual events and read the flame chart. You can change the dock position from the three-dot menu in the top-right of the DevTools panel.

Before starting any recording, configure the checkboxes in the Performance panel toolbar. The three most important options are Web Vitals, Screenshots, and Memory. Each adds a separate lane to the timeline that gives you additional context when analyzing the recording.

The Web Vitals checkbox adds a dedicated lane at the very top of the timeline. This lane displays the LCP event as a blue diamond, layout shift events as pink regions, and INP measurements for any interactions recorded. Without this lane enabled, you would need to hunt for these events manually in the flame chart. Screenshots adds a filmstrip across the top of the timeline -- small thumbnail frames captured at regular intervals that let you see exactly what the user was seeing at any point in time. Memory adds a heap allocation graph that helps identify memory leaks and garbage collection pauses that cause visual jank.

To capture a full page-load trace from a cold cache, click the reload button (the circular arrow icon, not the plain record circle). DevTools will automatically disable the cache, reload the page, record the entire loading sequence, and stop recording once the page becomes idle. This gives you an accurate measurement of what first-time visitors experience.

Wait until the recording completes and the timeline renders before interacting with the panel. On pages with heavy JavaScript, this can take 10-20 seconds. Once the timeline appears, you will see colored sections across the top representing CPU activity, a filmstrip if Screenshots was enabled, and the various lanes below (Web Vitals, Main, Interactions, Network, Frames).

// Step-by-step recording checklist:

1. Open DevTools (F12) and go to Performance tab
2. Check: Web Vitals, Screenshots, Memory
3. Set CPU throttle: 4x slowdown (mid-range mobile)
4. Set Network: Fast 3G or Slow 4G
5. Click the RELOAD button (circular arrow)
   -- NOT the plain record circle --
6. Wait for recording to stop automatically
7. The timeline renders -- do not click yet
8. Zoom to the first 5 seconds for LCP analysis:
   click and drag on the filmstrip row

The Web Vitals lane is the most important place to start. Locate the blue diamond -- that is the LCP event. Hover over it to see a tooltip showing the LCP element (e.g., img.hero-image or h1.page-title) and the exact timestamp in milliseconds. Click the diamond to pin the detail in the bottom pane, which shows the element's full CSS selector, its size, and whether it was loaded from the network or from cache.

Layout shift events appear as pink highlighted regions in the Web Vitals lane. Each region represents one or more layout shifts that contributed to your CLS score. Click a layout shift region to see the affected elements in the detail pane -- you will see each element's ID or class, its previous bounding box, its new bounding box after the shift, and its individual impact score. This information is exactly what you need to trace CLS back to a missing image dimension, a late-loading font, or a dynamically injected banner advertisement.

The Main lane contains the JavaScript execution flame chart -- the single most useful section for diagnosing slow interactions and render-blocking work. Expand the Main lane by clicking the triangle next to it. Long tasks appear as wide gray bars with a red triangle in the top-right corner. Any task that takes more than 50ms is considered long because it blocks the browser from responding to user input for that duration.

Click on any long task bar to select it. The detail pane at the bottom will show the total duration and a call stack summary. Switch to the Bottom-Up tab to see functions sorted by self time (time spent executing that function itself, not counting sub-calls). This is the quickest way to identify the exact function doing expensive work. Switch to the Call Tree tab to trace the full execution path from the top-level event handler down to the costly function. If your source maps are configured correctly, function names and file paths will be readable rather than minified.

// In the detail pane (bottom panel), four tabs are available:

Summary     -- Total time breakdown: scripting, rendering, painting, idle
Bottom-Up   -- Functions sorted by self time (best for finding root cause)
Call Tree   -- Top-down execution path from the event root
Event Log   -- Chronological log of all events in selected time range

// Workflow for diagnosing a long task:
1. Click the long task bar in the flame chart
2. Open "Bottom-Up" tab
3. Sort by "Self Time" column (click header)
4. The top row is the most expensive function
5. Click the "..." disclosure to expand and see the full call path
6. Click the source link on the right to jump to the code

// Enable source maps for readable function names:
DevTools Settings > Preferences > Sources > Enable JavaScript source maps

INP (Interaction to Next Paint) measures the latency of the worst user interaction during a page visit. Unlike LCP, INP cannot be observed in a standard page-load recording -- you need to start a recording and then interact with the page. Click the plain record button (not the reload button), then perform realistic interactions: click buttons, open dropdown menus, type in search inputs, dismiss dialogs, and toggle filters. Stop recording after 30-60 seconds of interactions.

In the resulting timeline, expand the Interactions track. Each interaction appears as a horizontal bar. The bar's total length represents the full interaction latency from the user's input event to the browser's next paint. The bar is color-coded: green means the interaction was under 200ms (Good), yellow means 200-500ms (Needs Improvement), and red means over 500ms (Poor). Click any interaction bar to see a three-part breakdown in the detail pane: Input Delay (time from event to event handler start), Processing Time (event handler execution), and Presentation Delay (time from handler end to paint). Most INP problems stem from long Processing Time caused by heavy JavaScript in event handlers, or from long Presentation Delay caused by expensive style recalculation or layout work triggered by DOM mutations.

// INP score thresholds
Good:              < 200ms   (green)
Needs improvement: 200-500ms (yellow)
Poor:              > 500ms   (red)

// The three phases of an interaction (click the bar to see):
1. Input Delay
   -- From: user presses button / mouse click
   -- To:   event handler starts executing
   -- Caused by: main thread busy with another task
   -- Fix: reduce long tasks; defer non-critical JS

2. Processing Time
   -- From: event handler starts
   -- To:   event handler finishes (all microtasks done)
   -- Caused by: heavy synchronous JS in click handlers
   -- Fix: yield with scheduler.yield() or setTimeout(fn,0)

3. Presentation Delay
   -- From: handler finishes
   -- To:   browser paints the next frame
   -- Caused by: layout thrashing, expensive CSS recalcs
   -- Fix: batch DOM writes; avoid layout-triggering reads
              inside animation frames

Performance metrics measured on a developer machine -- typically a fast laptop with a wired or Wi-Fi connection -- will be dramatically better than what median real users experience. A developer machine runs JavaScript 5-10x faster than the median Android phone used by mobile visitors. Without throttling, you risk declaring performance "good" in your lab tests while real users on mobile are experiencing Poor ratings in the field.

The CPU throttle dropdown is in the Performance panel toolbar. Select 4x slowdown to approximate a mid-range Android phone (the recommended setting for general mobile testing, and the value Lighthouse uses). Select 6x slowdown for low-end device simulation. The Network throttle is adjacent: choose Fast 3G (1.6 Mbps down, 750 Kbps up, 150ms latency) or Slow 4G for mobile testing, and leave it at No Throttling for desktop users. Apply both CPU and network throttling simultaneously -- each alone is an incomplete simulation.

After capturing a recording that shows a problem, save it immediately before closing DevTools. Click the download icon (or press the Save Profile button) in the Performance panel toolbar. DevTools exports the recording as a .json file -- these files can range from a few hundred kilobytes to tens of megabytes depending on the recording length and the amount of data captured.

Share the exported .json file with teammates or attach it to a GitHub issue or Jira ticket. Anyone can load it back into Chrome DevTools via the upload icon in the Performance panel, without needing to reproduce the issue themselves. This is invaluable for async collaboration -- a back-end engineer can open the profile and see exactly which JavaScript function is the bottleneck, even without access to the production environment. Saved profiles also provide a performance baseline: record a profile before and after an optimization, then compare the two side by side to confirm that long tasks shortened and metric markers moved left.