パフォーマンス データとデバッグ情報を関連付ける方法の詳細 アナリティクスを使用して実際のユーザーが直面する問題を特定して修正できます。
Google では、パフォーマンスの測定とデバッグのためのツールとして、次の 2 つのカテゴリを提供しています。
- ラボツール: ページが Lighthouse などのツールで読み込まれるため、 さまざまな条件を再現できるシミュレーション環境(低速な ローエンドのモバイル デバイスが必要です。
- フィールド ツール: Chrome ユーザー エクスペリエンスなどのツール レポート (CrUX)を開発しました。( PageSpeed などのツールによってレポートされるフィールド データ 分析情報と検索 コンソールのソース CrUX データ)
フィールド ツールはより正確なデータ(実際に何を表しているかを示すデータ)を提供する 実際のユーザー エクスペリエンス。多くの場合、ラボツールは、問題の特定と修正に サポートします。
CrUX データはページの実際のパフォーマンスを より正確に表していますが CrUX スコアは、顧客満足度を向上させる方法の 向上します
一方、Lighthouse では、問題を特定し、 改善方法の提案が表示されますただし Lighthouse では、候補となるのは パフォーマンスの問題を検出します問題が検出されない スクロールやクリックなどのユーザー操作の結果としてのみ現れる クリックします。
このことから、Google Cloud のアプリケーションのデバッグ情報を Core Web Vitals など、実際に現場のユーザーから得たパフォーマンス指標は何ですか。
この投稿では、その他のデータの収集に使用できる API について詳しく説明します。 最新の Core Web Vitals 指標のデバッグ情報を確認できるほか、 既存の分析ツールでこのデータを取得する方法の アイデアが得られます
アトリビューションとデバッグ用の API
Cumulative Layout Shift(CLS)
Core Web Vitals の中でも、CLS はおそらく 最も重要なのは、デバッグ情報の収集です。CLS を測定 ページ全体を通じて広告が配信されるため ユーザーがどこまでスクロールしたか、何をクリックしたかなど)が、 レイアウト シフトの有無やシフトする要素が影響を受けます。
PageSpeed Insights の以下のレポートについて考えてみましょう。
<ph type="x-smartling-placeholder">ラボ(Lighthouse)の CLS について報告された値と、Google で報告された CLS の CrUX データはまったく異なっており、 このページには多数のインタラクティブな コンテンツが含まれている可能性があります Lighthouse でのテスト時には使用されません。
ユーザーの操作がフィールド データに影響することがわかっていても、 ページのどの要素がシフトしているかを知る必要があり、その結果スコアは 0.28 75 パーセンタイルで評価されますLayoutShiftAttribution インターフェースがそれを実現します。
レイアウト シフトのアトリビューションを取得する
LayoutShiftAttribution
インターフェースが、Layout Instability を示す各 layout-shift
エントリで公開される
API が出力します。
この 2 つのインターフェースの詳細については、デバッグ レイアウトをご覧ください。 シフトします。目的 この投稿で知っておくべき主なことは、デベロッパーは ページ上で発生したすべてのレイアウトシフトと 変化しています
以下に、各レイアウト シフトと要素をログに記録するサンプルコードを示します。 変化しました。
new PerformanceObserver((list) => {
for (const {value, startTime, sources} of list.getEntries()) {
// Log the shift amount and other entry info.
console.log('Layout shift:', {value, startTime});
if (sources) {
for (const {node, curRect, prevRect} of sources) {
// Log the elements that shifted.
console.log(' Shift source:', node, {curRect, prevRect});
}
}
}
}).observe({type: 'layout-shift', buffered: true});
データを測定して分析ツールに送信するのは、おそらく実用的ではありません。 レイアウト シフトが発生するたびにすべてのシフトをモニタリングすることで、 最も悪かった変化を追跡し、その変化に関する情報のみを報告できます。
目標は、すべてのレイアウト シフトを特定して修正することではありません。 すべてのユーザー目標は 最大数に影響を与えた変化を ページの CLS に最も大きく寄与している割合が 75 パーセンタイルです。
また、イベントが発生するたびに最大のソース要素を計算する必要も 変更する必要があるのは、データに CLS 値を送信する準備ができた場合のみです。 分析ツール
次のコードは、寄与する layout-shift
エントリのリストを受け取ります。
最大シフトから最大のソース要素を返します。
function getCLSDebugTarget(entries) {
const largestEntry = entries.reduce((a, b) => {
return a && a.value > b.value ? a : b;
});
if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
const largestSource = largestEntry.sources.reduce((a, b) => {
return a.node && a.previousRect.width * a.previousRect.height >
b.previousRect.width * b.previousRect.height ? a : b;
});
if (largestSource) {
return largestSource.node;
}
}
}
最大の変化に大きく寄与している要素を特定したら、 分析ツールに報告できます
あるページで CLS に最も大きく影響する要素は、通常、 すべてのユーザーからこれらの要素を集計すると 多くのユーザーに影響を与える要素のリストを生成できます。
それらの変化の根本原因を特定して修正した後 要素があると、アナリティクス コードでより小さなシフトが「最悪」としてレポートされるようになります。 ページの変化を確認できます最終的には、報告される変化はすべて ページは「優良」のしきい値 0.1 です。
最大のシフトと同時にキャプチャすると役立つ可能性のあるその他のメタデータ ソース要素は次のとおりです。
- 最大シフトの時刻
- 最大シフト時の URL パス(動的に (シングルページ アプリケーションなど)は URL を更新できません)。
Largest Contentful Paint(LCP)
フィールドで LCP をデバッグするには、 その特定の要素(LCP 候補要素)の最大の要素 ページの読み込み。
なお、LCP は、 ユーザー候補要素は、まったく同じでもユーザーごとに異なります。 できます。
この問題は次のような原因で発生することがあります。
- ユーザーのデバイスの画面解像度が異なるため、 ページ レイアウト、つまりさまざまな要素がビューポート内に表示されます。
- ユーザーは必ずしも最上部にスクロールしたページを読み込むとは限りません。リンクは多くの場合 フラグメント識別子を含む テキスト フラグメントを利用できます。つまり、 ページ上の任意のスクロール位置でページが読み込まれ、表示されるようにします。
- コンテンツは現在のユーザーに合わせてパーソナライズされる場合があるため、LCP 候補要素は ユーザーごとに大きく異なる場合があります
つまり、どの要素や要素のセットを推測できない 特定のページで最も一般的な LCP 候補要素となります。必要があります。 実際のユーザー行動に基づいて パフォーマンスを測定できます
LCP 候補要素を特定する
JavaScript で LCP 候補要素を特定するには、Largest Contentful Paint API を使用すると、 (LCP 時間値の決定に使用するのと同じ API)を使用する必要があります。
largest-contentful-paint
エントリを監視している場合、
最後のエントリの element
プロパティを見て、現在の LCP 候補要素を確認します。
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});
LCP 候補要素を把握したら、分析ツールに送信できます 指標値が表示されます。CLS と同様に、これにより 最適化することが最も重要です。
LCP 候補要素に加えて、指標のしきい値を LCP サブパート時間: サイトに適した具体的な最適化ステップを判断する上で役立ちます。
Interaction to Next Paint(INP)
INP のフィールドで収集する最も重要な情報は次のとおりです。
- 操作された要素
- そのインタラクションの種類
- そのやり取りが行われた日時
やり取りが遅くなる主な原因は、ブロックされたメインスレッドです。 JavaScript の読み込み中によく使用されます。最も遅いインタラクションの 何が起こっているのかを知ることで、何を修復すべきかを判断できます 解決できます。
INP 指標は VM 全体のレイテンシを (たとえば、登録済みのイベント リスナーを すべてのイベント リスナーが呼び出された後、次のフレームを描画するのにかかる時間です。 確認できます。つまり、INP にとってどのターゲットが 要素のインタラクションが遅くなる傾向があり、どのようなインタラクションが あります
次のコードは、INP エントリのターゲット要素と時刻をログに記録します。
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
console.log('INP time:', inpEntry.startTime);
}
なお、このコードでは、どの event
エントリが INP であるかを判断する方法については示していません。
そのロジックはより複雑なものになります。ただし、次のセクションでは、
kubectl の「get pods」
web-vitals JavaScript ライブラリを配布できます。
web-vitals JavaScript ライブラリの使用
前のセクションでは、一般的な推奨事項とコードの例を紹介しました。 分析ツールに送信するデータに含めるデバッグ情報
バージョン 3 以降では、web-vitals JavaScript ライブラリには 構築 すべての情報が表示され、さらにいくつかの追加機能が できます
次のコードサンプルは、追加のイベントを設定する方法を示しています。 パラメータ(または custom ディメンション)を含む パフォーマンスの根本原因の特定に役立つデバッグ文字列 サポートします。
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'CLS':
eventParams.debug_target = attribution.largestShiftTarget;
break;
case 'LCP':
eventParams.debug_target = attribution.element;
break;
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
break;
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
このコードは Google アナリティクス専用ですが、基本的には 他の分析ツールにも応用できます
このコードでは、単一のデバッグ シグナルをレポートする方法も示されていますが、 複数の異なるシグナルを収集して レポートに表示すると便利です 表示されます。
たとえば、INP をデバッグするには、 操作の種類、時間、loadState、 (Long Animation Frame Data など)。
web-vitals
アトリビューション ビルドでは、追加のアトリビューション情報が公開されます。
次の例をご覧ください。
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
eventParams.debug_type = attribution.interactionType;
eventParams.debug_time = attribution.interactionTime;
eventParams.debug_load_state = attribution.loadState;
eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
eventParams.debug_presentation_delay = Math.round(attribution.presentationDelay);
break;
// Additional metric logic...
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
詳しくは、web-vitals アトリビューション モデル ドキュメント 公開されているデバッグ シグナルの完全なリスト。
データのレポートと可視化
デバッグ情報と指標値の収集を開始したら、 全ユーザーのデータを集計して パターンと傾向を把握します
前述のように、必ずしもすべての問題に対処する必要はありません。 特にまずは問題に対処する必要があります この問題は、この問題にも対処する必要があります。 Core Web Vitals のスコアにマイナスの影響が最も大きいものを確認できます。
GA4 については、 BigQuery。
概要
この投稿が、Google Chat で Google Meet を使用する具体的な
既存のパフォーマンス API と web-vitals
ライブラリを使用してデバッグ情報を取得する
実際のユーザー数に基づいてパフォーマンスを診断できます。この
Core Web Vitals に重点を置いているため、このコンセプトはデバッグにも
JavaScript で測定可能な
パフォーマンス指標です
パフォーマンスの測定を始めたばかりで Google アナリティクスをご利用の場合は、ウェブに関する指標レポートツールから始めることをおすすめします。 Core Web のデバッグ情報のレポート作成がサポートされているためです。 指標。
分析ベンダーの方で、サービスやプロダクトの改善、 詳細なデバッグ情報をユーザーに提供するには、 ここで説明するアイデアだけにとどまらないでください。 見てみましょう。この投稿は、一般的にあらゆる分析ツールに適用されることを想定しています。 ただし、個々の分析ツールは デバッグ情報を確認できます。
最後に API 自体に欠けている機能や情報がある場合は、 web-vitals-feedback@googlegroups.com.