Chrome の Heavy Ad Intervention について

Nour Nabil

Rowan Merewood

公開日: 2025 年 9 月 22 日、最終更新日: 2026 年 1 月 7 日

ユーザーにとって、ウェブページの読み込みが突然遅くなったり、バッテリーが消耗したり、毎月のデータ使用量が上限に達したりするほどイライラすることはありません。原因は、ユーザーが見ようとしたコンテンツではなく、バックグラウンドで実行されている広告である場合があります。

ユーザー エクスペリエンスを保護するため、Chrome では広告で使用できるリソースに上限が設けられています。広告がこれらの上限を超えて重い広告になると、Chrome はデバイスのリソースを解放するために広告をアンロードします。

このドキュメントでは、この介入の仕組み、関連する具体的なしきい値、広告をスムーズに配信するためのベスト プラクティスについて説明します。

時間のかかった広告の問題とは

重い広告の介入は、広告フレームのリソース使用量をモニタリングする Chrome のメカニズムです。広告が帯域幅や CPU 処理能力を過剰に消費している場合、Chrome はその広告フレームをアンロードします。

広告の代わりに、通常は「広告を削除しました」というメッセージと、広告がリソースを過剰に使用したことを説明する [詳細] リンクが表示された灰色のボックスが表示されます。

広告が重いと判断されるのはどのような場合ですか？

Chrome は、3 つの特定のしきい値に基づいて広告が重いかどうかを判断します。ユーザーが広告を操作しておらず、次のいずれかの条件を満たしている場合、広告はアンロードされます。

• ネットワーク使用量: 広告が 4 メガバイトを超えるネットワーク帯域幅を使用している。
• CPU 使用率のピーク: 広告が 30 秒間の任意のウィンドウで 15 秒を超えてメインスレッドを使用しています。
• 合計 CPU 使用率: 広告がメインスレッドを合計 60 秒以上使用しています。広告フレームの子孫 iframe で使用されるすべてのリソースは、その広告の介入の制限に対してカウントされます。

この介入の一般的なトリガーは何ですか？

広告の動作の種類によっては、他の種類よりもこうした介入がトリガーされやすくなります。一般的な原因は次のとおりです。

• 非圧縮メディア: 圧縮率の低い非常に大きな画像を読み込む。
• Heavy Javascript: JavaScript を使用して動画ファイルをデコードするなど、大規模なオペレーションを実行している。
• 重い計算: バックグラウンドで複雑な計算を実行しています。
• ジェスチャーのない動画コンテンツ: ユーザーが広告を操作する前に大きな動画ファイルを読み込む。

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

Chrome は、広告が重い広告のしきい値を超えたことを検出すると、ユーザーのデバイスリソースを保護するために直ちに対処します。

ユーザー エクスペリエンス

ユーザーの視点から見ると、広告はすぐにアンロードされます。代わりに、Chrome には [広告を削除しました] というメッセージが表示された灰色のボックスが表示されます。コンテナ内の [詳細] をクリックすると、具体的な説明が表示されます。

デベロッパー エクスペリエンス

また、Chrome は Reporting API を使用して介入レポートを生成し、何が起きたかを正確に把握できるようにします。以前は、これらのレポートは広告フレーム自体とその子孫フレームにのみ送信されていました。しかし、パブリッシャーは、自分のページの広告が削除されていることを知る方法がないことがよくありました。この問題を解決するため、Chrome ではレポート メカニズムを拡張しました。介入レポートは、広告フレーム自体に加えて、埋め込みフレーム（ルート広告フレームの親）にも送信されるようになりました。埋め込みフレームに送信されるレポートには、子フレームの ID と広告フレームの URL が含まれます。

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

Reporting-Endpoints: default="https://example.com/reports"

トリガーされた 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?utm_source=devtools"
 }
}]

埋め込みフレームは、埋め込みフレームの URL 宛ての同様のレポートを受け取りますが、メッセージには子フレームの ID と子フレームの特定の URL も含まれます。

...
"message": "Ad was removed because its CPU usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384?utm_source=devtools (id=123;url=http://example2.com/pre-redirect-ad-url.html)"
...

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

// callback that will handle intervention reports
function sendReports(reports) {
  for (let report of reports) {
    // Log the `report` json using 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 ページ（広告など）がアンロードされるため、pagehide イベントを使用して、ページが消える前にレポート コールバックが介入レポートを確実にキャプチャするようにします。

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

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',
    },
  },
];

デベロッパー向けのベスト プラクティス

