Chrome DevToolsパフォーマンスパネル

要点 — パフォーマンスパネルは Chrome に組み込まれたツールです（DevToolsを開き、パフォーマンスをクリックします）。ページの読み込み中にブラウザーが行うこと、つまりすべてのスクリプト、ネットワークリクエスト、描画を正確に記録します。PageSpeed Insights と違ってスコアは出さず、ページが遅い理由を見つけるための生の状況を示します。重要なのは、あなたのブラウザーの動作を示すのであって、Googleのクローラーの動作ではないことです。アカウント不要で無料です。

どのようなものか

Chrome DevToolsには多くのタブがあります。パフォーマンスパネルは、ページの読み込みと実行を記録してから、詳細を掘り下げるためのものです。ファイルのダウンロード、JavaScriptの実行、ページのレイアウトと描画など、ブラウザーの作業を時間軸に沿って取得し、拡大して調べられるタイムラインに並べます。

違いは次のように考えると分かりやすいでしょう。PageSpeed InsightsとLighthouseは、テストを実行してスコアとやるべきことの一覧を渡す通知表のようなものです。パフォーマンスパネルは、ページの読み込み全体を撮影した防犯カメラの記録に似ています。スコアはありませんが、巻き戻して問題が起きた正確な瞬間を確認できます。

開き方と最初に表示されるもの

1. DevToolsを開きます（ページを右クリックして 検証、またはMacでは Cmd+Option+I、Windowsでは Ctrl+Shift+I）。
2. 上部の パフォーマンス タブをクリックします。

開いた瞬間から、パネルにはページの**Largest Contentful Paint（LCP）とCumulative Layout Shift（CLS）**が表示されます。これは3つあるCore Web Vitalsのうち2つで、あなたのブラウザー上でリアルタイムに測定されたものです。ページを操作すると、**Interaction to Next Paint（INP）**も取得されます。何も記録しなくても、ローカルなCore Web Vitalsのスナップショットが得られます。

ページの読み込みを記録する

読み込みの全体像を見るには、プロファイリングを開始してページを再読み込みをクリックします（各時点でページがどう見えたかのフィルムストリップも取得できるよう、先に スクリーンショット のチェックボックスをオンにします）。パネルがページを再読み込みしてすべてを記録します。停止すると、スクリプト処理、レンダリング、描画を示す色付きバー、上部を横切るスクリーンショットの帯、いつ何が読み込まれたかを示すネットワーク領域からなる密なタイムラインが表示されます。

初めて見ると圧倒されます。しかし、ほとんどのSEO担当者がここへ来る目的は単純です。Advancedタブで手順を説明しますが、LCPになった正確な要素、つまりページが描画した最大の要素を見つけ、何を最適化すべきかを把握します。

多くの人が誤解すること

パフォーマンスパネルが示すのは、あなたのChromeブラウザーの動作であり、Googlebotの動作ではありません。 GooglebotはWeb Rendering Serviceという独自のシステムでページをレンダリングし、完全なデスクトップブラウザーと同一ではありません。そのためパネルは速度の診断とレンダリングの理解には非常に役立ちますが、Googleが実際にクロールしてインデックス登録できるものを確認する方法ではありません。その確認には、Google Search ConsoleのURL Inspectionツールを使います。

フレームチャートの読み方、Insightsサイドバー、LCP要素の発見、遅いスマートフォンを再現するスロットリング、LighthouseやWebPageTestとの比較まで詳しく知りたいですか？ Advancedタブへ切り替えてください。

要点 — パフォーマンスパネルは Chrome DevTools に組み込まれたローカルプロファイラーです。開くとローカルのLCP/CLS（操作後はINPも）が表示されます。プロファイリングを開始してページを再読み込み（スクリーンショットをオン）を押すと、完全な読み込みを記録できます。メインスレッドの処理を示すフレームチャート、FPS/CPUのタイムライン、ネットワークウォーターフォール、Bottom-up／Call Tree／Event Logの分析タブを読み、さらにLCPを4つの部分に分解し、レンダリングをブロックするリクエスト、強制リフロー、サードパーティーのコストを示すInsightsサイドバーも確認します。正確なLCP要素を特定する最短の組み込み手段です。押さえる点は3つです。これはGooglebotのWeb Rendering Serviceではなくあなたのブラウザーをプロファイルすること、記録トレースはラボの証拠であり、パネルが任意に実ユーザーのCrUXフィールドデータを併記できても同じ測定ではないこと、そして旧スタンドアロンのPerformance InsightsパネルはChrome 132で削除され、機能はこのパネルのInsightsタブに移ったことです。スロットリング倍率は絶対ベンチマークではなく、あなたのマシンを基準にした相対値です。

パフォーマンスパネルとは何か

Googleの説明は明快です。“Use the Performance panel to analyze your website’s performance” (翻訳) 「パフォーマンスパネルを使ってウェブサイトのパフォーマンスを分析します」、“The Performance panel lets you record CPU performance profiles of your web applications” (翻訳) 「パフォーマンスパネルでは、ウェブアプリケーションのCPUパフォーマンスプロファイルを記録できます」（Chrome DevToolsのドキュメント）。つまりこれはプロファイラーです。ブラウザーが一定時間内に行ったすべての処理のトレースを記録し、そのトレースを調べます。

