Google I/O にご参加いただきありがとうございました。オンデマンドでコンテンツを視聴できます。

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

PubTech の同意管理プラットフォームが、顧客ウェブサイトの INP を最大 64% 削減し、広告の視認性を最大 1.5% 改善した方法

PubConsent CMP がブラウザの Scheduler API を使用して Chrome DevTools で特定された応答性の問題を修正する収益戦略により、顧客の INP を最大 64% 削減した方法。

Marco Prontera

Gilberto Cocchi

同意管理プラットフォーム（CMP）は、Cookie やトラッキング技術の使用についてユーザーの同意を得て、ウェブサイトがプライバシーに関する規則を遵守できるようにするためのツールです。CMP は、法令遵守を徹底するという主な目的に加え、サードパーティスクリプトとして、パフォーマンスとユーザーエクスペリエンスへの影響を最小限に抑える必要もあります。

PubConsent CMP は PubTech の最新プロダクトです。パフォーマンスに重点を置いて設計された PubConsent CMP は軽量設計で、最適なユーザーエクスペリエンスを提供し、ウェブサイトの全体的なパフォーマンスへの影響を最小限に抑えます。

Interaction to Next Paint（INP）指標の導入により、PubTech は CMP の応答性の問題を発見することができました。このケーススタディでは、PubTech が PubConsent CMP プラットフォームの応答性に関する問題を解決した方法と、2024 年 3 月に Core Web Vitals の一つになる前に INP をどのように改善したかを示し、CMP プロダクトで可能な限り最高のパフォーマンスを提供するという揺るぎない取り組みを示しました。

PubTech がパフォーマンスを重視する理由

PubConsent CMP は、ほとんどの CMP と同様に、同意管理機能をサイトのページにサードパーティのスクリプトとして実装します。CMP サービスのパフォーマンスへの影響（応答性など）を軽減することは、CMP 統合の成功を保証するために不可欠です。

パフォーマンスを優先し、PubConsent CMP スクリプトを軽量化することで、ウェブサイトの所有者は、ユーザーエクスペリエンスの品質を維持しながら、有用な同意管理機能を組み込む際のバランスを微調整できます。

CMP が提供する機能の重要性と、CMP がパフォーマンスに与える影響を考慮して、PubTech は次のような目標を設定しました。

PubConsent CMP プロダクトが INP に及ぼす影響を最小限に抑える。
CMP プロダクトに起因する時間のかかるタスクを削減する。
ページの INP に悪影響を及ぼす可能性がある合計ブロック時間（TBT）を短縮します。

INP の測定方法

PubTech は、Chrome DevTools を使用して初期分析を行い、遅いインタラクションを手動で診断しました。このワークフローにより、PubTech はページの応答性に影響を与える特定の問題を特定できました。たとえば、CMP サービス内でクリック操作を行い、すべての Cookie を受け入れて Cookie 使用の同意ダイアログを閉じると、長いタスクが発生してユーザーインターフェースのレンダリング更新が遅れました。次の画像からわかるように、長いタスクが完了するまでユーザーインターフェースが更新されず、ダイアログが閉じられたことが示されていませんでした。

すべての Cookie を受け入れるボタンと同様に、すべての Cookie を拒否するボタンや Cookie の設定をカスタマイズするボタンも、すべて PubConsent CMP アーキテクチャの同じワークフローに従います。そのため、この事例で詳述した改善は、CMP サービスでのユーザー操作に影響を与えました。

ユーザーが [すべてに同意] をクリックした後、タスクによってユーザーインターフェースの更新がどの程度ブロックされるかを示すフロー] ボタンが表示されます。1 つの長いタスクには 5 つのステップがあるため、ユーザーインターフェースが遅く感じられます。 — </ph> ユーザーが [すべて承認] をクリックした場合の動作を示す図] ボタンを離します。

この遅延により、作業中にパネルがロックされたと視覚的に認識されるようになりました。目に見えるほど長い時間レンダリング更新をブロックしたため、ページの INP に悪影響が及びました。

PubTech がボタンとリンクの INP を最適化した方法

INP を改善するために、PubConsent CMP でさまざまな収益戦略が採用されました。

優先度の高いタスクの実現

