Chrome DevTools Performance Insights: Auto-Diagnose LCP, INP, and CLS in 2026

Updated: August 3, 2026

The Chrome DevTools Performance Insights sidebar is a built-in panel that automatically diagnoses your page's Core Web Vitals from a single trace, flagging LCP, INP, and CLS regressions using the same rules Lighthouse ships. In 2026, the sidebar has absorbed almost everything the standalone Performance Insights tab used to offer: subpart breakdowns for LCP and INP, layout-shift clustering, forced-reflow detection, and render-blocking analysis, all annotated directly on the timeline. If you've been round-tripping to Lighthouse for every regression, you can stop.

• The Insights sidebar surfaces the same audits Lighthouse runs (LCP breakdown, INP breakdown, render-blocking, DOM size, forced reflow) without leaving the Performance panel.
• LCP is decomposed into TTFB, resource load delay, resource load duration, and element render delay. Each one has a distinct fix.
• INP is decomposed into input delay, processing duration, and presentation delay, all overlaid on the main thread.
• Layout shifts are grouped into 5-second session windows so you can attribute a CLS score to specific DOM mutations.
• Live Metrics reports field-style LCP, INP, and CLS values as you interact. No recording needed to catch regressions.
• Passed insights collapse into a folded section at the bottom so you only see what actually needs work.

What is the Insights sidebar in Chrome DevTools?

The Insights sidebar is the right-hand column that appears after you record a trace in the Performance panel. It reads the trace, matches known performance patterns against it, and produces a ranked list of audits. These are the same audits Lighthouse ships, but scoped to whatever you just recorded rather than a synthetic full-page load. Each insight expands to show the offending events on the timeline, so clicking "LCP by phase" jumps you straight to the LCP element in the Main track with the four subparts overlaid.

The important shift versus older DevTools versions is that Insights are trace-scoped, not page-scoped. If you record a specific interaction (say, opening a modal) the sidebar tells you what went wrong for that interaction, not what would happen on a cold load from Fast 3G. Honestly, that makes it far better suited for debugging regressions found in real user monitoring, where the failing scenario is usually a specific user path, not a Lighthouse cold start.

Insights that pass are folded into a "Passed insights" section at the bottom. Failed insights sit at the top, sorted by severity. According to the Chrome DevTools Performance reference, the audit set covers LCP subparts, LCP request discoverability, INP subparts, third-party impact, duplicated and legacy JavaScript, render-blocking requests, forced reflow, viewport configuration, and DOM size.

Record a trace the Insights sidebar can actually use

The Insights sidebar is only as good as the trace behind it. Recording with the wrong throttling profile is the single biggest reason developers stare at a green report while their p75 field data is on fire. Before you hit record, configure three things.

First, network throttling. The default is "No throttling," which nearly guarantees your local LCP passes even when it does not on mobile. Switch to "Slow 4G" or, better, use a custom profile that matches the p75 latency you see in your CrUX data. Second, CPU throttling. Set it to 4x or 6x slowdown to approximate a mid-range Android device (the class of hardware INP regressions typically hide on). Third, cache: check "Disable cache" for cold-load traces and uncheck it when you're debugging a warm interaction.

Then start the recording. For load traces, use the reload button in the panel so the trace begins before navigation, capturing TTFB. For interaction traces, hit record, interact, then stop. Don't record for longer than the interaction, or the noise will drown out the signal.

// Optional: script the recording via the DevTools MCP or Puppeteer
// so your CI harness generates traces with consistent throttling.
import { launch } from 'puppeteer';

const browser = await launch({ headless: 'new' });
const page = await browser.newPage();

// Match the throttling you use manually in DevTools
const client = await page.target().createCDPSession();
await client.send('Network.emulateNetworkConditions', {
  offline: false,
  latency: 150,          // ms round-trip
  downloadThroughput: (1.6 * 1024 * 1024) / 8, // Slow 4G
  uploadThroughput:   (750 * 1024) / 8,
});
await client.send('Emulation.setCPUThrottlingRate', { rate: 4 });

await page.tracing.start({ path: 'trace.json', screenshots: true });
await page.goto('https://example.com', { waitUntil: 'networkidle0' });
await page.tracing.stop();

// Open trace.json in the Performance panel. The Insights sidebar
// treats loaded traces identically to live recordings.

How do I fix LCP in Chrome DevTools?

Open the Insights sidebar, click LCP by phase, and DevTools splits your LCP into the four subparts documented in the LCP breakdown reference. There's no overlap between them and they always sum to the full LCP time, which is exactly what makes this view useful. The largest bar is the bottleneck, and each bar has a distinct class of fix.