兄弟ツールと最初に位置づけておく価値があります。これらは頻繁に混同されるからです。

• Lighthouse / PageSpeed Insightsは自動監査を実行し、スコアと優先順位付きの推奨事項を出します（PSIは実ユーザーのCrUXフィールドデータも加えます）。スコア付きで、自動化され、判断を伴うツールです。
• WebPageTestは、ページをリモートの実機で実行し、履歴として共有できる結果を記録し、複数ステップのスクリプトにも対応します。リモートで共有しやすく、詳細なツールです。
• パフォーマンスパネルは、あなたのローカルブラウザーから得た生の対話型トレースを提供します。スコアもアカウントもリモートマシンもありません。より深く柔軟ですが、解釈は自分で行います。

記録されたトレース自体は、その瞬間の1台のブラウザー、デバイス、ネットワークのスナップショットであり、ローカルなラボの証拠です。ただし、その周囲のパネルは純粋なラボツールではありません。再設計以降、ローカル結果の横に任意で実ユーザーのCrUXフィールド指標も表示できます。ローカルラボ、リモートラボ、実ユーザーフィールドの違いを区別してください。この区別が、ウェブパフォーマンスツールクラスター全体の軸であり、以下の誤解が生じる理由でもあります。

簡単な歴史（いま見ているパネルを特定するために）

このパネルは長く存在しています。Chrome DevToolsチームのElizabeth SweenyとPaul Irishは、“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,” (翻訳) 「Chrome DevToolsのパフォーマンスパネルは、15年近くにわたり、形を変えながら開発者が実行時パフォーマンスを測定・最適化するのに役立ってきました」、そして*“Starting with a panel called ‘Timeline’, it evolved to the Performance panel you know today”* (翻訳) 「「Timeline」というパネルから始まり、現在知られているパフォーマンスパネルへ発展しました」と説明しています（2024年以降のパフォーマンスツール）。その過程で、“Lighthouse was launched in 2016 to help spot optimization opportunities more easily,” (翻訳) 「Lighthouseは最適化の機会を見つけやすくするため、2016年に公開されました」、“The experimental Performance Insights panel was released in 2022 to test new ways of surfacing performance insights.” (翻訳) 「実験的なPerformance Insightsパネルは、パフォーマンスに関する洞察を新しい方法で提示するため、2022年に公開されました」とも述べています。

最後の点は、現在の情報を理解するうえで重要です。スタンドアロンのPerformance Insightsパネルは実験であり、現在はありません。Google自身の告知には*“The Performance insights panel is deprecated and removed from DevTools starting with Chrome version 132. We recommend you use the Performance > Insights tab instead”* (翻訳) 「Performance insightsパネルは非推奨となり、Chromeバージョン132以降はDevToolsから削除されます。代わりにPerformance > Insightsタブを使うことを推奨します」とあります（廃止告知）。別の「Performance Insights」パネルが表示されるチュートリアルやスクリーンショットはChrome 132より前のもので、古い情報です。洞察は通常のパフォーマンスパネル内のサイドバーに移りました。

開くと表示されるライブ指標

DevToolsを開き、上部のタブから パフォーマンス を選択します。Googleの説明によれば、“When you open the Performance panel, it immediately captures and shows you your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics,” (翻訳) 「パフォーマンスパネルを開くと、ローカルのLargest Contentful Paint（LCP）とCumulative Layout Shift（CLS）の指標が直ちに取得・表示されます」、“If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INP)” (翻訳) 「ページを操作すると、パフォーマンスパネルはローカルのInteraction to Next Paint（INP）も取得します」とされています（概要ドキュメント）。これはRick Viscomiが*“a completely redesigned Performance panel landing page featuring a live view of your local Core Web Vitals performance”* (翻訳) 「ローカルなCore Web Vitalsのパフォーマンスをライブ表示する、完全に再設計されたパフォーマンスパネルのランディングページ」と説明した再設計の一部です（DevToolsでローカルと実ユーザーのCore Web Vitalsを監視する）。つまり、何も記録する前から、ローカルのCore Web Vitals一式を確認できます。

トレースを記録する：実行時と読み込み

記録できるものは2つあり、その違いが重要です。

• 実行時パフォーマンス — ページはすでに読み込まれていて、実行中（アニメーション、遅い操作、スクロールのカクつきなど）をプロファイルします。Googleは*“Runtime performance is how your page performs when it is running, as opposed to loading”* (翻訳) 「実行時パフォーマンスとは、ページが読み込み中ではなく実行中にどのように動作するかです」と説明しています（実行時パフォーマンスの分析）。
• 読み込みパフォーマンス — 新しいナビゲーションからの全体像を見ます。プロファイリングを開始してページを再読み込みをクリックし、先に スクリーンショット をオンにして、トレースと一緒に視覚的なフレームのフィルムストリップを取得します。

SEO作業でLCP、レイアウトシフト、レンダリングをブロックするスクリプトを調べるときは、ほとんどの場合、スクリーンショットをオンにした読み込み記録を使います。