広告が重い広告バナーの対象にならないようにするには、次のベスト プラクティスを検討してください。

• 重いコンテンツでユーザー操作を必須にする: 介入条件は、ユーザーが操作していない広告に適用されます。ユーザーが広告をクリックまたはタップすると、リソースの上限は適用されなくなります。動画やリッチメディア エクスペリエンスでは、重いアセットを読み込む前にユーザーの操作（「クリックして再生」など）を待ちます。
• 画像と動画を最適化する: 画像が圧縮され、動画がウェブ用に最適化されていることを確認します。サイズの大きな動画ファイルを自動的に読み込むのは避け、ユーザーが操作するまで軽量のプレースホルダを使用します。
• CPU 使用率を監査する: 複雑なアニメーションや、レイアウトとペイントを継続的にトリガーする JavaScript オペレーションは、CPU 使用率を急上昇させる可能性があります。ツールを使用して、メインスレッドを長時間ビジー状態にする可能性があるコード内のボトルネックを特定します。
• 子孫フレームをモニタリングする: リソース数には、広告の iframe 内のすべてのものが含まれることに注意してください。広告で第三者のトラッキング ピクセルやサブフレームが読み込まれる場合、それらのリソース使用量は上限にカウントされます。
• 広告以外のコンテンツを分離する: 広告以外のコンテンツ フレームを、フィルタ リスト プロバイダのポリシーで広告ドメインと見なされる可能性が低い、別のドメインまたは認識可能なパターンに分離します。

介入の原因をデバッグして診断する方法

重い広告の介入を効果的にトラブルシューティングして解決するには、まず Chrome の検出ロジックがコンテンツを広告として識別する方法を理解し、次に組み込みのデベロッパー ツールを使用して、削除につながった特定のリソース トリガーを監査する必要があります。

Chrome はどのようにして広告の存在を検出するのですか？

Chrome は、リソース リクエストをフィルタリストと照合してコンテンツを広告としてタグ付けします。検出ロジックは iframe 内のコンテンツに適用されます。メインページ フレームは、広告スクリプトが含まれていても、広告関連とみなされることはありません。フィルタリストと一致するリソースから読み込まれた iframe は、そのフレームから広告以外のコンテンツも読み込まれた場合でも、広告と見なされます。たとえば、広告としてタグ付けされた iframe に読み込まれた動画プレーヤーが、広告以外のコンテンツも読み込むことがあります。

広告の検出を確認する方法

デベロッパーは、Chrome DevTools を使用して、Chrome がコンテンツを広告として正しく検出しているかどうかを視覚的に確認できます。

• 広告フレームのハイライト表示: [レンダリング] パネルで [広告フレームをハイライト表示] を選択します。これにより、検出された広告フレームが画面上で赤色で色分けされます。
• 要素のメモ: [要素] パネルで、検出された広告 iframe の開始 <iframe> タグの横に広告のメモが表示されます。
• ネットワーク アクティビティ: [ネットワーク] パネルで、Is ad-related ブール値に基づいてリクエストをフィルタします。
• 広告ステータス: アプリケーション パネルの [フレーム] セクションで、広告タグ付きフレームには Ad Status 属性が含まれます。

介入の原因を診断する方法

Chrome には、ウェブページの品質とパフォーマンスを監査して改善するためのツールが用意されています。Chrome DevTools で Lighthouse を実行して、ページのパフォーマンスに関するレポートを取得します。web.dev/fast コレクションも参照して、ウェブに関する主な指標の詳細をご確認ください。

ネットワーク使用量

Chrome DevTools の [Network] パネルを開いて、広告のネットワーク アクティビティ全体を確認します。[Disable cache] オプションをオンにすると、繰り返し読み込んでも一貫した結果が得られます。

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

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

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

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

CPU 使用率

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

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

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

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

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

不適切な介入を報告するにはどうすればよいですか？

広告以外のコンテンツにタグが付けられている場合は、フィルタリング ルールに一致しないようにコードを変更するか、EasyList の管理者に直接連絡してフィルタリング ルールを変更することを検討してください。重い広告の介入はユーザー操作のあるフレームには影響しないため、コンテンツを読み込む前に再生ボタンをクリックする必要がある動画は除外できます。EasyList がコンテンツと一致せず、Chrome がコンテンツを広告関連として誤って分類した場合は、このテンプレートを使用して Chrome に問題を報告できます。問題を報告する際は、介入レポートのキャプチャ例と、問題を再現するためのサンプル URL を含めてください。