時間のかかる広告介入への対応

Rowan Merewood

デバイスのリソースを過剰に消費する広告は、パフォーマンスの低下という明らかな影響から、バッテリーの消耗や帯域幅の割り当ての消費といった目に見えにくい影響まで、ユーザー エクスペリエンスに悪影響を及ぼします。これらの広告には、暗号通貨マイナーなどの悪意のあるものから、意図しないバグやパフォーマンスの問題を含む正規のコンテンツまで、さまざまなものがあります。

Chrome は、広告で使用できるリソースに上限を設定し、上限を超えた場合は広告をアンロードします。詳しくは、Chromium ブログの発表をご覧ください。広告のアンロードに使用されるメカニズムは、時間のかかった広告の問題の処理です。

リソース消費の多い広告の条件

広告が重いと見なされるのは、ユーザーが広告を操作していない（タップやクリックなどを行っていない）場合に、次のいずれかの条件を満たしているときです。

  • 合計 60 秒以上メインスレッドを使用している
  • 30 秒間のうち 15 秒以上メインスレッドを使用している
  • 4 メガバイトを超えるネットワーク帯域幅を使用する

広告フレームの子孫 iframe で使用されるすべてのリソースは、その広告への介入の制限に対してカウントされます。メインスレッドの時間制限は、広告の読み込みからの経過時間と同じではないことに注意してください。制限は、広告のコードの実行に CPU がかかる時間に対して適用されます。

介入のテスト

この介入は Chrome 85 でリリースされましたが、ユーザーのプライバシーを保護するため、デフォルトではしきい値にノイズと変動が追加されています。

chrome://flags/#heavy-ad-privacy-mitigations を Disabled に設定すると、これらの保護が削除されます。つまり、制限は上限にのみ従って決定論的に適用されます。これにより、デバッグとテストが容易になります。

介入がトリガーされると、重い広告の iframe のコンテンツが「Ad removed」というメッセージに置き換えられます。[詳細] リンクをクリックすると、「この広告は、デバイスのリソース消費が多すぎるため、Chrome によって削除されました。」というメッセージが表示されます。

サンプル コンテンツに適用された介入については、heavy-ads.glitch.me で確認できます。また、このテストサイトを使用して任意の URL を読み込むことで、独自のコンテンツを簡単にテストすることもできます。

テストの際は、介入が適用されない理由がいくつかあることに注意してください。

  • 同じページ内で同じ広告を再読み込みすると、その組み合わせは介入の対象外になります。この場合は、閲覧履歴を削除して、新しいタグでページを開くと解決することがあります。
  • ページがフォーカスされた状態を維持します。ページをバックグラウンドに移動（別のウィンドウに切り替え）すると、そのページのタスクキューが一時停止し、CPU 介入がトリガーされません。
  • テスト中に広告コンテンツをタップまたはクリックしないようにしてください。ユーザー操作があったコンテンツには介入が適用されません。

必要なご対応について

サイトに第三者プロバイダの広告を表示している

対応は不要です。ただし、ユーザーがサイトにアクセスしたときに、上限を超えた広告が削除される可能性があることにご注意ください。

サイトにファーストパーティ広告を表示している、またはサードパーティのディスプレイ広告を提供している

Heavy Ad 介入の Reporting API を介して必要なモニタリングを実装するには、続きをお読みください。

広告コンテンツを作成している、または広告コンテンツを作成するためのツールを管理している

パフォーマンスとリソース使用量に関する問題についてコンテンツをテストする方法を理解するには、引き続きお読みください。また、選択した広告プラットフォームのガイダンスも参照してください。たとえば、Google のディスプレイ クリエイティブのガイドラインなど、技術的なアドバイスや制限が追加で提供されている場合があります。パフォーマンスの低い広告が野放しになるのを防ぐため、構成可能なしきい値をオーサリング ツールに直接組み込むことを検討してください。

広告が削除されるとどうなりますか？

Chrome での介入は、intervention レポート タイプで、Reporting API を介して報告されます。Reporting API を使用すると、レポート エンドポイントへの POST リクエストまたは JavaScript 内で、介入に関する通知を受け取ることができます。

これらのレポートは、ルートの広告タグ付き iframe とそのすべての子孫（介入によってアンロードされたすべてのフレーム）でトリガーされます。つまり、広告が第三者のソース（クロスサイト iframe）から配信された場合、レポートの処理は第三者（広告プロバイダなど）が行います。

HTTP レポート用にページを構成するには、レスポンスに Report-To ヘッダーを含める必要があります。

Report-To: { "url": "https://example.com/reports", "max_age": 86400 }

トリガーされた POST リクエストには、次のようなレポートが含まれます。

POST /reports HTTP/1.1
Host: example.com
…
Content-Type: application/report

[{
 "type": "intervention",
 "age": 60,
 "url": "https://example.com/url/of/ad.html",
 "body": {
   "sourceFile": null,
   "lineNumber": null,
   "columnNumber": null,
   "id": "HeavyAdIntervention",
   "message": "Ad was removed because its CPU usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384"
 }
}]

JavaScript API は、介入時に提供されたコールバックをトリガーするために使用できる observe() メソッドを ReportingObserver に提供します。これは、デバッグに役立つ追加情報をレポートに添付する場合に便利です。

// callback that will handle intervention reports
function sendReports(reports) {
  for (let report of reports) {
    // Log the `report` json via your own reporting process
    navigator.sendBeacon('https://report.example/your-endpoint', report);
  }
}

// create the observer with the callback
const observer = new ReportingObserver(
  (reports, observer) => {
    sendReports(reports);
  },
  { buffered: true }
);

// start watching for interventions
observer.observe();