トレースに含まれるのは、記録ウィンドウ内で起きたことだけです。ウィンドウ外の操作や、後から発生する遅延読み込みの処理を取得しなかった場合、それは「存在しない」のではなく、単に観測されていません。自分や他の人が後で再現・比較できるトレースにするには、Chromeのバージョンと日付（ラベル、ショートカット、正確なUIはリリースごとに変わります）、スクリーンショットの有無、CPU／ネットワークのスロットリング設定、詳細なペイント／CSSインストルメンテーションとJavaScriptサンプリングの設定を記録してください。各設定は詳細とオーバーヘッドを増やすため、設定が違うトレースは、設定を入れずに記録したトレースと直接比較できません。

トレースを読む

記録には、いくつかのトラックが積み重なって表示されます。主なものは次のとおりです。

• フレームチャート／Mainトラック。 ここが中心です。Googleは*“DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time.”* (翻訳) 「DevToolsは時間の経過に沿ったメインスレッドの活動をフレームチャートで示します。x軸は時間経過として記録を表します」、また*“Use the Main track to view activity that occurred on the page’s main thread”* (翻訳) 「Mainトラックを使って、ページのメインスレッドで発生した活動を確認します」と説明しています（機能リファレンス）。時間は左から右へ進み、各時点の下にあるバーの積み重なりがコールスタックです。幅の広いバーほど長いタスクです。そこが時間を使った場所です。このネストは、何が何を呼び、いつ起きたかというトレースの構造を示しますが、それだけで親タスクが広範なユーザー体験の問題を引き起こした証明にはなりません。仮説の出発点として扱い、確認してください。
• FPSチャート。 カクつきをすばやく読むためのものです。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.”* (翻訳) 「FPSの上に赤いバーがある場合、フレームレートが非常に低下し、ユーザー体験を損ねている可能性があります」と説明しています（実行時ドキュメント）。目標は滑らかな60 FPSで、赤いバーが粗い箇所を示します。
• CPUチャートは、記録中にメインスレッドがどれだけ忙しかったかを示します。
• Networkトラックは、すべてのリクエストのウォーターフォールです。何がいつ、どの順序で読み込まれたかが分かり、レンダリングをブロックするリソースもここに現れます。
• Timingsトラックは、アプリが発行したカスタム performance.mark() 測定を表示します。

フレームチャートの下には、同じデータを異なる角度から切り分ける3つの分析タブがあります。

• Bottom-up — “Use the Bottom-up tab to view which activities directly took up the most time in aggregate.” (翻訳) 「Bottom-upタブを使って、合計で最も多くの時間を直接使った活動を確認します」。「どの1つの関数が時間を消費しているのか？」を調べるのに向いています。
• Call tree — “Use the Call tree tab to view which root activities cause the most work.” (翻訳) 「Call treeタブを使って、どのルート活動が最も多くの作業を発生させたかを確認します」。「どのトップレベルタスクがすべての処理を始めたのか？」を調べるのに向いています。
• Event log — 同じイベントを時系列に並べたものです。

Insightsサイドバー

再設計で診断に加わった最も役立つ機能は、削除されたスタンドアロンのPerformance Insightsパネルを引き継ぐ Insights サイドバーです。フレームチャートを自分で探し回る代わりに、具体的で名前の付いた問題を提示します。SEOで特に重要なのは次の項目です。

• LCPの内訳。 GoogleはLCPを、最初のバイトまでの時間、リソース読み込み遅延、リソース読み込み時間、要素のレンダリング遅延という4つの部分に分けます（LCP内訳のInsight）。単に遅いという結果ではなく、LCPが遅い理由（サーバーか、遅れて読み込まれた画像か、レンダリングブロックか）を示します。
• レンダリングをブロックするリクエスト — 初回描画を遅らせたCSS／JSです（レンダリングブロックのInsight）。
• 強制リフロー — ブラウザーがレイアウトを再計算するためにスクリプトを一時停止しなければならなかった場所です。
• サードパーティーのコスト — 埋め込み、タグ、ウィジェットがどれだけ時間を使っているかです。

自動的に提示されるため、Insightsサイドバーは、パフォーマンスパネルがLighthouseの「修正すべきもの」を示す体験に最も近づく部分です。それでも、各Insightの背後にある生のトレースへ移動できます。

各Insightは証明ではなく、導かれた仮説として扱ってください。潜在的な問題を特定し、その背後にあるトレースの文脈へつなぎますが、項目が表示されたことは、それが追っている結果を引き起こした証明でも、修正すれば解決する証明でもありません。クライアントやチームメイトにInsightが原因だと伝える前に、トレースそのものと、修正前後の再記録で確認してください。

CPUとネットワークのスロットリング（つまずきやすい注意点）

開発マシンは一般的なスマートフォンよりはるかに速いため、自分には一瞬に感じるページが実ユーザーには苦痛になることがあります。スロットリングは、CPUの低速化倍率とネットワークプロファイル（Slow 4Gなど）によって、より弱い条件を再現します。

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.” (翻訳) 「スロットリングはコンピューターの性能を基準にした相対値です。たとえば2xの低速化オプションでは、CPUは通常の能力の2倍遅く動作します」（機能リファレンス）。つまり「4x低速化」は絶対的なベンチマークではありません。高速なノートパソコンでの4xと、低速なマシンでの4xは同じ結果になりません。これはマシン間で比較できる標準ではなく、相対的なダイヤルです。DebugBearはDevToolsの詳しい解説 で、密集したイベント群を読めるように記録自体を遅くする、という実用的な使い方も指摘しています。

ここでのラボデータと、Googleがランキングに使うフィールドデータ

