バックグラウンド サービスをデバッグする

Kayce Basques
Kayce Basques
X GitHub
Sofia Emelianova
Sofia Emelianova
GitHub

Chrome DevTools の [バックグラウンド サービス] セクションは、ユーザーがウェブサイトを開いていない場合でも、ウェブサイトで更新の送受信を可能にする JavaScript API のツールを集めたものです。バックグラウンド サービスは、機能的にはバックグラウンド プロセスと似ています。

[バックグラウンド サービス] セクションでは、次のバックグラウンド サービスをデバッグできます。

Chrome DevTools では、DevTools が開いていない場合でも、フェッチ、同期、通知のイベントを 3 日間記録できます。これにより、イベントが想定どおりに送信および受信されていることを確認できます。

DevTools では、バックグラウンド サービス イベントに加えて、次のこともできます。

バックグラウンド フェッチ

バックグラウンド フェッチ API を使用すると、Service Workerが、映画やポッドキャストなどの大きなリソースをバックグラウンド サービスとして確実にダウンロードできます。DevTools が開いていない場合でも、バックグラウンド フェッチ イベントを 3 日間記録するには:

  1. Background Fetch API を使用しているページで DevTools を開きます。

  2. [Application] > [Background services] > [Background fetch] に移動し、録画。 [Record] をクリックします。

    [バックグラウンド フェッチ] タブ。

  3. ページで、バックグラウンド フェッチ アクティビティをトリガーします。DevTools はイベントをテーブルに記録します。

    [バックグラウンド取得] タブのイベントログ。

  4. イベントをクリックすると、表の下のスペースに詳細が表示されます。

  5. DevTools を閉じて、録画を最大 3 日間実行したままにできます。録画を停止するには、停止して。 [停止] をクリックします。

バックグラウンド同期

Background Sync API を使用すると、オフラインのService Workerが、信頼できるインターネット接続を再確立したときにサーバーにデータを送信できます。DevTools が開いていない場合でも、バックグラウンド同期イベントを 3 日間記録するには:

  1. たとえば、このデモページで DevTools を開きます。

  2. [Application] > [Background services] > [Background sync] に移動し、録画。 [Record] をクリックします。

    [バックグラウンド同期] タブ。

  3. デモページで [Register background sync] をクリックしてそれぞれの Service Worker を登録し、プロンプトが表示されたら [許可] をクリックします。

    Service Worker の登録はバックグラウンド同期アクティビティです。DevTools はイベントをテーブルに記録します。

    [バックグラウンド同期] タブのイベントログ。

  4. イベントをクリックすると、表の下のスペースに詳細が表示されます。

  5. DevTools を閉じて、録画を最大 3 日間実行したままにできます。録画を停止するには、停止して。 [停止] をクリックします。

（試験運用版）バウンス トラッキング対策

Chrome のバウンス トラッキング対策試験運用では、バウンス トラッキング手法を使用してクロスサイト トラッキングを行っていると思われるサイトの状態を特定して削除できます。トラッキングの軽減を手動で強制適用し、状態が削除されたサイトのリストを確認できます。

トラッキング対策を強制するには:

  1. Chrome でサードパーティの Cookie をブロックする。その他メニュー。 > [設定] > セキュリティ。 [プライバシーとセキュリティ] > [Cookie と他のサイトデータ] > ラジオボタンが選択されています。 [サードパーティ Cookie をブロックする] に移動して有効にします。
  2. chrome://flags で、バウンス トラッキング対策テストを [削除ありで有効] に設定します。
  3. DevTools を開き、[Application] > [Background services] > [バウンス トラッキングの緩和策] に移動します。
  4. バウンスリンクをクリックし、Chrome がバウンスを記録するまで 10 秒間待ちます。[問題] タブに、今後の状態の削除に関する警告が表示されます。
  5. [強制実行] をクリックして、状態をすぐに削除します。

バウンス トラッキング対策に状態の削除がリストされます。

通知

Service Workerがサーバーからプッシュ メッセージを受信すると、Service Worker は Notifications API を使用してデータをユーザーに表示します。DevTools が開いていない場合でも、3 日間通知を記録するには:

  1. DevTools を開く

  2. [Application] > [Background services] > [Notifications] に移動し、録画。 [Record] をクリックします。

    [通知] タブ。

  3. [通知のスケジュール] をクリックし、プロンプトが表示されたら [許可] をクリックします。

  4. 通知が表示されるまで待ちます。DevTools は通知イベントをテーブルに記録します。

    [通知] タブのイベントのログ。

  5. イベントをクリックすると、表の下のスペースに詳細が表示されます。

  6. DevTools を閉じて、録画を最大 3 日間実行したままにできます。録画を停止するには、停止して。 [停止] をクリックします。