ただし、介入によってページが iframe から完全に削除されるため、ページが完全に消える前にレポートが確実にキャプチャされるようにフェイルセーフを追加する必要があります（iframe 内の広告など）。そのためには、同じコールバックを pagehide イベントにフックします。

window.addEventListener('pagehide', (event) => {
  // pull all pending reports from the queue
  let reports = observer.takeRecords();
  sendReports(reports);
});

ユーザー エクスペリエンスを保護するため、pagehide イベントでは、その中で実行できる作業量が制限されます。たとえば、レポートで fetch() リクエストを送信しようとすると、そのリクエストはキャンセルされます。navigator.sendBeacon() を使用してレポートを送信する必要があります。それでも、これはブラウザによるベスト エフォートであり、保証されるものではありません。

JavaScript から返される JSON は、POST リクエストで送信される JSON と同様です。

[
  {
    type: 'intervention',
    url: 'https://example.com/url/of/ad.html',
    body: {
      sourceFile: null,
      lineNumber: null,
      columnNumber: null,
      id: 'HeavyAdIntervention',
      message:
        'Ad was removed because its network usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384',
    },
  },
];

介入の原因を診断する

広告コンテンツはウェブ コンテンツにすぎないため、Lighthouse などのツールを使用して、コンテンツの全体的なパフォーマンスを監査します。監査結果には、改善に関するインライン ガイダンスが表示されます。web.dev/fast コレクションもご覧ください。

より分離されたコンテキストで広告をテストすると、効果的な場合があります。https://heavy-ads.glitch.me のカスタム URL オプションを使用すると、広告タグ付きの既製の iframe でこれをテストできます。Chrome DevTools を使用して、コンテンツが広告としてタグ付けされていることを確認できます。[レンダリング] パネル（その他アイコン ⋮ > [その他のツール] > [レンダリング] の順に選択してアクセス）で、[広告フレームをハイライト表示] を選択します。最上位ウィンドウや、広告としてタグ付けされていない他のコンテキストでコンテンツをテストする場合、介入はトリガーされませんが、手動でしきい値を確認することはできます。

フレームの広告ステータスは、[要素] ペインにも表示されます。このペインでは、<iframe> 開始タグの後に ad アノテーションが追加されます。これは、[フレーム] セクションの [アプリケーション] パネルにも表示されます。広告タグ付きのフレームには [広告のステータス] 属性が含まれます。

ネットワーク使用量

Chrome DevTools の [ネットワーク] パネルを開いて、広告のネットワーク アクティビティ全体を確認します。繰り返し読み込んでも一貫した結果を得るには、[キャッシュを無効にする] オプションがオンになっていることを確認してください。

DevTools の [Network] パネル。
DevTools の [Network] パネル。

ページ下部の [転送された値] には、ページ全体の転送額が表示されます。上部の [フィルタ] 入力を使用して、リクエストを広告に関連するものだけに制限することを検討してください。

広告の初回リクエスト（iframe のソースなど）を見つけた場合は、リクエスト内の [イニシエータ] タブを使用して、そのリクエストによってトリガーされたすべてのリクエストを確認することもできます。

リクエストの [Initiator] タブ。
リクエストの [イニシエータ] タブ。

リクエストの全体リストをサイズで並べ替えると、大きすぎるリソースを特定できます。最適化されていない画像や動画が原因であることがよくあります。

レスポンス サイズでリクエストを並べ替えます。
レスポンス サイズでリクエストを並べ替えます。

また、名前で並べ替えると、リクエストの重複を簡単に確認できます。介入のトリガーとなるのは、単一の大きなリソースではなく、上限を徐々に超える多数の繰り返しリクエストである可能性があります。

CPU 使用率

DevTools の [パフォーマンス] パネルは、CPU 使用率の問題の診断に役立ちます。まず、キャプチャ設定メニューを開きます。[CPU] プルダウンを使用して、CPU を可能な限り遅くします。CPU の介入は、ハイエンドの開発マシンよりも低電力のデバイスで発生する可能性がはるかに高くなります。

[パフォーマンス] パネルでネットワークと CPU の調整を有効にします。
[パフォーマンス] パネルでネットワークと CPU のスロットリングを有効にします。

次に、[記録] ボタンをクリックしてアクティビティの記録を開始します。長いトレースは読み込みに時間がかかるため、録画のタイミングと時間を試してみることをおすすめします。録画が読み込まれたら、上部のタイムラインを使用して録画の一部を選択できます。グラフの黄色、紫、緑の実線で示された、スクリプト、レンダリング、ペイントを表す領域に注目します。

[パフォーマンス] パネルのトレースの概要。
パフォーマンス パネルのトレースの概要。

下部の [Bottom-Up]、[Call Tree]、[Event Log] の各タブを確認します。これらの列を [Self Time] と [Total Time] で並べ替えると、コード内のボトルネックを特定できます。

[ボトムアップ] タブで [Self Time] で並べ替えます。
[ボトムアップ] タブで [Self Time] で並べ替えます。

関連付けられたソースファイルもリンクされているため、[ソース] パネルで各行の費用を確認できます。

[ソース] パネルに表示された実行時間。
[ソース] パネルに表示される実行時間。

ここで確認する一般的な問題は、最適化されていないアニメーションによってレイアウトとペイントが継続的にトリガーされていることや、含まれているライブラリ内に隠されているコストのかかるオペレーションなどです。

不適切な介入を報告する方法

Chrome は、リソース リクエストをフィルタ リストと照合してコンテンツを広告としてタグ付けします。広告以外のコンテンツにタグが付けられている場合は、フィルタリング ルールに一致しないようにコードを変更することを検討してください。介入が誤って適用されたと思われる場合は、こちらのテンプレートから問題を報告してください。介入レポートの例をキャプチャし、問題を再現するためのサンプル URL を用意してください。