このページは Cloud Translation API によって翻訳されました。

現場でパフォーマンスをデバッグ

パフォーマンスデータとデバッグ情報を関連付ける方法の詳細アナリティクスを使用して実際のユーザーが直面する問題を特定して修正できます。

Philip Walton

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 の以下のレポートについて考えてみましょう。

さまざまな CLS 値を含む PageSpeed Insights レポート — PageSpeed Insights では、可能な場合はフィールドデータとラボデータの両方が表示されますが、これらは異なる場合があります。

ラボ（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 のデバッグ情報のレポート作成がサポートされているためです。 Vitals をご覧ください。

分析ベンダーの方で、サービスやプロダクトの改善、詳細なデバッグ情報をユーザーに提供するには、ここで説明するアイデアだけにとどまないでください。見てみましょう。この投稿は、一般的にあらゆる分析ツールに適用されることを想定しています。ただし、個々の分析ツールはデバッグ情報を確認できます。

最後に API 自体に欠けている機能や情報がある場合は、 web-vitals-feedback@googlegroups.com