ここでSEO担当者は痛い目に遭います。パフォーマンスパネルの数値、ライブ指標もすべての記録も、あなたのマシン、あなたのネットワーク、その瞬間のラボデータです。Googleの実際のCore Web Vitalsランキングシグナルは、実ユーザーのCrUXフィールドデータ（実際のChromeユーザーによる28日間の集計）から得られ、Search ConsoleとPageSpeed Insightsで確認できます。ローカル記録が完璧でも、フィールドスコアに合格するとは限りません。実ユーザーは、1回のテストより遅いデバイスや悪いネットワーク、より多様な条件を使うからです。

再設計されたパネルは、実際にはこの2つを橋渡しします。アップデート以降、ローカル結果のすぐ横に実ユーザーのCrUXフィールドデータを表示できるため、「いま測ったもの」と「実ユーザーが体験しているもの」を比較できます。フィールドオーバーレイが利用できる場合、URLレベルとオリジンレベル、モバイルとデスクトップを切り替えられ、UIには参照しているデータ期間も表示されます。比較するトレースとこれらを一致させてください。それでも、フィールドを踏まえた環境設定（パネルがCrUXに基づいて推奨するスロットリングプリセット）は、選択した実ユーザーセグメントを近似するだけです。1回のローカル記録が、元の母集団の分布を再現したり、ランキング結果を予測したりするわけではありません。このオーバーレイは、ローカルのトレースとGoogleのランキングシグナルが異なる2つの数値だと、組み込み機能が最も明確に思い出させてくれるものです。ラボとフィールドの詳しい説明は、ウェブパフォーマンスツールハブと、兄弟記事のCore Web VitalsおよびCrUX解説を参照してください。

テクニカルSEOでの使い方

私は長年、パフォーマンスパネルを単独の成果物としてではなく、スコアだけでは足りず、実際の仕組みを見る必要があるときに手に取るツールとして使ってきました。具体的な用途をいくつか挙げます。

正確なLCP要素を見つける。 これはパネルでできるSEO上の最も価値ある技の1つで、ステージで教えてきた手順でもあります。私のPage Experience Update（TMC、2021年6月） 講演資料では、手順は Performance > 「Screenshots」を確認、「プロファイリングを開始してページを再読み込み」をクリック、タイミンググラフでLCPを探す、そしてノードをクリックする — これがLCPの要素です、となっています。DevToolsは、GoogleがLargest Contentful Paintとして数える要素を正確に教えてくれるため、何を最適化するかが分かります。Seer InteractiveのRichie Lauridsenも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” (翻訳) 「LCPのフラグにカーソルを合わせると、ページの読み込み中に最大のコンテンツペイントとして指示されたコンテンツ部分を実際に確認できます」（Chrome DevToolsをSEOトラブルシューティングに使う3つの方法）。独立した2つの解説が同じ手順にたどり着くことから、これは一度きりの方法ではなく標準的なワークフローだと分かります。

レンダリングを人に説明する。 私のJavaScript SEOガイド では、“In Chrome Dev Tools, if you run a test on the ‘Performance’ tab, you get a loading chart.” (翻訳) 「Chrome Dev Toolsで「Performance」タブのテストを実行すると、読み込みチャートが表示されます」という説明を使い、レンダリングパイプラインを見える形にします。ダウンロード、HTML解析、JS実行、レイアウト、描画というチャートの流れをたどると、Googlebotのレンダリングは完全なブラウザーの描画と同じことをすべて行うわけではない、とクライアントや同僚に説明できます。これはJS SEOの問題を診断する中心的な点です。

レンダリングをブロックするサードパーティーを見つけることとレイアウトシフトを診断することも重要です。ネットワークウォーターフォールは初回描画を遅らせているものを示し、トレース（およびCLS指標）は何がいつ移動したかを示します。

Googlebotに関する誤解（実際に理解しておくべき点）

ここに落とし穴があります：“if it looks fine in my Performance panel, Googlebot sees it fine too.” (翻訳) 「自分のパフォーマンスパネルで問題なく見えるなら、Googlebotにも問題なく見える」。そうとは限りません。パネルがプロファイルするのは、ローカルで機能が完全なChromeです。GooglebotがレンダリングするのはWeb Rendering Serviceであり、最近のものではあるものの同一ではないChromiumビルドです。完全なブラウザーが対応するすべてをサポートせず、状態を保持せず、権限プロンプトを拒否するなど、動作も異なります（クロールとレンダリングを参照）。パフォーマンスパネルはレンダリングの動作を理解・診断するには非常に優れていますが、実際にクロールおよびインデックス登録できるものを確認する代わりにはなりません。その確認にはSearch ConsoleのURL Inspectionツールまたは生のフェッチを使います。

簡単な区別の注記

パフォーマンスパネルとパフォーマンスモニターを混同しないでください。後者は、記録したトレースではなく、CPU使用率、JSヒープ、DOMノードなどのリアルタイム指標をライブ表示する、より小さな別のDevTools機能です。同じ単語が使われますが、別のツールです。

AI要約

Advanced版を短くまとめると、次のとおりです。

