Chrome DevTools Performance Panel

TL;DR — The Performance panel is a tool built into Chrome (open DevTools, click Performance) that records exactly what your browser does while a page loads — every script, every network request, every paint. Unlike PageSpeed Insights, it doesn’t give you a score; it gives you the raw picture so you can find why a page is slow. Important: it shows what your browser does, not what Google’s crawler does, and it’s free with no account.

What it is

Chrome DevTools has a lot of tabs. The Performance panel is the one for recording how a page loads and runs, then digging into the detail. It captures your browser’s work over time — downloading files, running JavaScript, laying out and painting the page — and lays it out as a timeline you can zoom into.

Think of the difference this way. PageSpeed Insights and Lighthouse are like a report card: they run a test and hand you a score plus a to-do list. The Performance panel is like a security-camera recording of the whole page load — no score, but you can rewind and see the exact moment something went wrong.

How to open it and what you see first

1. Open DevTools (right-click the page → Inspect, or press Cmd+Option+I on Mac / Ctrl+Shift+I on Windows).
2. Click the Performance tab at the top.

The moment you open it, the panel already shows you your page’s Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) — two of the three Core Web Vitals — measured live in your own browser. Click around the page and it picks up Interaction to Next Paint (INP) too. You get a snapshot of your local Core Web Vitals without recording anything.

Recording a page load

To see the full story of a load, click Start profiling and reload page (turn on the Screenshots checkbox first so you also get a filmstrip of what the page looked like at each moment). The panel reloads the page and records everything. When it stops, you get a dense timeline: colored bars showing scripting, rendering, and painting; a strip of screenshots across the top; and a network section showing what loaded when.

It looks intimidating the first time. The one thing most SEOs actually come here to do is simple, and I’ll walk through it in the Advanced tab: find the exact element that was your LCP — the biggest thing the page painted — so you know what to optimize.

The thing people get wrong

The Performance panel shows what your Chrome browser does — not what Googlebot does. Googlebot renders pages with its own system (the Web Rendering Service), which isn’t identical to your full desktop browser. So the panel is fantastic for diagnosing speed and understanding rendering, but it is not a way to confirm what Google can actually crawl and index. For that you use Google Search Console’s URL Inspection tool.

Want the full walkthrough — reading the flame chart, the Insights sidebar, finding your LCP element, throttling to simulate a slow phone, and how this compares to Lighthouse and WebPageTest? Switch to the Advanced tab.

TL;DR — The Performance panel is Chrome DevTools’ built-in, local profiler. Open it and it shows live local LCP/CLS (and INP once you interact); hit Start profiling and reload page (with Screenshots on) to record a full load. You read a flame chart of main-thread work, an FPS/CPU timeline, a network waterfall, and analysis tabs (Bottom-up, Call Tree, Event Log), plus an Insights sidebar that breaks LCP into its four sub-parts and flags render-blocking requests, forced reflow, and third-party cost. It’s the fastest built-in way to pinpoint your exact LCP element. Three things to keep straight: it profiles your browser, not Googlebot’s Web Rendering Service; the recorded trace is lab evidence, and while the panel can optionally show real-user CrUX field data alongside it, that field overlay is not the same measurement as your local trace; and the old standalone Performance Insights panel was removed in Chrome 132 — those features now live inside this panel’s Insights tab. Throttling multipliers are relative to your machine, not an absolute benchmark.

What the Performance panel actually is

Google’s framing is plain: “Use the Performance panel to analyze your website’s performance” and “The Performance panel lets you record CPU performance profiles of your web applications” (Chrome DevTools docs). It’s a profiler — you record a trace of everything the browser does over a slice of time, then explore that trace.

It’s worth positioning against its siblings up front, because people conflate them constantly:

• Lighthouse / PageSpeed Insights run an automated audit and give you a score plus prioritized recommendations (PSI also adds real CrUX field data). Scored, automated, opinionated.
• WebPageTest runs your page on a remote real device, records historical, shareable results, and supports multi-step scripting. Remote, shareable, thorough.
• The Performance panel gives you a raw, interactive trace from your own local browser — no score, no account, no remote machine. Deeper and more flexible, but you do the interpreting.

The recorded trace itself is local, lab evidence — a snapshot of your one browser, device, and network at that moment. But the panel around it isn’t purely a lab tool: since the redesign it can also show optional real-user CrUX field metrics alongside your local results. Keep the two straight — local lab vs. remote lab vs. real-user field — because that distinction is the spine of the whole web performance tools cluster, and it’s what the myths below turn on.

