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 crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. 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 InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 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 (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.) and Cumulative Layout ShiftCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) — two of the three Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. — measured live in your own browser. Click around the page and it picks up Interaction to Next PaintInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.) too. You get a snapshot of your local Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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, renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., 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 LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. — 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 GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. does. Googlebot renders pages with its own system (the Web RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 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 ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’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 LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. and WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input.? Switch to the Advanced tab.

TL;DR — The Performance panel is Chrome DevTools’ built-in, local profiler. Open it and it shows live local LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (and INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. 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 LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. into its four sub-parts and flags render-blockingRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. 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 GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’s Web Rendering ServiceTurning HTML, CSS, and JavaScript into the final visual page and DOM.; the recorded trace is lab evidence, and while the panel can optionally show real-user CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. 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:

• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. / PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. run an automated audit and give you a score plus prioritized recommendations (PSI also adds real CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests.). Scored, automated, opinionated.
• WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. 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, “LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 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 (CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) metrics,” and “If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.)” (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 VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. 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 resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. ranking signal comes from real-user CrUX field data (a 28-day aggregate of real Chrome users), which you see in Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. and CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 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 GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’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 renderingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor.). 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 toolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. 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 CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests. alongside it.
• Positioning: LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal./PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. = scored automated audit (+ CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field data); WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. = remote real-device lab; the Performance panel = raw interactive trace from your own browser.
• Live metrics: on open it shows local LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.; interacting adds local INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. — full local Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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): LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM..
• Myth to bust: it shows your browser, not GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’s Web Rendering Service — confirm crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index. 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 LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good./INP metricsInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good..
• 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 — LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. split into TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., 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 CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field-data overlay.
• Performance tooling in 2024 and beyond — Elizabeth Sweeny & Paul Irish on the Timeline → Performance history and where LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal./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 PaintLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.) and Cumulative Layout ShiftCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) metrics.” / “If you interact with your page, the Performance panel also captures your local Interaction to Next PaintInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. (INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good.).” 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 VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. 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 GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’s renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 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 dataPerformance metrics captured from real users, not lab tests.: PageSpeed Insights or Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.’s Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. (CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.). 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 LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. in DevTools) is your tool — it runs on whatever’s in your browser. PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. and WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. 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) → WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input..
• No — you just need to see the mechanics right now → the Performance panel.

What specifically are you trying to find?

• “Which element is my LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.?” → Performance panel: Screenshots on → Start profiling and reload → click the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. node on the timing graph.
• “What’s blocking my first paint / costing me third-party time?” → Performance panel → Insights sidebar (render-blockingRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. requests, third-party cost).
• “A prioritized to-do list of fixes” → LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. / PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking..
• “What can GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. actually crawl/render?” → not this panel — use Search Console’s URL Inspection toolA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version..

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 CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field data Google ranks on, though the panel can optionally show field dataPerformance metrics captured from real users, not lab tests. alongside it.
• It profiles your browser — not GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’s Web Rendering ServiceTurning HTML, CSS, and JavaScript into the final visual page and DOM..
• 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 LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. breakdown first — it points you at server, resource-load, or render-delay causes.
• Use the recipe to click the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. node and confirm the actual LCP element.
• Check the Network track for render-blockingRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. CSS/JS and heavy third-party requests.
• Cross-check what you foundA 302 (\"Found\") is a temporary redirect: it forwards users to a new URL while telling search engines the original URL should stay in the index. It's a weak canonicalization signal, not the zero-equity dead end of SEO folklore. against field dataPerformance metrics captured from real users, not lab tests. (PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. / Search Console CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.) — a good local trace doesn’t guarantee a passing field score.
• For crawlabilityCrawlability is how well search engine crawlers can discover, access, and fetch a site's pages. A crawlability issue is any technical condition — blocked access, broken links, server failures, or bloated URL inventory — that stops pages from reaching the index./indexability questions, switch to URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. — the Performance panel doesn’t answer “what does GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. 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 panelThe 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. — this tool. Local, lab, raw trace; best for why a page is slow and for pinpointing the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. element.
• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. — also runs inside DevTools; the scored, automated audit with a prioritized fix list.
• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests. on top, a LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. lab run below; public URLs only, works on competitors.
• Chrome UX Report (CrUX)Chrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. — the real-user field dataset Google actually ranks on; the panel can now overlay it next to your local results.
• WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. — remote real-device testing, shareable results, multi-step scripting.
• Google Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results. — Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs. — failing page groups at scale (field data).
• Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance. — URL InspectionA Google Search Console feature that reports how Google sees one specific URL on a property you own. By default it shows the last-indexed snapshot; a separate \"Test live URL\" mode fetches the current version. — the right tool (not the Performance panel) for “what can GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. 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 CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. 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 taskAny main-thread task over 50 ms — the primary cause of INP regressions. 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 CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 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; CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. 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 GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer.’s renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. 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 renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. fit in the bigger picture.

My speaking

• Page Experience Update (TMC, June 2021) (SlideShare) — includes the step-by-step “How to see the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. 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 CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field-data overlay.
• Performance tooling in 2024 and beyond (Sweeny & Irish, Chrome) — the Timeline → Performance history and how LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal./Insights relate.
• 3 Ways to Use Chrome DevTools for SEO Troubleshooting (Richie Lauridsen, Search Engine Journal) — the closest existing SEO-framed take, including the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.-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, renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., network requests — captured frame by frame. Since its 2023–2024 redesign it also shows a live view of your local Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. the moment you open it, plus an Insights sidebar that explains specific bottlenecks (an LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. phase breakdown, render-blockingRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. requests, forced reflow, third-party cost).

Where LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. and PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. 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 RenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM. Service. The panel isn’t purely lab-only overall, though: since the redesign it can optionally show real-user CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program. field dataPerformance metrics captured from real users, not lab tests. 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