TTFB (Time to First Byte)

Everything before the first byte of the HTML document lands. Poor-LCP pages spend an average of 2.27 s here, which alone exceeds the 2.5 s "good" threshold. Fixes are server-side: origin cache, CDN edge caching with a permissive Cache-Control policy, faster database queries, or HTTP 103 Early Hints to overlap server think-time with resource discovery.

Resource load delay

Time between TTFB and the moment the browser starts fetching the LCP resource. This is the discovery bar and it's almost always fixable in the HTML. If it is longer than a few hundred milliseconds, the LCP image was probably lazy-loaded, hidden behind a script, or referenced via CSS background-image where the browser preload scanner can't find it. Add <link rel="preload"> with fetchpriority="high", or put a real <img> in the initial HTML with fetchpriority="high". If the delay is zero, the LCP element is text rendered in a system font, so there's nothing to fetch.

Resource load duration

The download itself. If this dominates, the fix is smaller bytes: better image formats (AVIF, WebP), correct srcset for the viewport, and a CDN close to the user. The Insights sidebar's ImageDelivery audit will call out oversized images specifically.

Element render delay

From the byte arriving to paint. Long render delays usually mean the LCP element was blocked behind render-blocking CSS or JavaScript. The RenderBlocking insight lists the offending resources; the fix is inlining critical CSS, adding media queries to non-critical stylesheets, or deferring scripts. For a full walkthrough of these fixes, see our LCP sub-part optimization deep dive.

Diagnosing INP subparts on the main thread

The INP by phase insight decomposes each interaction into three subparts, all rendered as overlays on the Main track so you can see which one collides with which script:

• Input delay. Time from user input to the event handler starting. Usually caused by a long task already on the main thread when the click lands.
• Processing duration. The event handler itself, plus any synchronous work it triggers.
• Presentation delay. From the handler returning to the next paint. Long here means large style recalcs, layout, or heavy off-main-thread rendering costs.

DevTools also draws the Long Animation Frames (LoAF) shaded regions in the Main track, so you can attribute the interaction cost to specific scripts, style, and layout work by hovering the frame. The Interactions track above the Main track shows the interaction rectangle in the same time axis, letting you eyeball which frame owns which subpart.

For anything worse than 200 ms, start by yielding. The scheduler.yield() API breaks up long tasks between the input handler and the follow-up work, letting the browser render the next frame before you continue. If the interaction is running on Safari, use requestIdleCallback or a setTimeout(fn, 0) polyfill. Our INP optimization guide covers the yielding patterns and their fallback strategies. I hit this exact bug shipping a keyboard-heavy autocomplete last year: input delay was 0 ms locally and 340 ms on the mid-range Pixels my users actually held.

// Bad. One 800ms task blocks paint after the click
button.addEventListener('click', () => {
  const results = expensiveCompute();  // 800ms
  renderResults(results);              // paints only after compute returns
});

// Good. Yield after the critical UI update
button.addEventListener('click', async () => {
  showLoadingSpinner();                     // paints immediately
  await scheduler.yield();                  // browser draws the spinner
  const results = await computeInChunks();  // internally yields between chunks
  renderResults(results);
});

async function computeInChunks() {
  const out = [];
  for (const chunk of chunks) {
    out.push(processChunk(chunk));
    if (out.length % 100 === 0) await scheduler.yield();
  }
  return out;
}

CLS clusters and the Layout Shifts track

Open the Layout Shifts track under the Main track and every shift shows up as a red-tinted band. DevTools groups them into 5-second session windows (the same clustering used by the official CLS metric) so you can see which cluster contributed to the reported score.

Clicking a shift reveals the affected DOM node, its previous rectangle, its new rectangle, and (critically) the immediate cause: an inserted element, a resized image without dimensions, a late-loading web font swap, or a scripted style change. Combined with the CLS culprits insight, this is usually enough to attribute a shift to a specific commit within a few minutes. When the culprit is a font swap, see our CLS attribution guide for the font-display and size-adjust combinations that eliminate the shift entirely.

Live Metrics: catching regressions without a recording

The Live Metrics screen sits above the Insights sidebar and updates in real time as you use the page. It reports current LCP, cumulative CLS, and (as soon as you interact) INP, using the same web-vitals library semantics you would deploy in RUM. Two things make it uniquely useful.