A brief history (so you know which panel you’re even looking at)

The panel has been around a long time. Elizabeth Sweeny and Paul Irish of the Chrome DevTools team put it this way: “The Performance panel in Chrome DevTools has been helping developers measure and optimize their runtime performance in one form or another for the better part of 15 years,” and “Starting with a panel called ‘Timeline’, it evolved to the Performance panel you know today” (Performance tooling in 2024 and beyond). Along the way, as they note, “Lighthouse was launched in 2016 to help spot optimization opportunities more easily,” and “The experimental Performance Insights panel was released in 2022 to test new ways of surfacing performance insights.”

That last one matters for currency. The standalone Performance Insights panel was an experiment, and it’s gone: Google’s own notice states that “The Performance insights panel is deprecated and removed from DevTools starting with Chrome version 132. We recommend you use the Performance > Insights tab instead” (deprecation notice). If a tutorial or screenshot you’re following shows a separate “Performance Insights” panel, it predates Chrome 132 and is stale — the insights now live in a sidebar inside the regular Performance panel.

Opening it and the live metrics screen

Open DevTools and select Performance from the tabs at the top. As Google describes it, “When you open the Performance panel, it immediately captures and shows you your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics,” and “If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INP)” (overview docs). This landing screen is part of the redesign Rick Viscomi described as “a completely redesigned Performance panel landing page featuring a live view of your local Core Web Vitals performance” (Monitor your local and real-user Core Web Vitals in DevTools). So before you record anything, you already have your full set of local Core Web Vitals.

Recording a trace: runtime vs. load

There are two things you can record, and the distinction matters:

• Runtime performance — the page is already loaded and you want to profile it while it runs (an animation, a slow interaction, a scroll jank). Google: “Runtime performance is how your page performs when it is running, as opposed to loading” (Analyze runtime performance).
• Load performance — you want the whole story from a fresh navigation. Click Start profiling and reload page. Turn on Screenshots first so you get a filmstrip of visual frames alongside the trace.

For SEO work — LCP, layout shift, render-blocking scripts — you almost always want the load recording with screenshots on.

A trace only contains what happened inside its recording window — whatever you didn’t capture (an interaction outside the window, lazy-loaded work that fires later) is simply unobserved, not absent. If you want a trace you or someone else can reproduce or compare later, note down: the Chrome version and the date (labels, shortcuts, and the exact UI shift release to release), whether screenshots were on, your CPU/network throttling settings, and whether you left the advanced paint/CSS instrumentation and JavaScript sampling options at their defaults — each of those adds detail and overhead, so a trace recorded with different settings isn’t directly comparable to one recorded without them.

Reading the trace

A recording gives you several stacked tracks. The main ones:

• The flame chart / Main track. This is the heart of it. Google: “DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time,” and “Use the Main track to view activity that occurred on the page’s main thread” (features reference). Time runs left to right; the stack of bars under each moment is the call stack. A wider bar = a longer-running task — that’s where your time went. That nesting shows you trace structure — what called what, and when — but it isn’t by itself proof that a parent task caused a broader user-experience problem; treat it as the starting point for a hypothesis, then confirm.
• The FPS chart. A quick read on jank. Google: “Whenever you see a red bar above FPS, it means that the framerate dropped so low that it’s probably harming the user experience” (runtime docs). You’re aiming for a smooth 60 FPS; red bars mark the rough spots.
• The CPU chart shows how busy the main thread was over the recording.
• The Network track is a waterfall of every request — what loaded, when, and in what order (this is where render-blocking resources show up).
• The Timings track surfaces custom performance.mark() measurements if your app emits them.

Below the flame chart, three analysis tabs slice the same data differently:

• Bottom-up — “Use the Bottom-up tab to view which activities directly took up the most time in aggregate.” Best for “what single function is eating my time?”
• Call tree — “Use the Call tree tab to view which root activities cause the most work.” Best for “which top-level task kicked all this off?”
• Event log — the same events in chronological order.

The Insights sidebar

The redesign’s most useful addition for diagnosis is the Insights sidebar — the successor to the removed standalone Performance Insights panel. Instead of you hunting through the flame chart, it surfaces specific, named problems. The ones that matter most for SEO:

