コンテンツ レコメンデーション プロバイダである Taboola は、LoAF を使用して、パブリッシャー パートナー ウェブサイトの INP を最大 36% 改善しました。

Taboola は、Long Animation Frames API(LoAF)とスマートな収益戦略を導入することで、広告のパフォーマンスを損なうことなく、どのようにパブリッシャーのウェブサイトの応答性を向上させることに成功しました。

David Belford
David Belford

Interaction to Next Paint(INP)は、ユーザー入力に対するウェブサイトの応答性を評価する指標です。INP は、ユーザーが操作(クリック、タップ、入力など)を開始してから、その結果として表示される視覚的なフィードバックまでの時間を測定します。INP は、2024 年 3 月にウェブに関する主な指標として First Input Delay(FID)の代替となる予定です。

Taboola は、世界有数のコンテンツ発見プラットフォームで、オープンウェブで毎秒 50 万件のおすすめ情報を提供しています。これらの最適化案により、Taboola の 9,000 の独占的なパブリッシャー パートナーは、オーディエンスの収益化とエンゲージメントの促進に役立っています。パブリッシャー様は JavaScript を使用してページにおすすめを表示します。

サードパーティの JavaScript は、ページのユーザー入力にすばやく反応する能力に影響を与える可能性があるため、Taboola は JavaScript ファイルのサイズと実行時間を短縮することに注力してきました。Taboola はレンダリング エンジン全体を再設計するとともに、ブラウザ API を抽象化なしで直接使用することで、INP への影響を最小限に抑えてきました。

このケーススタディでは、新しい Long Animation Frames(LoAF)API を使用してフィールドの応答性に及ぼす影響を測定することで、Taboola が INP を改善する取り組みと、ユーザー エクスペリエンスを向上させるために特定の最適化を適用する取り組みについて説明します。

INP の代用としての TBT

Total Blocking Time(TBT)はラボベースの指標で、ページの応答性に影響する可能性の高い、メインスレッドがどこでブロックされていたかを特定します。応答性を測定するフィールド指標(INP など)は、高い TBT の影響を受ける可能性があります。Annie Sullivanモバイル デバイスにおける TBT と INP の相関関係について調査したところ、メインスレッドのブロック時間が最小限である場合に、サイトが良好な INP スコアを達成する可能性が高いことが示されました。

この相関関係と、TBT が高いことに関する Taboola のニュース メディアの懸念とあいまって、Taboola はこの指標への貢献度を最小限に抑えることに注力することにしました。

ブロックされたメインスレッドの時間に対する Lighthouse の監査のスクリーンショット。メインスレッドは、いくつかのスクリプトによって合計で 2,630 ミリ秒ブロックされ、サードパーティの JavaScript がこの間に 712 ミリ秒かかっていました。第三者のブロック時間の大半は Taboola の RELEASE.js スクリプトによるもので、691 ミリ秒です。
Taboola の古いエンジンでは、RELEASE.js などのスクリプトはメインスレッドを 691 ミリ秒ブロックします。

Taboola は INP の代替指標として TBT を使用し、JavaScript の実行時間のモニタリングと最適化を開始し、Core Web Vitals への潜在的な影響を制限することにしました。まず、次のことを行いました。

  • Long Tasks API を使用して、現場で問題のあるスクリプトを特定し、最適化する。
  • PageSpeed Insights API を使用して 1 日あたり 10,000 ~ 15,000 件の URL を評価し、TBT の影響を推定します。

しかし、Taboola はこれらのツールを使用した TBT の分析にはいくつかの制限があることに気づきました。

  • Long Tasks API は、タスクをオリジン ドメインや特定のスクリプトに帰属させることができないため、長時間タスクのソースを特定することが難しくなります。
  • Long Tasks API は、レンダリングの遅延を引き起こす可能性があるタスクとレイアウト変更の組み合わせではなく、時間のかかるタスクのみを識別します。

このような課題に対処するため、Taboola はユーザー入力の応答性に対する実際の影響をより深く理解するため、Long Animation Frames(LoAF)API のオリジン トライアルに参加しました。オリジン トライアルでは、新機能や試験運用版の機能にアクセスして、ユーザーが期間限定で試すことができる新機能をテストできます。

この課題の最も難しい側面は、広告の KPI(重要業績評価指標)を損なったり、パブリッシャー様のリソースの遅延を引き起こしたりすることなく、INP を効果的に改善することであったことを強調する必要があります。

LoAF を使用して INP の影響を評価する