• どのようなものか： Chrome DevToolsのパフォーマンスパネルは、組み込みのローカルプロファイラーです。DevToolsを開いて パフォーマンス を選びます。ページの読み込みと実行を記録しますが、スコアは出しません。記録トレースはローカルなラボの証拠ですが、パネルには任意でCrUXフィールドデータを併記できます。
• 位置づけ： Lighthouse／PageSpeed Insights＝スコア付き自動監査（＋CrUXフィールドデータ）、WebPageTest＝リモート実機ラボ、パフォーマンスパネル＝自分のブラウザーから得た生の対話型トレースです。
• ライブ指標： 開くとローカルの LCP と CLS が表示され、操作するとローカルの INP が加わります。記録なしでローカルのCore Web Vitals一式を確認できます。
• 記録： runtime（ページがすでに実行中）とload（プロファイリングを開始してページを再読み込み、スクリーンショットをオンにしてフィルムストリップを取得）を区別します。
• トレースを読む： メインスレッド処理のフレームチャート（幅が広いバーほど長いタスク）、FPSチャート（赤＝カクつき、目標60 FPS）、CPUチャート、ネットワークウォーターフォール、Timings、さらに Bottom-up／Call Tree／Event Log の分析タブがあります。
• Insightsサイドバー（スタンドアロンのPerformance Insightsパネルを引き継ぎ、Chrome 132で削除）：LCPを4つの部分に分け、レンダリングをブロックするリクエスト、強制リフロー、サードパーティーのコストを示します。各Insightは、原因の証明ではなく導かれた仮説として扱い、トレースと修正前後の再記録で確認します。
• スロットリングは絶対ベンチマークではなくマシンに対する相対値です。高速なノートパソコンの「4x」と低速なものの「4x」は同じではありません。
• ラボ≠フィールド： 記録トレースはラボデータで、Googleのランキングは実ユーザーのCrUXフィールドデータに基づきます。再設計版ではCrUXをローカル結果の横に表示できます（URL／オリジン、フォームファクター、期間を一致させます）が、これは実ユーザーセグメントの近似であり、母集団の再現ではありません。
• SEOでの用途： 正確な LCP要素（Patrickのスライド手順と、SEJのRichie Lauridsenによる説明で裏付け）、レンダリングをブロックするサードパーティーの発見、レイアウトシフトの診断、レンダリングの説明です。
• 壊すべき誤解： 表示するのはあなたのブラウザーであり、GooglebotのWeb Rendering Serviceではありません。クロール可能性はDevToolsではなくURL Inspectionで確認します。

公式ドキュメント

Chrome DevToolsチームによる一次資料です。

Chrome / Google

• パフォーマンスパネルの概要 — 何であるか、開き方、ローカルのLCP／CLS／INPライブ指標。
• 実行時パフォーマンスを分析する — 記録、フレームチャート、FPS／CPU、実行時と読み込みの区別。
• パフォーマンス機能リファレンス — Mainトラック、Bottom-up、Call Tree、Event Log、スロットリングの定義。
• Performance Insights（廃止告知） — スタンドアロンパネルはChrome 132で削除され、代わりにPerformance > Insightsを使います。
• LCP内訳のInsight — LCPをTTFB、リソース読み込み遅延、リソース読み込み時間、要素のレンダリング遅延に分解します。
• レンダリングをブロックするリクエストのInsight — 初回描画を遅らせるCSS／JSを特定します。
• DevToolsでローカルと実ユーザーのCore Web Vitalsを監視する — Rick Viscomiによる、再設計したランディングページとCrUXフィールドデータオーバーレイの説明。
• 2024年以降のパフォーマンスツール — Elizabeth SweenyとPaul Irishによる、TimelineからPerformanceへの歴史とLighthouse／Insightsの位置づけ。
• 400%高速化されたPerformanceパネル — エンジニアリングの深掘り。パネルが継続的に投資され、リリースごとに変化していることを示します。
• パフォーマンスモニター — メインのパフォーマンスパネルとは別のリアルタイム指標ストリップ（区別のため）。

Bing / Microsoft

• Chrome／Edge DevToolsのパフォーマンスパネルに関するBing固有の資料はありません。これは検索エンジン製品ではなくブラウザーツールだからです。ChromiumベースのEdgeには、同じパフォーマンスパネルを備えたほぼ同一のDevToolsが搭載されているため、ここでの説明はEdgeにも適用できます。

ソースからの引用

Chrome DevToolsチームと業界の実務家による、記録に基づく発言です。Chromeの各リンクは、引用箇所へ直接移動するディープリンクです。

Chrome DevTools — パネルの役割と読み方