投機的読み込み

投機的読み込みを使用すると、定義した投機的ルールに基づいて、ほぼ瞬時のページ読み込みが可能になります。これにより、ウェブサイトで最もアクセスされたページをプリフェッチしてプリレンダリングできます。

プリフェッチはリソースを事前に取得し、プリレンダリングはさらに一歩進んで、非表示のバックグラウンド レンダラ プロセスでページ全体をレンダリングします。

投機的読み込みのデバッグは、[アプリケーション] > [バックグラウンド サービス] > [投機的読み込み] セクションで行うことができます。このセクションには、次の 3 つのビューがあります。

  • 投機的読み込み。現在のページ、現在の URL、現在のページが投機的に読み込もうとしているページ、およびそれらのステータスの投機的ステータスが含まれます。
  • ルール。[Elements] パネルの現在のページにあるルールセットと、投機的実行の全体的なステータスが含まれます。
  • 推測。投機的読み込みの試行とそのステータスに関する情報を含む表が含まれています。試行が失敗した場合は、テーブルでクリックすると、詳細情報と失敗の理由を確認できます。

こちらのプリレンダリングのデモページで投機的読み込みのデバッグをお試しください。

  1. ページで DevTools を開き、[アプリケーション] > [バックグラウンド サービス] > [投機的読み込み] に移動します。ページによって開始された投機的読み込みが表示されない場合は、ページを再読み込みします。

    このページで投機的に読み込まれた URL。成功 2 件、失敗 1 件。

  2. デモの開始ページでは、2 つのページが事前レンダリングされ、1 つのページの事前レンダリングが失敗します。[すべての投機的読み込みを表示] をクリックします。

  3. [推測] で、ステータスが [失敗] の推測を選択すると、下部の詳細情報セクションに [失敗の理由] が表示されます。

    失敗した投機が選択されました。

    この場合、ウェブサイトに /next3.html ページがないため、事前レンダリングに失敗しています。

  4. （省略可）[投機] タブの表をフィルタするには、上部のフィルタバーに値を自由に入力するか、キー付きフィルタ（url:VALUE、action:VALUE、action:VALUE）のいずれかを使用します。

    投機テーブルのフィルタバー。

  5. [ルール] セクションを開き、[ステータス] をクリックすると、下部にルールセットが表示されます。[ルールセット] リンクをクリックすると、[要素] パネルに移動し、投機ルールが定義されている場所が表示されます。

    ルールセットへのリンクを含む [ルール] セクション。

詳細な手順については、投機ルールのデバッグをご覧ください。

プッシュ メッセージング

ユーザーにプッシュ通知を表示するには、まず Service Worker が Push Message API を使用してサーバーからデータを受信する必要があります。Service Worker は、通知を表示する準備ができたら、Notifications API を使用します。DevTools が開いていない場合でも、プッシュ メッセージを 3 日間記録するには:

  1. たとえば、このデモページで DevTools を開きます。

  2. [Application] > [Background services] > [Push Messaging] に移動し、録画。 [Record] をクリックします。

    [プッシュ メッセージング] タブ。

  3. デモページで [プッシュ通知を有効にする] を切り替え、プロンプトが表示されたら [許可] をクリックし、メッセージを入力して送信します。DevTools はプッシュ通知イベントをテーブルに記録します。

    [プッシュ メッセージ] タブのイベントログ。

  4. イベントをクリックすると、表の下のスペースに詳細が表示されます。

  5. DevTools を閉じて、録画を最大 3 日間実行したままにできます。録画を停止するには、停止して。 [停止] をクリックします。

Reporting API

エラーの中には、本番環境でのみ発生するものもあります。実際のユーザー、ネットワーク、デバイスによってゲームが変わるため、ローカルや開発中にそれらを確認することはできません。

たとえば、新しいサイトが document.write() を使用して重要なスクリプトを読み込むサードパーティ製ソフトウェアに依存しているとします。世界中の新規ユーザーがサイトを開きますが、テストで使用した接続よりも遅い可能性があります。お客様が知らないうちに、低速ネットワークで Chrome が document.write() に対して介入するため、サイトが機能しなくなります。また、コードベースで使用されている非推奨の API や、まもなく非推奨になる API を監視することもできます。