長いアニメーション フレームは、レンダリングの更新が 50 ミリ秒を超えて遅延した場合に発生します。Taboola は、タスクだけではなく、ユーザー インターフェースの更新が遅い原因を特定することで、ページの応答性に及ぼす影響を現場で分析することができました。LoAF を観察することで、Taboola は次のことができるようになりました。

  1. 特定の Taboola タスクにエントリを関連付けます。
  2. 特定の機能を本番環境にデプロイする前に、その機能のパフォーマンスの問題を観察します。
  3. A/B テストで集計データを収集して異なるコード バージョンを比較し、主な成功指標に関するレポートを作成します。

次の JavaScript は、LoAF を収集して Taboola の影響を切り分けるために本番環境で使用される簡略バージョンです。

function loafEntryAnalysis (entry) {
  if (entry.blockingDuration === 0) {
    return;
  }

  let taboolaIsMajor = false;
  const hasInteraction = entry.firstUIEventTimestamp > 0;
  let taboolaDuration = 0;
  const nonTaboolaLoafReport = {};
  const taboolaLoafReport = {};

  entry.scripts.forEach((script) => {
    const taboolaScriptBlockingDuration = handleLongAnimationFrameScript(script, taboolaLoafReport, nonTaboolaLoafReport);
    taboolaDuration += taboolaScriptBlockingDuration;

    if (taboolaScriptBlockingDuration > 0 || taboolaDuration > entry.duration / 2) {
      taboolaIsMajor = true;
    }
  });

  generateToboolaLoafReport(taboolaLoafReport, nonTaboolaLoafReport, hasInteraction, taboolaIsMajor);

  if (hasInteraction) {
    const global = _longAnimationFramesReport.global;
    global.inpBlockingDuration = Math.max(global.inpBlockingDuration, entry.blockingDuration);

    if (taboolaIsMajor) {
      global.taboolaInpBlockingDuration = Math.max(global.taboolaInpBlockingDuration, entry.blockingDuration);
    }
  }
}

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) {
    loafEntryAnalysis(entry);
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });
  • Taboola は loafEntryAnalysis 関数を使用することで、どのエントリが主要な寄与者かを特定することができました。
  • スクリプトの再生時間全体の半分以上が Taboola に起因している場合や、Taboola スクリプトの実行に 50 ミリ秒以上かかる場合、Taboola は主要な原因と見なされます。
  • 長いアニメーション フレームが原因でユーザー操作が遅延すると、firstUIEventTimeStamp が生成されます。最も長いブロック期間が、全体的な INP スコアと見なされます。また、Taboola が Taboola の INP スコアを計算するために firstUIEventTimeStamp をトリガーしたタイミングを特定することもできます。

LoAF で収集したデータを基に、次のアトリビューション表を作成しました。これにより、収益機会を適用できる領域を特定できます。

スクリプト 時間(ミリ秒)
vpaid/units/33_6_8/infra/cmTagINLINE_INSTREAM.js:106517 997
vpaid/units/33_6_8/infra/cmTagFEED_MANAGER.js:496662 561
vpaid/vPlayer/player/v15.8.6/OvaMediaPlayer.js:44631 336
libtrc/impl.20231212-23-RELEASE.js:821090 857
publisher_name/pmk-20220605.5.js:7728 336
libtrc/card-interference-detector.20231219-7-RELEASE.es6.js:183 239
Taboola RUM によってキャプチャされた LoAF スクリプトのエントリ

TRECS エンジン: 新しい収益戦略

Taboola は、LoAF を使用してスクリプト最適化の機会をより深く理解するだけでなく、JavaScript の実行とブロック時間を大幅に最小化するためにレンダリング エンジン全体を再設計しました。

Taboola Recommendations Extensible Client Service(TRECS)は、クライアントサイド レンダリングとパブリッシャーの現在の JS コードを維持しながら、Taboola の推奨事項の読み込みに必要な必須ファイルの数とサイズを削減します。

LoAF を使用してレンダリング ブロック タスクが特定されると、「パフォーマンス フェーダー」は scheduler.postTask() を使用してメインスレッドに渡す前にこれらのタスクを分割できます。この設計により、メインスレッドを占有している可能性のある既存のタスクに関係なく、レンダリングの更新などの重要なユーザー向けの処理をできるだけ早く実行できます。

「パフォーマンス フェーダー」タスクランナーの JS スニペットを次に示します。