• LCP breakdown. Google splits LCP into four sub-parts — time to first byte, resource load delay, resource load time, and element render delay (LCP breakdown insight). This tells you why your LCP is slow (server? a late-loading image? render blocking?) rather than just that it’s slow.
• Render-blocking requests — the CSS/JS that delayed the first paint (render-blocking insight).
• Forced reflow — where the browser had to pause script to recalculate layout.
• Third-party cost — how much your embeds, tags, and widgets are costing you.

Because these are surfaced automatically, the Insights sidebar is the closest the Performance panel gets to Lighthouse’s “here’s what to fix” experience — while still letting you drop into the raw trace behind any insight.

Treat each insight as a guided hypothesis, not proof. It identifies a potential issue and connects you to the trace context behind it, but flagging an item isn’t the same as proving that item caused the outcome you’re chasing, or that fixing it will. Confirm with the trace itself — and with a before/after re-recording — before you tell a client or teammate an insight is the cause.

CPU and network throttling (and the caveat that trips people up)

Your dev machine is far faster than a typical phone, so a page that feels instant to you can be painful for real users. Throttling simulates weaker conditions: a CPU slowdown multiplier and a network profile (Slow 4G, etc.).

The catch, straight from Google: “Throttling is relative to your computer’s capabilities. For example, the 2x slowdown option makes your CPU operate 2 times slower than its usual ability” (features reference). That means a “4x slowdown” is not an absolute benchmark — 4x on a fast laptop and 4x on a weak one aren’t the same result. It’s a relative dial, not a standard you can compare across machines. A second, practical use DebugBear points out in their deep DevTools walkthrough: throttling can also just slow the recording down so dense clusters of events are legible.

Lab data here vs. field data Google ranks on

This is where SEOs get burned. The Performance panel’s numbers — the live metrics and every recording — are lab data from your machine, on your network, at that moment. Google’s actual Core Web Vitals ranking signal comes from real-user CrUX field data (a 28-day aggregate of real Chrome users), which you see in Search Console and PageSpeed Insights. A perfect local recording does not guarantee a passing field score — real users have slower devices, worse networks, and more variety than your one test.

The redesigned panel actually bridges this: since the update, it can show your real-user CrUX field data right alongside your local results, so you can compare “what I just measured” against “what real users experience.” When that field overlay is available, you can switch it between the URL and origin level and between mobile and desktop, and the UI exposes the data period it’s drawing from — so match those to the trace you’re comparing it against. Even matched that way, field-informed environment settings (throttling presets the panel recommends based on CrUX) approximate a selected real-user segment; a single local recording still doesn’t recreate the underlying population distribution or predict a ranking outcome. That overlay is the clearest built-in reminder that your local trace and Google’s ranking signal are two different numbers. For the full lab-vs-field treatment, see the web performance tools hub and the sibling Core Web Vitals and CrUX explainers.

How I use it for technical SEO

I’ve leaned on the Performance panel for years — not as a standalone deliverable, but as the tool I reach for when a score isn’t enough and I need to see the actual mechanics. A few concrete uses:

Finding the exact LCP element. This is the single most valuable SEO trick in the panel, and it’s a recipe I’ve taught from stage. In my Page Experience Update (TMC, June 2021) deck, the steps are: Performance > check “Screenshots”, click “Start profiling and reload page”, find LCP on the timing graph, then click the node — this is the element for LCP. DevTools tells you precisely which element Google would count as your Largest Contentful Paint, so you know exactly what to optimize. Richie Lauridsen of Seer Interactive describes the same technique in Search Engine Journal: “In hovering over the flag for LCP, we can actually see the piece of content flagged to be the largest contentful paint during the page load” (3 Ways to Use Chrome DevTools for SEO Troubleshooting). That two independent write-ups land on the same recipe tells you it’s a standard workflow, not a one-off.

Explaining rendering to people. In my JavaScript SEO guide I use the panel to make the rendering pipeline visible: “In Chrome Dev Tools, if you run a test on the ‘Performance’ tab, you get a loading chart.” Walking through that chart — download, HTML parse, JS execution, layout, paint — is how I explain to clients and colleagues that Googlebot’s rendering doesn’t do everything a full browser paint does, which is central to diagnosing JS SEO problems.

Spotting render-blocking third parties and diagnosing layout shift round it out: the network waterfall shows what’s holding up the first paint, and the trace (plus the CLS metric) shows what shifted and when.

The Googlebot myth (the one to actually internalize)

