公開日: 2024 年 9 月 17 日
前回の記事では、DevTools でパフォーマンス ワークフローをカスタマイズするための 3 つの新機能について説明しました。これらの人間工学的な改善は、Core Web Vitals の最適化を DevTools でより簡単に、より効果的に行うための数年にわたる取り組みの始まりに過ぎません。本日、次の一連の機能がリリースされます。ローカル Core Web Vitals のパフォーマンスのライブビューを備えた、完全に再設計されたパフォーマンス パネルのランディング ページです。
![DevTools の [パフォーマンス] パネルのローカルとフィールドの指標](https://developer.chrome.com/static/blog/devtools-realtime-cwv/image/performance-live.png?authuser=00&hl=ja)
この投稿では、以下の新機能について詳しく説明します。
ローカルの Core Web Vitals のリアルタイム パフォーマンス
ローカル エクスペリエンスのパフォーマンスを測定できることは、Core Web Vitals のデバッグ ワークフローの重要な要素です。実際のユーザーの問題を再現できるかどうかに影響する可能性があります。ただし、ローカル パフォーマンスの測定は、必ずしも簡単ではありませんでした。
![DevTools の [パフォーマンス] パネルのトレースビュー](https://developer.chrome.com/static/blog/devtools-realtime-cwv/image/performance-trace.png?authuser=00&hl=ja)
これまで、DevTools の [パフォーマンス] パネルには、ネットワーク リクエストと CPU アクティビティの詳細なタイムラインが表示されていました。これは、パフォーマンスのデバッグに非常に便利なツールです。ただし、パフォーマンスの問題を再現するのは難しい場合があります。録画が完了するまでパフォーマンスが低下しているかどうかはわかりません。ウェブに関する指標拡張機能で学んだように、DevTools でローカルの Core Web Vitals のパフォーマンスにアクセスできることは、大きな変化をもたらします。そこで、拡張機能から得たすべての教訓を活かし、これらの機能を [パフォーマンス] パネルに直接組み込むことにしました。
ウェブに関する主な指標のすべての指標が、初めて [パフォーマンス] パネルで利用可能になりました。[パフォーマンス] パネルを開くと、ローカル エクスペリエンスのパフォーマンスがすぐに確認できます。録画は必要ありません。実際、DevTools を開いておく必要はありません。指標はバックグラウンドで収集され、必要なときにいつでも利用できます。これは、特定の問題を積極的にデバッグしようとしていないが、何かが遅く感じられてその理由を把握したい場合に便利です。
パネルの [ローカル指標] セクションには、ローカルの Core Web Vitals 指標（Largest Contentful Paint、Cumulative Layout Shift、Interaction to Next Paint）のライブビューが表示されます。ページの読み込みと操作に伴い、これらの指標はリアルタイムで更新されます。また、パフォーマンスの良し悪しを示すしきい値に応じて色分けされているため、パフォーマンスの問題が発生したときに簡単に見つけることができます。
実際のユーザー エクスペリエンス データ
ほとんどのユーザーが遭遇しないパフォーマンスの問題を最適化するのは、時間の無駄になる可能性があります。同様に、ローカル環境で速度が現実離れしている場合は、実際の問題を見落としている可能性があります。そのため、時間の使い方についてより的確な判断を行うには、ローカルのパフォーマンスをフィールドでの実際のユーザー エクスペリエンス データと比較する必要があります。
パフォーマンス パネルで、ローカル エクスペリエンスの横に実際のユーザーデータが表示されるようになりました。データは公開されている CrUX API に基づいています。これは、特定のウェブページとオリジンでの実際のユーザー エクスペリエンスの 28 日間の集計です。有効にするには、[フィールドデータ] セクションで [設定] をクリックし、構成ダイアログの手順に沿って操作します。
個々の URL とオリジン（ウェブサイト全体）が CrUX データセットに含まれるには、特定の資格要件を満たしている必要があります。十分なデータがある場合は、ユーザー エクスペリエンスはパソコンとモバイル デバイスの種類別に集計されます。DevTools は、ローカル環境に最も関連性の高いデータを自動的に表示するように最善を尽くします。利用可能な場合は、デフォルトで同じ URL とデバイスタイプが表示されます。パソコンまたはモバイル単位のデータが不足している場合は、すべてのデバイスタイプを対象とした集計データが表示されます。
75 パーセンタイル値に加えて、任意の指標にカーソルを合わせると、各評価における実際のユーザー エクスペリエンスの割合を確認できます。この例では、ローカルの Largest Contentful Paint のエクスペリエンスが異常に遅く、実際のユーザー エクスペリエンスの 12% に相当しています。
このデータを使用すると、ローカル環境のエクスペリエンスがどの程度代表的であるかを明確に把握し、一般的なユーザー エクスペリエンスに近づけるように微調整できます。
ローカル環境を構成するための推奨事項
ラボデータとフィールドデータには多くの違いがあり、ページにアクセスして操作する方法がさまざまなため、その違いはさらに複雑になります。環境を構成することで、これらの違いの一部を考慮し、ローカル環境をより代表的なものにすることができます。
フィールドデータが有効で利用可能な場合、[録画設定] セクションに、実際のユーザーが使用する最も一般的なデバイスタイプをエミュレートすることが提案されます。デバイスモードを有効にすると、モバイル デバイスのビューポート サイズをエミュレートできます。レスポンシブ インターフェースでは、最大コンテンツの描画に関連付けられる要素が変更され、パフォーマンス特性が大きく異なる場合があります。モバイル レイアウトでは、モバイル ユーザーのみが操作できるナビゲーション メニューなどの特定の要素が表示されたり、大画面のビューポートでは発生しない独自のレイアウト シフトが発生したりすることもあります。
このセクションでは、低速 4G などの特定のネットワーク スロットリング構成が推奨されることもあります。ネットワークに関する推奨事項は、そのページまたはウェブサイトでの実際のユーザー エクスペリエンスから集計された、ラウンドトリップ時間の 75 パーセンタイルの指標に基づいています。ネットワーク速度が遅い場合、ページの読み込みパフォーマンスの特性により、実際のパソコン ユーザーとモバイル ユーザーの両方にとってよりリアルな読み込みが実現し、改善の余地を簡単に見つけることができます。また、レイアウト シフトは、操作から 500 ミリ秒以内に発生しなかった場合にのみ、累積レイアウト シフト指標にカウントされます。ユーザー開始型レイアウト シフトがネットワーク リクエストの結果である場合、ローカルでレイアウト シフトを検出する唯一の方法は、ネットワークをスロットリングすることです。
CPU をスロットリングすることも、ローカル デバイスを実際のユーザーのように動作させる方法の一つです。CPU スロットリングは、モバイル デバイスの比較的遅い動作をエミュレートするのに適しています。高速なマシンでは、さらにスロットリングが必要になります。DevTools に最近追加されたCPU を 20 倍にスロットリングする機能は、デベロッパーがよく使用する高性能のデスクトップ マシンに特に便利です。CPU がスロットリングされると、スクリプトの実行速度が低下し、長いタスクになる可能性が高くなります。これにより、Interaction to Next Paint の問題が発生する可能性があります。同じ理由で、他の Core Web Vitals 指標も、スクリプトの実行速度が遅い場合に影響を受ける可能性があります。特に、レイアウトを変更するコンテンツや要素のレンダリングがブロックされている場合はその可能性が高くなります。
より現実的なビューポート、ネットワーク、CPU の設定でローカル環境を構成すると、気付かなかったパフォーマンスの問題が浮き彫りになる可能性があります。実際のユーザーデータに基づく推奨事項により、推測に頼ることなく問題を特定して修正できるため、問題の解決に集中できます。
問題を再現するための情報
ローカル パフォーマンスは、環境の構成方法とページの操作方法に大きく依存します。たとえば、一般的なウェブページでは、モバイル ビューポートのサイズで Largest Contentful Paint 要素が画像である可能性は低くなります。テキスト フィールドに 1 文字入力するのは速くても、複数の文字を連続して入力すると、次のペイントまでのインタラクション時間が長くなる可能性があります。指標に関する追加情報を確認することで、この指標を理解し、再現性の高いテストを実施できます。
Largest Contentful Paint 指標に関連付けられた LCP 要素には、要素自体へのリンクが表示されます。リンクにカーソルを合わせると、ページ上の要素がハイライト表示されます。リンクをクリックすると [要素] パネルが表示され、ドキュメントの全体的なコンテキストで要素を確認できます。
[インタラクション] セクションには、DevTools が開いている間に発生した対象となるすべてのインタラクションのリアルタイム ログが表示されます。入力、タップ、クリックなどの操作ごとに、追加情報がログに記録されます。これにより、発生した事象と再現方法を把握しやすくなります。
インタラクション タイプ（ポインタ イベントまたはキーボード イベント）に加えて、インタラクション ターゲットへの参照が表示されます。LCP 要素と同様に、インタラクション ターゲット自体もインタラクティブです。ターゲットにカーソルを合わせるとページ上でハイライト表示され、クリックすると要素パネルに表示されます。インタラクション レイテンシも、Interaction to Next Paint 指標のしきい値と同じ色分けで表示されるため、遅いインタラクションを見つけやすくなります。
デバッグしようとしているパフォーマンスの問題を再現できたら、プロファイリングを開始できます。[次のステップ] セクションで、[記録して再読み込み] ボタンを使用して、Largest Contentful Paint や読み込み時間の Cumulative Layout Shift などの読み込みパフォーマンスの問題をデバッグします。ユーザー操作の結果として発生する問題をデバッグするには、[記録] ボタンを使用してページをプロファイリングし、遅い操作や読み込み後のレイアウト シフトを手動で再現します。
次のステップ
パフォーマンス ワークフローをリアルタイムのローカルデータと現場の実際のユーザーデータに基づいて行うことで、指標のデバッグと最適化にどの程度の労力を割くべきかを判断できます。このデータを使用してローカル環境を調整し、ユーザーのデバイスの種類、CPU の速度、ネットワーク構成をよりリアルにエミュレートして、パフォーマンスの問題をより適切に再現できるようにする必要があります。
ウェブバイタル拡張機能をご利用の方は、これらの機能の多くをすでにご存じでしょう。拡張機能にどのような影響があるか、疑問に思われるかもしれません。これらの変更が拡張機能に与える影響については、今後数週間以内に改めてお知らせいたします。
パフォーマンス パネルの改善は始まったばかりで、今後もさらに改善を進めていく予定です。近日中に、この投稿で最新情報をお知らせいたします。それまでは、[パフォーマンス] パネルでこれらの新機能をすべてお試しいただき、ご意見をお寄せください。フィードバックがございましたら、公開されている問題のコメント欄でお知らせください。