/**
* Send a task to run using the Fader. The task will run using the browser Scheduler, by the configuration settings, or immediately.
* @param task
* @param isBlocker
*/
function sendTaskToFader (task, isBlocker = true) {
  const publisherFaderChoice = fillOptimizationGlobals(); // Loading publisher choice
  const applyYielding = publisherFaderChoice === OptimizationFaderType.Responsiveness;

  if (applyYielding) {
    return runAsPostTask(task, isBlocker);
  }

  return runImmediately(task);
}

/**
* Yielding method using scheduler.postTask and falling back to setTimeout when it's not availabe based on the publisher choice
*/
function runAsPostTask (task, isBlocker = true) {
  if ('scheduler' in window && 'postTask' in scheduler) {
    const priority = isBlocker ? 'user-blocking': 'background';

    return window?.scheduler?.postTask(task, { priority });
  }

  const publisherChoiceEnableFallback = fillPublisherChoices();

  if (publisherChoiceEnableFallback) {
    return new Promise(resolve => {
      window.setTimeout(() => {
        resolve(task());
      }, 0);
    });
  }

  return runImmediately(task);
}

sendTaskToFader 関数:

  • runAsPostTask を使用します。これは、内部で scheduler.postTask() を使用する(API が使用可能な場合)か、setTimeout にフォールバックします。
  • この関数は、長いアニメーション フレームと INP を発生させるコードセクションに関数呼び出しをラップします。これらのコード セクションを短いタスクに分割して、INP を削減します。

ビジネス指標

LoAF のおかげで、Taboola は INP への影響をより深く理解できるようになりました。このツールは、新しい TRECS エンジンの一部として使用できるスクリプト最適化の機会も強調しました。

Taboola は、TRECS とパフォーマンス フェーダーの影響を判断するため、既存のエンジンに対する INP を測定する A/B テストを実施しました。パブリッシャー パートナーのパネルでは、スクリプトは得られませんでした。

次の表は、Taboola ネットワークの匿名パブリッシャー 4 社の 75 パーセンタイルにおける INP の結果をミリ秒単位で示したものです。

パブリッシャー TRECS + パフォーマンス フェーダーによる INP 既存のエンジンによる INP INP の低下率(%)
パブリッシャー A 48 75 36%
パブリッシャー B 153 163 6%
パブリッシャー C 92 135 33%
パブリッシャー D 37 52 29%

テストパネルで TRECS とパフォーマンス フェーダーを有効にしても、広告のクリック率やインプレッション 1,000 回あたりの収益(RPM)などのビジネス指標に悪影響はありません。INP がこのように改善したことで、Google 広告の KPI に期待どおりの結果が出ることはなかったため、Taboola は自社プロダクトに対するパブリッシャーの認識を徐々に高めていく予定です。

先ほどハイライト表示した同じお客様に対して別の Lighthouse を実行したところ、新しいエンジンを使用した場合の Taboola によるメインスレッドのブロック時間が大幅に改善されたことがわかります。

メインスレッドのブロック時間を改善するために、新しい TRECS エンジンと Performance Fader エンジンを適用した後の、ブロックされたメインスレッドの時間に関する Lighthouse の監査のスクリーンショット。監査にかかる時間は、最適化前の 712 ミリ秒からわずか 206 ミリ秒に短縮されました。
Taboola の新しいエンジンにより、RELEASE.js などのスクリプトは TBT を 485 ミリ秒(-70%)削減できました。

このことは、LoAF を使用して INP の原因を特定し、それに続くパフォーマンス フェーダーによる収益手法を導入することで、Taboola のパートナーは広告とページのパフォーマンスで最大限の成果を達成できたことを示しています。

おわりに

INP の最適化は、特にパートナー ウェブサイトでサードパーティのスクリプトが使用されている場合、複雑なプロセスになります。最適化を開始する前に、INP を特定のスクリプトにアトリビューションすることで、当て推量や、他のサイト パフォーマンス指標への潜在的な損害を排除できます。LoAF API は、ページに存在する他のテクノロジーからの干渉を排除しながら、特定の SDK の改善機会を特定できるため、特に埋め込まれたサードパーティについて、INP の問題を特定して対処するための有用なツールであることが証明されています。

LoAF を適切な収益戦略scheduler.postTask() など)と組み合わせて使用すると、ページの応答性が低い原因を観察して把握し、ウェブサイトの INP を改善するために必要な情報を得ることができます。

この作業に協力してくれた Google の Gilberto Cocchi、Noam Rosenthal、Rick Viscomi、Taboola のエンジニアリングおよびプロダクト チームの Dedi Hakak、Anat Dagan、Omri Ariav に感謝します。