Here’s the trap: “if it looks fine in my Performance panel, Googlebot sees it fine too.” It doesn’t follow. The panel profiles your local, full-featured Chrome. Googlebot renders with the Web Rendering Service, a recent-but-not-identical Chromium build that doesn’t support everything a full browser does and behaves differently (it’s stateless, denies permission prompts, and so on — see crawling and rendering). The Performance panel is superb for understanding and diagnosing rendering behavior; it is not a substitute for confirming what’s actually crawlable and indexable. For that, use Search Console’s URL Inspection tool or a raw fetch.

A quick disambiguation footnote

Don’t confuse the Performance panel with the Performance monitor — a separate, smaller DevTools feature that shows a live strip of real-time metrics (CPU usage, JS heap, DOM nodes) rather than a recorded trace. Same word, different tool.

AI summary

A condensed take on the Advanced version:

• What it is: the Chrome DevTools Performance panel is a built-in, local profiler. Open DevTools → Performance. It records how a page loads and runs; it does not produce a score. The recorded trace is local, lab evidence, though the panel can optionally show CrUX field data alongside it.
• Positioning: Lighthouse/PageSpeed Insights = scored automated audit (+ CrUX field data); WebPageTest = remote real-device lab; the Performance panel = raw interactive trace from your own browser.
• Live metrics: on open it shows local LCP and CLS; interacting adds local INP — full local Core Web Vitals without recording.
• Recording: runtime (page already running) vs. load (Start profiling and reload page, with Screenshots on for a filmstrip).
• Reading a trace: flame chart of main-thread work (wider bar = longer task), FPS chart (red = jank, target 60 FPS), CPU chart, Network waterfall, Timings; plus Bottom-up / Call Tree / Event Log analysis tabs.
• Insights sidebar (replaced the standalone Performance Insights panel, removed in Chrome 132): LCP breakdown into 4 sub-parts, render-blocking requests, forced reflow, third-party cost. Treat each insight as a guided hypothesis, not proof of cause — confirm with the trace and a before/after re-recording.
• Throttling is relative to your machine, not an absolute benchmark — “4x” on a fast laptop ≠ “4x” on a weak one.
• Lab ≠ field: the recorded trace is lab data; Google ranks on real-user CrUX field data. The redesign can show CrUX next to your local results (matched by URL/origin, form factor, and period) — an approximation of a real-user segment, not a recreation of it.
• SEO uses: pinpoint the exact LCP element (Patrick’s slide recipe, corroborated by SEJ’s Richie Lauridsen), spot render-blocking third parties, diagnose layout shift, explain rendering.
• Myth to bust: it shows your browser, not Googlebot’s Web Rendering Service — confirm crawlability with URL Inspection, not DevTools.

Official documentation

Primary-source documentation from the Chrome DevTools team.

Chrome / Google

• Performance panel overview — what it is, how to open it, and the live local LCP/CLS/INP metrics.
• Analyze runtime performance — recording, the flame chart, FPS/CPU, and the runtime-vs-load distinction.
• Performance features reference — the Main track, Bottom-up, Call Tree, Event Log, and throttling definitions.
• Performance insights (deprecation notice) — the standalone panel was removed in Chrome 132; use Performance > Insights instead.
• LCP breakdown insight — LCP split into TTFB, resource load delay, resource load time, and element render delay.
• Render-blocking requests insight — identifying the CSS/JS that delays first paint.
• Monitor your local and real-user Core Web Vitals in DevTools — Rick Viscomi on the redesigned landing page and the CrUX field-data overlay.
• Performance tooling in 2024 and beyond — Elizabeth Sweeny & Paul Irish on the Timeline → Performance history and where Lighthouse/Insights fit.
• A 400% faster Performance panel — engineering deep-dive; evidence the panel is actively invested in and changes release-to-release.
• Performance monitor — the separate real-time metrics strip, not the main Performance panel (disambiguation).

Bing / Microsoft

• No Bing-specific documentation on the Chrome/Edge DevTools Performance panel exists — this is a browser tool, not a search-engine product. Chromium-based Edge ships a near-identical DevTools with the same Performance panel, so everything here applies there too.

Quotes from the source

On-the-record statements from the Chrome DevTools team and industry practitioners. Each Chrome link is a deep link that jumps to the quoted passage.

Chrome DevTools — what the panel is and how to read it