First, it captures interactions you'd never think to record. Scroll, hover, keyboard events, focus shifts, all of them count, and the Interactions table below the metric cards lists them with per-interaction timings and phase breakdowns. Second, it exposes conditional regressions. INP that only appears when you have five tabs open, CLS that only fires after a specific ad slot loads, LCP that regresses on a warm cache: Live Metrics catches all three because you interact freely without the observer-effect of a stopwatch recording.

For CI, use the web-vitals library in a Puppeteer script instead. Live Metrics is a manual tool. But for the ad-hoc "why is my dashboard slow today?" question, it beats a recorded trace by orders of magnitude in setup cost.

Beyond Core Web Vitals: forced reflow, DOM size, third parties

The Insights sidebar audits more than the three headline metrics. Five audits are worth memorizing because they catch categories of bug that neither Lighthouse alone nor RUM will surface until it's too late:

• Forced reflow. Flags interleaved DOM reads and writes that trigger synchronous layout. The fix is batching: read all layout properties first, then write. This is the single most common cause of long presentation delays.
• DOM size. Highlights events that were made slower by an oversized DOM. If your page has more than ~1,500 nodes and you see this flagged, virtualization or CSS content-visibility: auto is the fix.
• Third parties. Attributes main-thread time to specific third-party scripts by origin. Great for justifying "we need to remove this analytics script" to a stakeholder.
• Duplicated JavaScript. Catches the classic React-in-your-bundle-twice regression that ships when a subpackage bundles its own copy of a shared dependency.
• Legacy JavaScript. Flags ES5-transpiled polyfills served to modern browsers. Modern-only builds via <script type="module"> plus a nomodule fallback usually cut 20 to 40 KB.

A realistic 2026 debugging workflow

The workflow below is what I run when a Web Vitals alert fires in RUM. It's deliberately short: the point is to reach a diagnosis in under ten minutes.

1. Reproduce the exact scenario. Pull the failing URL, referrer, and viewport from your RUM. Open DevTools, set throttling to match the p75 device (Slow 4G, 4x CPU is a safe default).
2. Record from reload. Click the reload button in the Performance panel so the trace captures TTFB. Stop after the interaction that reproduces the regression.
3. Read the Insights sidebar top-down. The failing insight at the top is usually the fix. If it is LCP by phase, look at the largest bar. If it is INP by phase, look at which subpart dominates. If it is CLS culprits, click through to the shifted element.
4. Cross-check with Live Metrics. Interact with the page manually. Sometimes the recorded interaction wasn't the one that regressed in the field.
5. Ship a fix behind a feature flag. Deploy to 1% of traffic, watch CrUX weekly. Local traces confirm the mechanism; only field data confirms the outcome.

This loop replaces roughly three tools I used to reach for: standalone Lighthouse, WebPageTest for waterfalls, and Chrome's discontinued Performance Insights tab. Everything except the field-data step now lives in one panel, which (in my experience) is the single biggest reason my team stopped opening five tabs for every perf ticket.

Frequently Asked Questions

What replaced the Performance Insights panel in Chrome?

The standalone Performance Insights tab was folded into the main Performance panel as the Insights sidebar in Chrome 129 and formally deprecated shortly after. Every audit the old tab surfaced (LCP breakdown, INP breakdown, render-blocking, DOM size, forced reflow) now lives in the sidebar of the main Performance panel, with the same data and slightly better timeline integration.

Can Chrome DevTools measure INP without a real user?

Yes. The Live Metrics screen reports INP as soon as you interact with the page during a DevTools session, using the same p98-of-interactions calculation the web-vitals library uses in production. For scripted CI measurement, drive interactions with Puppeteer and read metrics via the web-vitals library rather than the DevTools UI.

Why does my LCP differ between DevTools and CrUX?

DevTools reports a single lab measurement under whatever throttling you chose, while CrUX aggregates real Chrome users at p75. Common causes of divergence: your throttling profile is too fast, your machine is faster than a p75 phone, you tested a warm cache, or the failing user path is not the one you recorded. Treat DevTools as the mechanism explanation and CrUX as the ground truth for whether users notice.

Does the Insights sidebar work on loaded trace files?

Yes. You can drag any .json trace generated by DevTools, Puppeteer's page.tracing, or the DevTools MCP into the Performance panel and the sidebar analyzes it identically to a live recording. This makes it practical to attach traces to bug reports and have every engineer see the same insights without re-recording.

How is the Insights sidebar different from Lighthouse?

Lighthouse always runs a synthetic full cold-load audit and scores against fixed thresholds. The Insights sidebar audits whatever trace you recorded, whether that's a specific interaction, a warm reload, or a subroute, using the same audit rules. Lighthouse is best for regression gating and public reports; the sidebar is best for debugging a specific failing scenario.