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

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

Marco Prontera

Gilberto Cocchi

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

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

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

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

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

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

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

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

INP の測定方法

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

すべての Cookie を許可するボタンと同様に、すべての Cookie を拒否するボタンと Cookie 設定をカスタマイズするボタンはすべて、PubConsent CMP アーキテクチャと同じワークフローに従います。このため、このケーススタディで詳しく説明した改善が、CMP サービスでの一連のユーザー操作に影響を与えました。

この遅延により、タスク中はパネルがロックされた状態で視覚的に認識されるようになりました。レンダリングの更新が長時間ブロックされていたため、ページの INP に悪影響が及びました。

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

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

優先度の高いタスクを実行できます

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

ここでは setTimeout の使用を回避しました。yieldToMainUiBlocking メソッドは、CMP 内部設定操作と優先度の高い作業を処理するように設計されているためです。これらの処理は、放棄している間もその優先度を維持する必要があります。つまり、これらのスケジュール設定 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);
  });
};

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

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

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

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

CMP の応答性の問題のほとんどを解決できた結果、主な依存関係の一つである IAB の透明性と同意に関するフレームワーク（TCF）ライブラリにさらなる改善の余地があることが判明しました。

このライブラリで最も計算コストの高いコンポーネントは「ビルド文字列」と「同意のディスパッチ」でした。これらのコンポーネントは IAB TCF ライブラリに不可欠な要素です。これらのコンポーネントに対して、以下の最適化が PubTech のニーズに合わせて別のフォークで適用されました。

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

最初の最適化では、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 のお客様は、Google の最適化の取り組みがもたらした INP のパフォーマンスとビジネス指標の改善にすぐに気づきました。お客様の貴重な Real User Monitoring（RUM）データを活用して、PubConsent CMP のさらなるパフォーマンス向上を検討しています。このデータは回帰と進歩の両方を綿密に追跡し、PubTech の継続的な改善の取り組みを推進しています。

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

このイノベーションの取り組みを支援してくれた PubTech CTO の Luca Coppola、Google の Jeremy Wagner、Michal Mocny、Rick Viscomi に感謝します。