• “Use the Performance panel to analyze your website’s performance.” / “The Performance panel lets you record CPU performance profiles of your web applications.” — Chrome DevTools docs. Jump to quote
• “When you open the Performance panel, it immediately captures and shows you your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics.” / “If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INP).” Jump to quote
• “Runtime performance is how your page performs when it is running, as opposed to loading.” / “DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time.” Jump to quote
• “Whenever you see a red bar above FPS, it means that the framerate dropped so low that it’s probably harming the user experience.” Jump to quote
• “Use the Main track to view activity that occurred on the page’s main thread.” / “Use the Bottom-up tab to view which activities directly took up the most time in aggregate.” / “Use the Call tree tab to view which root activities cause the most work.” Jump to quote
• “Throttling is relative to your computer’s capabilities. For example, the 2x slowdown option makes your CPU operate 2 times slower than its usual ability.” Jump to quote

Chrome DevTools — history and the currency note

• “The Performance panel in Chrome DevTools has been helping developers measure and optimize their runtime performance in one form or another for the better part of 15 years.” / “Starting with a panel called ‘Timeline’, it evolved to the Performance panel you know today.” — Elizabeth Sweeny & Paul Irish, Chrome DevTools team. Jump to quote
• “The Performance insights panel is deprecated and removed from DevTools starting with Chrome version 132. We recommend you use the Performance > Insights tab instead.” Jump to quote
• “a completely redesigned Performance panel landing page featuring a live view of your local Core Web Vitals performance.” — Rick Viscomi, Chrome team. Read the post

Industry — the SEO workflow

• “In hovering over the flag for LCP, we can actually see the piece of content flagged to be the largest contentful paint during the page load.” — Richie Lauridsen (Seer Interactive), Search Engine Journal. Read the article

Patrick Stox — using the panel

• “In Chrome Dev Tools, if you run a test on the ‘Performance’ tab, you get a loading chart.” — used in my Ahrefs JavaScript SEO guide to explain how Googlebot’s rendering differs from a full browser paint.

Which performance tool should I reach for?

The panel is one option among several, and picking the wrong one wastes time. A quick way to decide:

Do you need a score or a diagnosis?

• A score / pass-fail verdict for ranking → you want field data: PageSpeed Insights or Search Console’s Core Web Vitals report (CrUX). The Performance panel won’t give you this.
• A diagnosis of why a page is slow → keep going.

Is the page publicly reachable?

• No (behind a login, staging, localhost) → the Performance panel (or Lighthouse in DevTools) is your tool — it runs on whatever’s in your browser. PSI and WebPageTest need a public URL.
• Yes → either the Performance panel or a remote tool works; keep going.

Do you need a shareable, real-device, repeatable result?

• Yes (client report, real hardware, historical trend) → WebPageTest.
• No — you just need to see the mechanics right now → the Performance panel.

What specifically are you trying to find?

• “Which element is my LCP?” → Performance panel: Screenshots on → Start profiling and reload → click the LCP node on the timing graph.
• “What’s blocking my first paint / costing me third-party time?” → Performance panel → Insights sidebar (render-blocking requests, third-party cost).
• “A prioritized to-do list of fixes” → Lighthouse / PageSpeed Insights.
• “What can Googlebot actually crawl/render?” → not this panel — use Search Console’s URL Inspection tool.

Rule of thumb: field tools tell you whether you have a problem and whether it affects ranking; the Performance panel tells you why — down to the exact function, request, and element.

Performance panel cheat sheet

Getting in

Reading a trace

Find your LCP element (the SEO recipe)

1. Turn on Screenshots.
2. Click Start profiling and reload page.
3. Find LCP marked on the timing graph.
4. Click the node — DevTools shows the exact LCP element.

Fast facts / don’t-get-burned

• The recorded trace is local, lab data — not the CrUX field data Google ranks on, though the panel can optionally show field data alongside it.
• It profiles your browser — not Googlebot’s Web Rendering Service.
• The standalone Performance Insights panel was removed in Chrome 132; insights now live in the Insights tab of this panel.
• Throttling multipliers are relative to your machine, not an absolute benchmark.
• Free, built in, no account — and the same panel ships in Chromium Edge.
• The Performance monitor is a different feature (live metrics strip), not this panel.

A Performance-panel profiling pass

Getting a clean, useful recording:

