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

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

同意管理プラットフォーム（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 スクリプトを軽量化することで、ウェブサイトの所有者は、ユーザー エクスペリエンスの品質を維持しながら、有用な同意管理機能を組み込む際のバランスを微調整できます。

<ph type="x-smartling-placeholder">

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

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

INP の測定方法

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

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

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

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

<ph type="x-smartling-placeholder">

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);
  });
};

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

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

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

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

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

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

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

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

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

で確認できます。 <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 ミリ秒に）短縮されました。

<ph type="x-smartling-placeholder">

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

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

まとめ

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

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

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