次のコードスニペットに示す yieldToMainUiBlocking メソッドは、優先順位の高い JavaScript タスクを最適化するように設計されています。そのために、可能な場合は scheduler.yield を生成します。postTask を使用できる場合は優先度が user-blocking（高い）の postTask にフォールバックし、最終的に何も返しません。

ここで setTimeout が回避されたのは、yieldToMainUiBlocking メソッドが内部の CMP 設定処理と、そのような優先度を維持したまま高い優先度で処理するように設計されているためです。つまり、これらの Scheduling API を実装しているブラウザ（現時点では Chromium ベースのブラウザでのみ利用可能）のみが、このケーススタディで詳述されている改善点の恩恵を受けられることを意味します。それでもなお、このアプローチは、このような優先度の高いタスクの段階的な改善は許容範囲内と考えられていました。

function yieldToMainUiBlocking () {
  return new Promise((resolve) => {
    if ('scheduler' in window) {
      if ('yield' in window.scheduler) {
        return window.scheduler.yield().then(() => resolve(true));
      }

      if ('postTask' in window.scheduler) {
        return window.scheduler.postTask(() => resolve(true), { priority: 'user-blocking' });
      }
    }

    resolve(false);
  });
};

中程度のタスクとバックグラウンドタスクの収益

次のコードスニペットに示す yieldToMainBackground メソッドは、優先度が user-visible（中）または background の時間のかかるタスクを分割するために使用されます。ロジックは scheduler.yield() を実装します（使用可能な場合）。ただし、優先度が中程度の postTask を使用し、最終的に Chromium 以外のブラウザでは setTimeout にフォールバックする点が異なります。

function yieldToMainBackground () {
  return new Promise((resolve) => {
    if ('scheduler' in window) {
      if ('yield' in window.scheduler) {
        return window.scheduler.yield().then(() => resolve(true));
      }

      if ('postTask' in window.scheduler) {
        return window.scheduler.postTask(() => resolve(true), { priority: 'user-visible' });
      }
    }

    setTimeout(() => { resolve(true) }, 0);
  });
};

ユーザーが [すべて承諾] をクリックした後に、タスクがユーザーインターフェースの更新をブロックした時間を示すフローボタンが最適化されました。5 つのステップにより可能な限りそれが実現し、ユーザーインターフェースがレンダリングをより早く更新できるようになりました。 — </ph> `yieldToMainBackground` を使用して yield することで、ブラウザが次のペイント（この場合は CMP UI を閉じる）を迅速にレンダリングする方法を視覚的に表現した図。

PubTech がレンダリングレイアウトの最適化で TBT をさらに短縮した方法

収益戦略を適用した結果、CMP の方が INP が大幅に向上していることがわかりました。実際、イベントハンドラの処理時間を大幅に短縮した後、Close UI アクションの次のペイントでレンダリングをさらに改善する機会が発見されました。この操作は元々、DOM から要素を削除することを意図したものでした。これにより、特に DOM ノードが多数存在するウェブサイトでは課題が生じ、レンダリング処理が予期せず増加しました。

Chrome DevTools の [パフォーマンス] パネルのスクリーンショット。PubConsent CMP の UI ダイアログを閉じるためのアクティビティのコールスタックを含むトレースのセクションが表示されています。UI ダイアログ自体を閉じるタスクによって DOM ノードの削除がトリガーされ、これによってインタラクションの表示遅延が増大します。

DOM から要素を削除するために必要なレンダリング作業の増加に対処するために、「遅延解除」と呼ばれるソリューションが導入されました。この方法では、まずユーザーが CMP の同意ダイアログを非表示にすることに同意した後、display: none CSS ルールを CMP の同意ダイアログに適用します。その後、requestIdleCallback を使用して、CMP ダイアログに関連付けられた DOM ノードの削除を、ブラウザがアイドル状態になった後の時点に移行します。このアプローチは、ユーザーが同意ダイアログを閉じた瞬間に DOM ノードを削除するよりもはるかに高速であることが証明されました。

