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 の 1 つになる前に INP を改善した方法を紹介しています。これは、CMP プロダクトで可能な限り最高のパフォーマンスを提供するという揺るぎない取り組みを示しています。

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

PubConsent CMP は、ほとんどの CMP と同様に、サイトページにサードパーティ スクリプトとして実装された同意管理機能を提供します。CMP 統合を成功させるには、Google の CMP サービスによるパフォーマンスへの影響を軽減することが重要です（応答性への影響も含みます）。

パフォーマンスを優先し、PubConsent 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 サービスでのユーザー操作に影響を与えました。

この遅延により、タスク中にパネルがロックされた状態に見えていました。レンダリングの更新が明らかに長時間ブロックされたため、ページの INP に悪影響が出ました。

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

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

優先度の高いタスクを譲渡する

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

ここでは 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() が使用可能な場合は 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 ルールを適用します。次に、requestIdleCallback を使用して、CMP ダイアログに関連付けられた DOM ノードの削除を、ブラウザがアイドル状態になっている後で行うようにします。このアプローチは、ユーザーが同意ダイアログを閉じた瞬間に DOM ノードを削除するよりもはるかに高速であることが実証されています。

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

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

このライブラリで最も計算コストの高いコンポーネントは、「build strings」と「dispatch consent」でした。これらのコンポーネントは 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 のパフォーマンスとビジネス指標が改善されたことをすぐに認識しました。PubConsent CMP のパフォーマンスをさらに改善するため、お客様から提供された貴重なリアルユーザー モニタリング（RUM）データを活用することが検討されています。このデータは、リグレッションと進歩の両方を詳細に追跡し、PubTech の継続的な改善活動を推進します。

サードパーティとして、PubTech はビジネスの KPI に悪影響を及ぼすことなく、ウェブのパフォーマンスを大規模に改善し、応答性を高める機会があることに気づきました。このような改善は、いつでも始められます。

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