• “Use the Performance panel to analyze your website’s performance.” (翻訳) 「パフォーマンスパネルを使ってウェブサイトのパフォーマンスを分析します。」 / “The Performance panel lets you record CPU performance profiles of your web applications.” (翻訳) 「パフォーマンスパネルでは、ウェブアプリケーションのCPUパフォーマンスプロファイルを記録できます。」 — Chrome DevToolsドキュメント。 引用へ移動
• “When you open the Performance panel, it immediately captures and shows you your local Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) metrics.” (翻訳) 「パフォーマンスパネルを開くと、ローカルのLargest Contentful Paint（LCP）とCumulative Layout Shift（CLS）の指標が直ちに取得・表示されます。」 / “If you interact with your page, the Performance panel also captures your local Interaction to Next Paint (INP).” (翻訳) 「ページを操作すると、パフォーマンスパネルはローカルのInteraction to Next Paint（INP）も取得します。」 引用へ移動
• “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.” (翻訳) 「DevToolsは時間の経過に沿ったメインスレッドの活動をフレームチャートで示します。x軸は時間経過として記録を表します。」 引用へ移動
• “Whenever you see a red bar above FPS, it means that the framerate dropped so low that it’s probably harming the user experience.” (翻訳) 「FPSの上に赤いバーがある場合、フレームレートが非常に低下し、ユーザー体験を損ねている可能性があります。」 引用へ移動
• “Use the Main track to view activity that occurred on the page’s main thread.” (翻訳) 「Mainトラックを使って、ページのメインスレッドで発生した活動を確認します。」 / “Use the Bottom-up tab to view which activities directly took up the most time in aggregate.” (翻訳) 「Bottom-upタブを使って、合計で最も多くの時間を直接使った活動を確認します。」 / “Use the Call tree tab to view which root activities cause the most work.” (翻訳) 「Call treeタブを使って、どのルート活動が最も多くの作業を発生させたかを確認します。」 引用へ移動
• “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.” (翻訳) 「スロットリングはコンピューターの性能を基準にした相対値です。たとえば2xの低速化オプションでは、CPUは通常の能力の2倍遅く動作します。」 引用へ移動

Chrome DevTools — 歴史と現在性に関する注記

• “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.” (翻訳) 「Chrome DevToolsのパフォーマンスパネルは、15年近くにわたり、形を変えながら開発者が実行時パフォーマンスを測定・最適化するのに役立ってきました。」 / “Starting with a panel called ‘Timeline’, it evolved to the Performance panel you know today.” (翻訳) 「「Timeline」というパネルから始まり、現在知られているパフォーマンスパネルへ発展しました。」 — Chrome DevToolsチームのElizabeth SweenyとPaul Irish。 引用へ移動
• “The Performance insights panel is deprecated and removed from DevTools starting with Chrome version 132. We recommend you use the Performance > Insights tab instead.” (翻訳) 「Performance insightsパネルは非推奨となり、Chromeバージョン132以降はDevToolsから削除されます。代わりにPerformance > Insightsタブを使うことを推奨します。」 引用へ移動
• “a completely redesigned Performance panel landing page featuring a live view of your local Core Web Vitals performance.” (翻訳) 「ローカルなCore Web Vitalsのパフォーマンスをライブ表示する、完全に再設計されたパフォーマンスパネルのランディングページ。」 — ChromeチームのRick Viscomi。 記事を読む

業界 — SEOワークフロー

• “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.” (翻訳) 「LCPのフラグにカーソルを合わせると、ページの読み込み中に最大のコンテンツペイントとして指示されたコンテンツ部分を実際に確認できます。」 — Seer InteractiveのRichie Lauridsen、Search Engine Journal。 記事を読む

Patrick Stox — パネルの利用

• “In Chrome Dev Tools, if you run a test on the ‘Performance’ tab, you get a loading chart.” (翻訳) 「Chrome Dev Toolsで「Performance」タブのテストを実行すると、読み込みチャートが表示されます。」 — Googlebotのレンダリングが完全なブラウザーの描画と異なることを説明する、私のAhrefs JavaScript SEOガイド で使っています。

どのパフォーマンスツールを使うべきか？

このパネルは複数ある選択肢の1つで、間違ったものを選ぶと時間を無駄にします。判断を簡単にする方法は次のとおりです。

スコアが必要ですか、それとも診断が必要ですか？

• ランキングのためのスコア／合否判定 → フィールドデータが必要です。PageSpeed InsightsまたはSearch ConsoleのCore Web Vitalsレポート（CrUX）を使います。パフォーマンスパネルでは得られません。
• ページが遅い理由の診断 → 次へ進みます。

ページは公開状態で到達できますか？

• いいえ（ログインの背後、ステージング、localhost） → パフォーマンスパネル（またはDevTools内のLighthouse）がツールです。ブラウザーに表示できるものなら実行できます。PSIとWebPageTestには公開URLが必要です。
• はい → パフォーマンスパネルでもリモートツールでも動作します。次へ進みます。

共有可能で、実機を使い、再現可能な結果が必要ですか？

• はい（クライアントレポート、実機、履歴トレンド） → WebPageTest。
• いいえ — いま仕組みを確認したいだけ → パフォーマンスパネル。

具体的に何を見つけようとしていますか？

• 「自分のLCPはどの要素か？」 → パフォーマンスパネル：スクリーンショットをオン → プロファイリングを開始して再読み込み → タイミンググラフ上のLCPノードをクリック。
• 「初回描画をブロックしているもの／サードパーティーの時間を消費しているものは何か？」 → パフォーマンスパネル → Insightsサイドバー（レンダリングブロックリクエスト、サードパーティーコスト）。
• 「修正すべきことを優先順位付けした一覧」 → Lighthouse／PageSpeed Insights。
• 「Googlebotは実際に何をクロール／レンダリングできるか？」 → このパネルではありません。Search ConsoleのURL Inspectionツールを使います。

経験則は次のとおりです。フィールドツールは問題があるか、ランキングに影響するかを教え、パフォーマンスパネルはその理由を、正確な関数、リクエスト、要素まで教えます。

パフォーマンスパネルのチートシート

使い始める

トレースを読む