Chrome DevTools の [パフォーマンス] パネルのスクリーンショット。以前と同じだが最適化されたトレースが表示されています。PubConsent CMP のダイアログを閉じると、最初のアクションとして「CSS display: none」ルールを使用してダイアログが非表示になります。その後、ブラウザがアイドル状態になると、DOM ノードが削除されます。 — </ph> DOM 削除タスクをシフトしたことによる INP の改善を示した DevTools のスクリーンショット。

PubTech が IAB TCF ライブラリを改善して INP をさらに削減した方法

CMP の応答性に関するほとんどの問題を解決した後、主要な依存関係の一つである IAB の透明性と同意に関するフレームワーク（TCF）ライブラリに、さらなる改善の機会が特定されました。

このライブラリで最も計算コストの高いコンポーネントは「ビルド文字列」「ディスパッチの同意」などがあります。これらのコンポーネントは、IAB TCF ライブラリに不可欠な部分です。これらのコンポーネントに対して、特に PubTech のニーズに応えるため、別のフォークで以下の最適化を適用しました。

デコード処理で計算結果を再利用する。この処理は、ユーザーの同意を取得する必要があるサードパーティのコールバックごとに実行されます。
パブリッシャー制限のエンコードプロセス（ユーザーが同意したときに実行される）における不要なループを回避し、削減しました。

で確認できます。 <ph type="x-smartling-placeholder">

1 つ目の最適化では、IAB TCF ライブラリに接続する各サードパーティコールバックに CMP が費やす時間を短縮しました。2 つ目の最適化では、「ビルド文字列」による処理時間が短縮されました。説明します。実際、この最適化により、ユーザーが同意を示すたびに実行されるループを最大 60% 削減できました。

結果

これまで生成されていた戦略と新しいレンダリングレイアウト最適化を導入したことで、CMP の INP が最大 65%向上しました。その結果、PubConsent CMP のユーザーエクスペリエンスの応答性は大幅に向上し、一部の広告では、広告がリクエストされるタイミングを最適化することで視認性が 1.5% 向上しました。

これらの改善に加え、IAB の TCF ライブラリでは、TCF に起因する時間のかかるタスクを最大 85% 削減した結果、影響を受けた顧客のモバイルでの INP が最大 77% 向上したことが確認されています。これにより、ページのライフサイクル全体で実行されるサードパーティのコールバックのオーバーヘッドを大幅に削減することができました。

PubConsent CMP を使用した場合に INP に合格したオリジンの数は 400% 以上改善し、モバイルでは 13% から 55% に増加しました。一部のお客様では、PubTech SDK を最適化したことで、ページ INP が半分以上（470 ミリ秒から 230 ミリ秒に）短縮されました。

PubTech CMP を使用しているサイトの、オリジンの INP 合格率のスクリーンショット。パソコンでは合格率が約 84% から 99.12% に向上しています。モバイルでは、合格率が約 22% から 55.46% に向上します。 — </ph> HTTP Archive と Chrome ユーザーエクスペリエンスレポート（CrUX）で報告される、PubTech CMP を使用するサイトのオリジン INP 合格率。

75 パーセンタイルの RUM データからの INP を示すダッシュボードのスクリーンショット。2023 年 7 月/8 月から、INP は 500 ミリ秒を少し下回っていますが、2024 年 2 月中旬までに、INP は 200 ミリ秒を少し下回って、「良好」になります。あります。 — </ph> PubConsent の顧客のモバイル INP データの改善傾向。この事例紹介で説明されている SDK の変更と関連。

まとめ

PubTech の顧客は、当社の最適化の取り組みの結果、INP のパフォーマンスとビジネス指標が好ましい成果を生みだしていることをすぐに認識しており、お客様からの貴重なリアルタイムユーザーモニタリング（RUM）データを活用して、PubConsent CMP のさらなるパフォーマンス改善を検討しています。このデータは回帰と進歩の両方を厳密に追跡し、PubTech の継続的な改善の取り組みの原動力となっています。

また、PubTech はサードパーティとして、ビジネスの KPI への悪影響を回避しながら、ウェブパフォーマンスを大規模に改善し、応答性を向上させる機会があることも認識しました。こうした改善策の導入は、すぐにでも始められます。

このイノベーションの取り組みをサポートした PubTech CTO の Luca Coppola と、Google の Jeremy Wagner、Michal Mocny、Rick Viscomi に心より感謝します。