実際のデータを使用した DevTools パフォーマンス デバッグの精度向上

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Brendan Kenny

公開日: 2025 年 4 月 4 日

実際のパフォーマンスの問題を解決するには、開発環境とユーザーのさまざまなパフォーマンス エクスペリエンスのギャップを埋める必要があります。この記事では、パフォーマンスのデバッグに関する判断を推測ではなく実際のデータに基づいて行うための Chrome DevTools の新機能をご紹介します。

期待値の調整

Chrome 134 以降、DevTools に CPU スロットリング キャリブレーションが追加されます。これは、適切な CPU スロットリング レベルを選択する際の不確実性を解消する新しいツールです。調整を 1 回実行すると、DevTools によって、開発マシンに固有の「ローティア モバイル」と「ミッドティア モバイル」のスロットリング プリセットが生成されます。

ウェブ パフォーマンスの作業でよく見られる不一致は、デベロッパーが高速なパソコン デバイスでサイトを構築する一方で、多くのユーザーが比較的低スペックのモバイル デバイスを使用していることです。パフォーマンスの問題が、CPU が非常に遅いデバイスでのみ発生する場合は、問題の特定が難しい場合があります。

ゴールド スタンダードは実際のモバイル デバイスでのリモート デバッグですが、Chrome ではほぼ 10 年間、開発中の高速で軽量な反復処理サイクルのために CPU スロットリングもサポートされています。

では、どの CPU スロットリング レベルを選択すればよいですか。4 倍？20 倍?サイトにアクセスしているデバイスの種類に最も適したものをどのように判断すればよいですか？ハイエンドのワークステーションを使用している場合と、外出先で 8 年前の Chromebook を使用している場合では、マシンの速度によってその判断は変わりますか？

スロットリング調整プロセス

[パフォーマンス] パネルを開くと、[環境設定] に CPU スロットリング レベルを設定するためのプルダウンが表示されます。調整をまだ行っていない場合は、プルダウンの [調整済みのプリセット] に無効なオプションが 2 つ表示され、一番下に [調整...] オプションが表示されます。

これを選択すると、[設定] の CPU スロットリング プリセットに移動します（直接移動することもできます）。

1. [調整] ボタンをクリックします。
2. 現在のページから短時間移動する旨の警告が表示されたら、[続行] をクリックします。
3. 簡単なベンチマークが実行され、現在のマシンの速度が測定されます。これでキャリブレーションが完了します。

スロットリング オプションに、低価格帯デバイスと中価格帯デバイス向けの調整済みプリセットが入力されるようになりました。

これらの 2 つのプリセットは、ほとんどの開発ユースケースで十分です。通常は、ウェブでよく見られる「一般的な」モバイル デバイスに一致するため、「中程度」のプリセットをおすすめします。多くのユーザーがさらに低速のデバイスを使用している場合や、パフォーマンスの問題が通常はそのようなユーザーにのみ発生する場合は、[低階層] オプションを、ローエンド デバイスのロングリテールまでカバーできるほど低速にする必要があります。

最後に、キャリブレーションに問題があると思われる場合や、ローカルマシンが何らかの形で変更された場合は、スロットリング プルダウンまたは設定でいつでも再キャリブレーションできます。これにより、ベンチマークが再実行され、プリセットが更新されます。

DevTools での CPU スロットリングの仕組み

DevTools での CPU スロットリングの仕組みに興味をお持ちなら、その仕組みは比較的単純です。タブのスロットリングをオンにすると、Chrome は個別のスロットリング スレッドを起動します。このスレッドは、タブのメインスレッドを中断して短いバーストを頻繁に発生させます。目標は、特定のタスクの所要時間がスロットリング係数分長くなるように、メインスレッドを合計で十分長く停止することです。

たとえば、CPU スロットリングが 4 倍の場合、メインスレッドは約 75% の時間中断されるため、メインスレッドの処理が完了するまでに 4 倍の時間がかかります。

このアプローチの利点は、Chrome の他の部分に対してほとんど透過的であることです。JavaScript やレイアウト、ブラウザが行う必要がある他の多くの種類の処理を遅らせるために必要な特殊なコードはありません。スレッド自体はごく短い時間しか実行できないため、メインスレッドでのすべての処理に時間がかかります。

CPU スロットリングが実際のモバイル デバイスのように動作する

その結果、CPU スロットリングによって、さまざまな種類のモバイル CPU バウンド処理が適切にシミュレートされます。たとえば、インタラクションによって JavaScript とレイアウトがトリガーされると、モバイル デバイスで実行された場合と非常によく似た結果が得られる可能性があります。

ボタンのクリックによってトリガーされ、JavaScript を実行して DOM に新しい要素を追加するタスクについて考えてみましょう。このタスクでは、ブラウザがスタイルとレイアウトの計算を実行して新しいコンテンツを配置する必要があります。

キャリブレーション済みの「ミッドティア モバイル」CPU スロットリング プリセット（この開発マシンでは 3.7x）では、インタラクションの外観は非常に似ていますが、時間が大幅に長くなり、長いタスクになります。