• Test in an Incognito window with extensions disabled (extensions pollute the main-thread trace).
• Turn on Screenshots before recording a load, so you get a filmstrip.
• Note the Chrome version, date, throttling settings, and whether advanced paint/CSS/sampling instrumentation is on — so the recording is reproducible and comparable to a later one.
• Use Start profiling and reload page for a full-load story (not just “Record” on an already-loaded page) when diagnosing load performance.
• Apply CPU throttling (commonly 4x) and network throttling to approximate a mid-range phone — remembering the multiplier is relative to your machine.
• Record a couple of times; local recordings vary, so treat one run as a sample, not gospel.
• Open the Insights sidebar and read the LCP breakdown first — it points you at server, resource-load, or render-delay causes.
• Use the recipe to click the LCP node and confirm the actual LCP element.
• Check the Network track for render-blocking CSS/JS and heavy third-party requests.
• Cross-check what you found against field data (PageSpeed Insights / Search Console CrUX) — a good local trace doesn’t guarantee a passing field score.
• For crawlability/indexability questions, switch to URL Inspection — the Performance panel doesn’t answer “what does Googlebot see.”

The Performance panel and the tools around it

The panel is the local, lab diagnostic. Here’s where it sits relative to the rest:

• Chrome DevTools Performance panel — this tool. Local, lab, raw trace; best for why a page is slow and for pinpointing the LCP element.
• Lighthouse — also runs inside DevTools; the scored, automated audit with a prioritized fix list.
• PageSpeed Insights — CrUX field data on top, a Lighthouse lab run below; public URLs only, works on competitors.
• Chrome UX Report (CrUX) — the real-user field dataset Google actually ranks on; the panel can now overlay it next to your local results.
• WebPageTest — remote real-device testing, shareable results, multi-step scripting.
• Google Search Console — Core Web Vitals report — failing page groups at scale (field data).
• Search Console — URL Inspection — the right tool (not the Performance panel) for “what can Googlebot crawl and render.”
• Microsoft Edge DevTools — the same Chromium Performance panel, for Edge/Bing- focused workflows.

For how these fit together — lab vs. field, which one Google ranks on — start at the web performance tools hub.

Performance-panel mistakes that waste a trace

Treating one recording as field truth

The Performance panel records one local browser, device, network profile, cache state, and journey. Use it to explain a bottleneck, then use CrUX or RUM to judge how common that bottleneck is.

Recording without a reproducible interaction

An open-ended trace fills with unrelated activity. Define the load or interaction, start from the same state, and record only long enough to capture it.

Reading the flame chart without the network and frames tracks

A long task may be a consequence rather than the first cause. Align main-thread work with requests, interactions, screenshots, and paints before assigning ownership.

Applying heavy throttling and calling the number a benchmark

Throttling helps expose bottlenecks, but its result is a lab scenario. Keep the settings identical for before/after comparisons and label them when sharing results.

Fix common Performance-panel problems

The trace is too noisy to read

Likely cause: extensions, background tabs, or an overly long recording add unrelated work. Fix: use a clean profile, close background activity, and capture one defined journey. Confirm: the relevant interaction or load occupies a short, recognizable part of the trace.

The interaction feels slow but no event is obvious

Likely cause: the recording did not include the complete input-to-paint window or the wrong track is expanded. Fix: re-record the exact click, tap, or key interaction and inspect Interactions plus main-thread work. Confirm: the selected event exposes input delay, processing, and presentation work.

The result changes dramatically between runs

Likely cause: cache state, network variance, background work, or test setup differs. Fix: standardize reload mode, throttling, viewport, and journey, then run several times. Confirm: the same bottleneck appears even when the total duration varies.

The panel shows good lab vitals but Search Console is poor

Likely cause: the local trace does not represent real users or longer journeys. Fix: segment CrUX or RUM, reproduce the affected device and interaction, and use the panel for diagnosis. Confirm: the trace explains the slow segment rather than contradicting the field aggregate.

Prove a trace-driven fix worked

Repeated-journey test

Test to run: record the same load or interaction with identical cache, viewport, and throttling settings before and after the change. Expected result: the targeted request, task, or rendering phase shrinks consistently. Failure interpretation: run-to-run variance or a different bottleneck explains the result. Monitoring window: immediate across several recordings. Rollback trigger: errors, missing work, or worse visual behavior appears.

Main-thread test

Test to run: compare the selected main-thread task and its children in both traces. Expected result: removed or deferred work is absent from the critical interval rather than merely renamed or moved earlier. Failure interpretation: the implementation shifted the same cost elsewhere. Monitoring window: immediate. Rollback trigger: total blocking around the user action increases.