Reporting API は、非推奨の API 呼び出しやページのセキュリティ違反などをモニタリングできるように設計されています。レポートの設定については、Reporting API を使用してウェブ アプリケーションをモニタリングするをご覧ください。

ページで生成されたレポートを表示するには:

  1. DevTools を開き、[Application] > [Background services] > [Reporting API] に移動します。

    Reporting API に記載されているレポート

[Reporting API] タブは、次の 3 つの部分に分かれています。

  • 各レポートに関する次の情報を含む [レポート] テーブル:
    • レポートの生成を引き起こした URL
    • 違反の種類
    • レポートのステータス
    • 宛先エンドポイント
    • 生成日時のタイムスタンプ
    • レポートの本文
  • [レポート本文] プレビュー セクション。レポートの本文をプレビューするには、レポートの表でレポートをクリックします。
  • Reporting-Endpoints ヘッダーで構成されているすべてのエンドポイントの概要を示す [エンドポイント] セクション。

レポートのステータス

[ステータス] 列には、Chrome がレポートを正常に送信したか、送信しようとしているか、送信に失敗したかが表示されます。

ステータス 説明
Success ブラウザがレポートを送信し、エンドポイントが成功コード（200 または別の成功レスポンス コード 2xx）で応答しました。
Pending ブラウザがレポートの送信を試みています。
Queued レポートは生成されていますが、ブラウザはまだ送信を試みていません。レポートが Queued と表示されるのは、次の 2 つのケースのいずれかです。
  • レポートが新しく、ブラウザはレポートがさらに届くかどうかを確認してから送信しようとしています。
  • レポートは新しいものではありません。ブラウザはすでにこのレポートの送信を試みて失敗しており、再試行するまで待機しています。
MarkedForRemoval しばらく再試行（Queued）した後、ブラウザはレポートの送信を停止し、まもなく送信するレポートのリストから削除します。

レポートは、送信が成功したかどうかにかかわらず、しばらくすると削除されます。

障害レポートのコンテキスト

Reporting API を使用すると、ウェブサイトが crash-reporting または default サーバー エンドポイントにクラッシュを報告するように構成できます。クラッシュ レポートには、現在の最上位のブラウジング コンテキストの Key-Value ペアで任意のクラッシュ関連データを記録できる CrashReportContext インターフェースを含めることができます。

[アプリケーション] > [バックグラウンド サービス] > [Reporting API] > [クラッシュ レポートのコンテキスト] タブで、クラッシュ コンテキスト データを検査し、上部のフィルタバーでキーまたは値でフィルタできます。

[Crash Report Context]（クラッシュ レポートのコンテキスト）タブ。

デバイスにバインドされたセッション

デバイスにバインドされたセッション認証情報（DBSC）は、ユーザー エージェントが安全に保存された秘密鍵の所有権を主張できるようにすることで、Cookie の盗難を防ぐことを目的とした、ユーザー エージェントとサーバー間の Web API とプロトコルです。

デバイスにバインドされたセッション、その定義、イベントを表示するには:

  1. DBSC を使用するページで DevTools を開きます。
  2. [Application] > [Background services] > [Device bound sessions] に移動します。

  3. 左側のサイドバーでサイトを開き、アクティブなセッションを表示します。セッションを選択して定義を表示します。

    [デバイスにバインドされたセッション] タブ。

  4. Events テーブルには、DBSC イベント（作成、更新、チャレンジ、終了）が記録されます。ページ移動間でイベントのリストを保持するには、[check_box ログを保持] をオンにします。

  5. [イベント] テーブルで、イベントを選択して詳細を表示します。

  6. イベントが失敗すると、[結果] 列に Error メッセージが表示されます。失敗したイベントを選択すると、詳細、レスポンス エラーコード、失敗の原因が表示されます。

    エラー イベントが選択された [デバイス バインド セッション] タブ。

サイドバーの [デバイスにバインドされたセッション] セクションには、次の問題が表示されることがあります。

  • 終了したセッション: サイドバーで取り消し線とデータベース オフ アイコンで示されます。
  • 失敗したイベント: 警告アイコン付きでハイライト表示されます。[セッションなし] 要素は、サイトにはリンクされているものの、既知のセッションにはリンクされていない失敗したイベントをキャプチャします。