リモート デバッグを使用して実際のミッドティア デバイスで同じインタラクションをテストすると、インタラクションのトレースの時間と形の両方で非常に類似した結果が得られます。このタスクは、ページの JavaScript コードと Chrome のスタイルとレイアウト コードの実行など、ほとんどがメインスレッドで CPU バウンドであるため、調整済みのスロットリングにより、実際のモバイル パフォーマンスが正確に再現されます。

実際のモバイル デバイスでテストする必要がある場合

CPU スロットリングは非常に便利ですが、モバイル ハードウェアのすべての側面をシミュレートできるわけではありません。スマートフォンでは、ディスク速度が遅く、メモリ帯域幅が制限され、サーマル スロットリングがいつでも有効になって実行速度が低下する可能性があります。

一般的なスロットリング制限には、GPU 使用率の高い作業が含まれます。モバイルとパソコンの GPU のアーキテクチャは異なります。Chrome では、GPU オペレーションはページのメインスレッドとは別のプロセスで実行されます。そのため、DevTools の CPU スロットリングは GPU プロセスには影響しません（DevTools 自体と他のブラウザの応答性に影響するため、これは好ましいことです）。

複雑なペイント、合成、エフェクトを多用したスタイル設定は、開発マシンでは問題ないように見えても、モバイルでは想定外の遅延が発生する一般的なパフォーマンスの問題です。また、開発マシンで問題を再現しようとしたときに、問題があることに気づくのは難しい場合があります。

前述の操作（クリックして DOM に多くの要素を追加する）と同じことを考えてみましょう。ただし、今回は新しい要素に GPU 使用量の多い box-shadow とぼかしフィルタが過剰に適用されています。

インタラクションの開始形状と時間は似ていますが、追加されたエフェクトのために、最後に長い新しいメインスレッド ペイントがあります。

実際の中級スマートフォンでは、追加のペイントを含め、インタラクションのメインスレッド部分はシミュレートされたものと非常によく似ていますが、インタラクションの結果が画面に表示されるまで、野生の GPU プロセスが膨大な量の処理を行っているようです。

GPU 処理により、インタラクション時間がさらに 300 ミリ秒長くなります。この処理は、（メインスレッドの）CPU スロットルが有効になっている場合でも、ノートパソコンの GPU ではほとんど行われません。

シミュレートされたネットワーク スロットリング、プロセス間通信、ディスク キャッシュとメモリ キャッシュへのアクセスが相互に作用する、深い依存関係のあるページの読み込みなど、エミュレーションに大きな欠点があるケースが他にもあります。

必ず、ある時点で実際のモバイル デバイスでテストしてください。フィールド データでモバイル ユーザーに影響していると示されている問題を、ラボのパソコンで再現できない場合は、実際のデバイスでリモート デバッグを試して、見落としている違いがないかどうかを確認してください。

データドリブン デバッグの改善

先ごろ、実際のユーザーに基づいてデバッグ設定や判断を下すことを容易にするための新機能もいくつか追加されました。

フィールド データを有効にしている場合、[パフォーマンス] パネルには、Chrome ユーザー エクスペリエンス レポート（CrUX）で測定された 75 パーセンタイル ユーザーに基づくスロットリングに関する推奨事項が表示されます。また、ローカルで測定した指標がフィールド データと異なる場合は、リアルタイム指標ビューでアラートが表示されます。この点については、実際の Core Web Vitals データを DevTools に取り込む方法に関する以前の投稿で詳しく説明しています。

新たに追加された機能として、サイドバーのパフォーマンス パネルの分析情報で、トレース内で測定された指標がユーザーが実際に体験しているものと一致しない場合にもアラートが表示されるようになりました。

フィールド データを有効にすると、75 パーセンタイル値の Core Web Vitals を使用して、サイドバーに表示される分析情報の順序をランク付けすることもできます。たとえば、ユーザーの Largest Contentful Paint（LCP）は良好だが Interaction to Next Paint（INP）が低い場合、INP の改善に役立つ分析情報がリストの上位に表示されます。

最後に、複数のトレース間を切り替えたり、ディスクからトレースを読み込んだりしていると、各トレースで使用したモバイル エミュレーションとスロットリング設定を正確に覚えておくのは難しい場合があります。[パフォーマンス] パネルの上部にあるトレース選択 arrow_drop_down プルダウンに、各トレースのエミュレーション情報が表示されるようになります。

停止、キャリブレーション、リスニング

最終的には、分析とユーザー レポートのフィールド データから問題を特定し、ラボでそれらのユーザー エクスペリエンスを再現して診断するなど、実際の状況に基づいてデバッグに関する決定を行う必要があります。これらの新しい DevTools の追加により、そのプロセスが少し楽になるはずです。

フィールドとラボでのテスト結果が異なる場合の CPU スロットリング キャリブレーションとアラートは、正しい方向に進んでいるかどうかの不確実性を軽減し、実際のパフォーマンスをより一貫して近似できます。構成の推測を排除し、潜在的な不一致をハイライト表示することで、ユーザーに影響する実際のパフォーマンスの問題の修正に集中できるようにすることが DevTools の目的です。

改善点や新機能のアイデアをお持ちでしたら、お聞かせください