LCP要素を見つける（SEO手順）

1. スクリーンショットをオンにします。
2. プロファイリングを開始してページを再読み込みをクリックします。
3. タイミンググラフで印の付いた LCP を見つけます。
4. ノードをクリックします。DevToolsが正確なLCP要素を表示します。

早わかり／失敗を避けるために

• 記録トレースはローカルのラボデータであり、Googleがランキングに使うCrUXのフィールドデータではありません。ただし、パネルにはフィールドデータを任意で併記できます。
• プロファイルするのはあなたのブラウザーであり、GooglebotのWeb Rendering Serviceではありません。
• スタンドアロンのPerformance InsightsパネルはChrome 132で削除され、洞察はこのパネルのInsightsタブにあります。
• スロットリング倍率は絶対ベンチマークではなく、あなたのマシンを基準にした相対値です。
• 無料で組み込み、アカウント不要です。同じパネルがChromiumのEdgeにも搭載されています。
• パフォーマンスモニターは別機能（ライブ指標ストリップ）で、このパネルではありません。

パフォーマンスパネルのプロファイリング手順

きれいで役立つ記録を取得するには：

• 拡張機能を無効にしたシークレットウィンドウでテストする（拡張機能はメインスレッドのトレースを汚します）。
• 読み込みを記録する前にスクリーンショットをオンにし、フィルムストリップを取得する。
• Chromeのバージョン、日付、スロットリング設定、詳細なペイント／CSS／サンプリングのインストルメンテーションがオンかどうかを記録する。記録を再現可能にし、後の記録と比較できるようにするためです。
• 読み込みパフォーマンスを診断するときは、すでに読み込み済みのページで単に「Record」を押すのではなく、完全な読み込みの状況を得るためにプロファイリングを開始してページを再読み込みを使う。
• CPUスロットリング（通常は4x）とネットワークスロットリングを適用し、中程度のスマートフォンを近似する。ただし倍率はあなたのマシンを基準にした相対値です。
• 2回ほど記録する。ローカル記録は変動するため、1回の実行を絶対視せずサンプルとして扱う。
• Insightsサイドバーを開き、まずLCPの内訳を読む。サーバー、リソース読み込み、レンダリング遅延の原因を示してくれます。
• 手順に従ってLCPノードをクリックし、実際のLCP要素を確認する。
• Networkトラックで、レンダリングをブロックするCSS／JSと重いサードパーティーリクエストを確認する。
• 見つけたものをフィールドデータ（PageSpeed Insights／Search Console CrUX）と突き合わせる。良好なローカルトレースでも、フィールドスコアに合格するとは限りません。
• クロール可能性／インデックス登録可能性の質問ではURL Inspectionへ切り替える。パフォーマンスパネルは「Googlebotには何が見えるか」に答えるものではありません。

パフォーマンスパネルと周辺ツール

このパネルはローカルのラボ診断ツールです。他のツールとの位置づけは次のとおりです。

• Chrome DevToolsパフォーマンスパネル — このツールです。ローカル、ラボ、生のトレースで、ページが遅い理由とLCP要素の正確な特定に向いています。
• Lighthouse — DevTools内でも実行できます。スコア付きの自動監査で、修正一覧に優先順位を付けます。
• PageSpeed Insights — 上段にCrUXフィールドデータ、下段にLighthouseラボ実行結果を表示します。公開URLのみで、競合サイトにも使えます。
• Chrome UX Report（CrUX） — Googleが実際にランキングに使う実ユーザーフィールドデータセットで、パネルは現在、ローカル結果の横に重ねて表示できます。
• WebPageTest — リモート実機テスト、共有可能な結果、複数ステップのスクリプト。
• Google Search Console — Core Web Vitalsレポート — 大規模なページグループの失敗（フィールドデータ）。
• Search Console — URL Inspection — 「Googlebotは何をクロールし、レンダリングできるか」を知るための正しいツール（パフォーマンスパネルではありません）。
• Microsoft Edge DevTools — Edge／Bingを中心としたワークフローでも使える、同じChromiumパフォーマンスパネルです。

これらがどう組み合わさるか、ラボとフィールドの違い、Googleがどちらをランキングに使うかについては、ウェブパフォーマンスツールハブから始めてください。

トレースを無駄にするパフォーマンスパネルの誤り

1回の記録をフィールドの真実として扱う

パフォーマンスパネルは、1台のローカルブラウザー、デバイス、ネットワークプロファイル、キャッシュ状態、ユーザージャーニーを記録します。ボトルネックの説明には使い、そのボトルネックがどの程度一般的かの判断にはCrUXまたはRUMを使ってください。

再現可能な操作なしに記録する

開放的なままのトレースには、無関係な活動が混ざります。読み込みまたは操作を定義し、同じ状態から開始し、それを取得するのに必要な長さだけ記録してください。

ネットワークとフレームのトラックを見ずにフレームチャートを読む

長いタスクは最初の原因ではなく、結果である可能性があります。担当を決める前に、メインスレッドの処理をリクエスト、操作、スクリーンショット、描画と位置合わせしてください。

重いスロットリングを適用し、その数値をベンチマークと呼ぶ

スロットリングはボトルネックの発見に役立ちますが、結果はラボのシナリオです。前後比較では設定を同一に保ち、結果を共有するときは設定を明記してください。