Field handoff test

Test to run: monitor the changed template or interaction in RUM after the lab win. Expected result: the affected field metric and attribution improve for the intended segment. Failure interpretation: the local scenario was not representative. Monitoring window: RUM as traffic arrives; CrUX over its rolling field window. Rollback trigger: field performance or task completion worsens consistently.

Test yourself: Chrome DevTools Performance Panel

Five quick questions on what the Performance panel is, how to read it, and what it isn’t. Pick an answer for each, then check.

Resources worth your time

My writing

• JavaScript SEO: What You Need to Know — where I use the Performance tab’s loading chart to explain how Googlebot’s rendering differs from a full browser paint.
• Google PageSpeed Insights for SEOs & Developers — the scored, field-plus-lab tool that complements the raw trace you get in DevTools.
• The Beginner’s Guide to Technical SEO — where performance and rendering fit in the bigger picture.

My speaking

• Page Experience Update (TMC, June 2021) (SlideShare) — includes the step-by-step “How to see the LCP element in DevTools” recipe.
• What’s Next for Page Experience (SMX Next 2021) (SlideShare) — my page-experience talk from the same era.

From around the industry

• Performance panel overview (Chrome for Developers) — the canonical starting point: what it is, how to open it, live metrics.
• Analyze runtime performance (Chrome for Developers) — the flame chart, FPS/CPU, and recording walkthrough.
• Monitor your local and real-user Core Web Vitals in DevTools (Rick Viscomi, Chrome) — the redesigned landing page and the CrUX field-data overlay.
• Performance tooling in 2024 and beyond (Sweeny & Irish, Chrome) — the Timeline → Performance history and how Lighthouse/Insights relate.
• 3 Ways to Use Chrome DevTools for SEO Troubleshooting (Richie Lauridsen, Search Engine Journal) — the closest existing SEO-framed take, including the LCP-finding technique.
• Profile Site Speed With The DevTools Performance Tab (DebugBear) — the deepest non-SEO technical walkthrough: forced-reflow debugging, layer analysis, throttling to see clearly.
• Chrome DevTools for Debugging Web Performance (Web Performance Calendar, 2025) — a current, post-redesign community perspective on the panel’s workflow.

Chrome DevTools Performance Panel

The Performance panel is Chrome DevTools' built-in, local profiler for recording and analyzing how a page loads and runs — CPU, main-thread work, rendering, network, and live Core Web Vitals. The recorded trace is local, lab data from your own browser — not what Googlebot sees — though the panel can optionally show real-user CrUX field data alongside it.

Related: Lighthouse, PageSpeed Insights, Core Web Vitals

Chrome DevTools Performance Panel

The Performance panel is the profiling tool built into Chrome DevTools (and the near-identical DevTools in Chromium-based Edge). You open DevTools, click the Performance tab, and record a trace of how a page loads and runs — CPU activity, main-thread work, rendering, network requests — captured frame by frame. Since its 2023–2024 redesign it also shows a live view of your local Core Web Vitals the moment you open it, plus an Insights sidebar that explains specific bottlenecks (an LCP phase breakdown, render-blocking requests, forced reflow, third-party cost).

Where Lighthouse and PageSpeed Insights score a page and hand you a prioritized list of fixes, the Performance panel gives you the raw trace to explore yourself: a flame chart of every function call on the main thread, a network waterfall, a filmstrip of visual frames, and analysis views (Bottom-up, Call Tree, Event Log). It’s deeper and more flexible, with no automated score.

The single most important thing to understand: the recorded trace is local, lab evidence. It profiles your own copy of Chrome on your machine and network at that moment — not Google’s Web Rendering Service. The panel isn’t purely lab-only overall, though: since the redesign it can optionally show real-user CrUX field data alongside your local results, matched by URL/origin, form factor, and period — but that overlay approximates a real-user segment, it doesn’t recreate it, and it’s not the same measurement as your local trace. It’s for finding why a page is slow, not for reporting a number Google sees on its own. Two easy points of confusion: the standalone Performance Insights panel (an experiment introduced in 2022) was deprecated and removed starting Chrome 132, with its features folded into the main Performance panel’s Insights tab; and the Performance monitor is a separate real-time metrics strip, not this panel.

Related: Lighthouse, PageSpeed Insights, Core Web Vitals

Changelog