パフォーマンスパネルのよくある問題を直す

トレースがノイズだらけで読めない

考えられる原因： 拡張機能、バックグラウンドタブ、または長すぎる記録が無関係な処理を追加しています。対処： クリーンなプロファイルを使い、バックグラウンドの活動を閉じ、1つの定義したジャーニーを取得します。確認： 関係する操作または読み込みが、トレース内の短く見分けやすい範囲を占めています。

操作が遅く感じるが、明らかなイベントがない

考えられる原因： 入力から描画までの完全なウィンドウを記録していないか、展開しているトラックが間違っています。対処： 正確なクリック、タップ、キー操作を再記録し、Interactionsとメインスレッドの処理を調べます。確認： 選択したイベントに、入力遅延、処理、表示の処理が現れます。

実行するたびに結果が大きく変わる

考えられる原因： キャッシュ状態、ネットワークの変動、バックグラウンド処理、またはテスト設定が異なります。対処： 再読み込みモード、スロットリング、ビューポート、ジャーニーを標準化してから、複数回実行します。確認： 合計時間が変わっても、同じボトルネックが現れます。

パネルのラボ指標は良好なのにSearch Consoleが悪い

考えられる原因： ローカルトレースが実ユーザーやより長いジャーニーを代表していません。対処： CrUXまたはRUMをセグメント化し、影響を受けたデバイスと操作を再現し、パネルを診断に使います。確認： トレースがフィールド集計と矛盾するのではなく、遅いセグメントを説明します。

トレースに基づく修正が効いたことを証明する

同じジャーニーを繰り返すテスト

実行するテスト： 変更の前後で、キャッシュ、ビューポート、スロットリング設定を同一にして、同じ読み込みまたは操作を記録します。期待する結果： 対象のリクエスト、タスク、レンダリング段階が一貫して短くなります。失敗の解釈： 実行ごとの変動または別のボトルネックが結果を説明しています。監視期間： 複数の記録にわたる直後の期間。ロールバックの条件： エラー、処理の欠落、または視覚的な動作の悪化が現れます。

メインスレッドのテスト

実行するテスト： 両方のトレースで、選択したメインスレッドのタスクとその子を比較します。期待する結果： 削除または遅延された処理が、名前を変えたり前へ移動したりしただけではなく、重要な区間からなくなります。失敗の解釈： 実装が同じコストを別の場所へ移しただけです。監視期間： 直後。ロールバックの条件： ユーザー操作の周囲にある合計ブロッキング時間が増えます。

フィールドへの引き継ぎテスト

実行するテスト： ラボで改善した後、変更したテンプレートまたは操作をRUMで監視します。期待する結果： 影響を受けたフィールド指標とアトリビューションが、対象セグメントで改善します。失敗の解釈： ローカルのシナリオが代表的ではありませんでした。監視期間： トラフィックが到着する間はRUM、ローリングするフィールド期間はCrUX。ロールバックの条件： フィールドパフォーマンスまたはタスク完了が一貫して悪化します。

自分で確認する：Chrome DevToolsパフォーマンスパネル

パフォーマンスパネルとは何か、どう読むか、何ではないかについての簡単な5問です。それぞれ答えを選んでから、確認してください。

時間を使う価値のあるリソース

私の執筆

• JavaScript SEO：知っておくべきこと — パフォーマンスタブの読み込みチャートを使い、Googlebotのレンダリングが完全なブラウザーの描画とどう異なるかを説明しています。
• SEO担当者と開発者のためのGoogle PageSpeed Insights — DevToolsで得られる生のトレースを補完する、スコア付きのフィールド＋ラボツールです。
• テクニカルSEO初心者向けガイド — パフォーマンスとレンダリングをより大きな全体像の中に位置づけています。

私の講演

• Page Experience Update（TMC、2021年6月） （SlideShare）— DevToolsでLCP要素を見る方法を手順ごとに示しています。
• ページエクスペリエンスの次の展開（SMX Next 2021） （SlideShare）— 同じ時期のページエクスペリエンスに関する講演です。

業界の資料

• パフォーマンスパネルの概要 （Chrome for Developers）— 何であるか、開き方、ライブ指標を知るための正式な出発点です。
• 実行時パフォーマンスを分析する （Chrome for Developers）— フレームチャート、FPS／CPU、記録の手順。
• DevToolsでローカルと実ユーザーのCore Web Vitalsを監視する （ChromeのRick Viscomi）— 再設計されたランディングページとCrUXフィールドデータオーバーレイ。
• 2024年以降のパフォーマンスツール （ChromeのSweenyとIrish）— TimelineからPerformanceへの歴史と、Lighthouse／Insightsとの関係。
• Chrome DevToolsをSEOトラブルシューティングに使う3つの方法 （Search Engine JournalのRichie Lauridsen）— 既存のSEO向け解説として最も近く、LCP発見手法も含みます。
• DevToolsのPerformanceタブでサイト速度をプロファイルする （DebugBear）— 強制リフローのデバッグ、レイヤー分析、明瞭に見るためのスロットリングを扱う、SEO以外では最も詳しい技術解説です。
• Chrome DevToolsでウェブパフォーマンスをデバッグする （Web Performance Calendar、2025年）— 再設計後のパネルのワークフローに関する、現在のコミュニティ視点です。

変更履歴