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

Long Animation Frames API(LoAF)とスマートな収益戦略の採用により、Taboola がパブリッシャーの広告のパフォーマンスを損なうことなくウェブサイトの応答性を高めることができる。

David Belford
David Belford

Interaction to Next Paint(INP)は、ユーザー入力に対するウェブサイトの応答性を評価する指標です。INP は、ユーザーが操作(クリック、タップ、入力など)を開始してから、結果として得られる視覚的なフィードバックまでの時間を測定します。INP は 2024 年 3 月に最初の入力遅延(FID)に代わって Core Web Vitals に組み込まれたためです。

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

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

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

INP の代理人としての TBT

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

この相関と Taboola のパブリッシャーのTBT の高さに関する懸念から、Taboola はこの指標への貢献度を最小限に抑えることに重点を置くことにしました。

<ph type="x-smartling-placeholder">
</ph> ブロックされたメインスレッド時間の Lighthouse 監査のスクリーンショット。メインスレッドは、いくつかのスクリプトによって合計 2,630 ミリ秒ブロックされ、その時間にはサードパーティの JavaScript が 712 ミリ秒を占めていました。Taboola の RELEASE.js スクリプトは、第三者のブロック時間の大半(691 ミリ秒)を占めています。 <ph type="x-smartling-placeholder">
</ph> Taboola の古いエンジンでは、RELEASE.js のようなスクリプトはメインスレッドを 691 ミリ秒ブロックします。

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

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

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

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

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

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

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

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

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

次の JavaScript は、Taboola の影響を切り分けるために LoAF を収集するために本番環境で使用される簡易版です。

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 });
  • loafEntryAnalysis 関数を使用することで、Taboola は主な要因となっているエントリを特定できました。
  • スクリプトの合計時間の半分以上が Taboola によるものである場合、または Taboola スクリプトの実行に 50 ミリ秒を超える場合、Taboola は主な原因と見なされます。
  • firstUIEventTimeStamp は、長いアニメーション フレームが原因でユーザー操作が遅延した場合に生成されます。ブロック期間が最も長いものが全体の INP スコアになります。また、Taboola が firstUIEventTimeStamp をトリガーして Taboola INP スコアを計算したタイミングを特定することもできます。

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

で確認できます。 をご覧ください。
スクリプト 時間(ミリ秒)
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 スクリプトエントリ
<ph type="x-smartling-placeholder">

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

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

TRECS(Taboola Recommendations Extensible Client Service)を使用すると、クライアントサイドのレンダリングとニュース メディアの現在の JS コードを維持しながら、Taboola のおすすめの読み込みに必要なファイルの数とサイズを削減できます。

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

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

ビジネス指標

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

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

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

パブリッシャー INP と TRECS + パフォーマンス フェーダー 既存のエンジンを使用した INP INP の減少率(%)
パブリッシャー A 48 75 36%
パブリッシャー B 153 163 6%
パブリッシャー C 92 135 33%
パブリッシャー D 37 52 29%

幸い、テストパネルで TRECS とパフォーマンス フェーダーを有効にしても、広告のクリック率やインプレッション収益(RPM)などのビジネス指標に悪影響はありませんでした。広告の KPI で想定どおりのマイナスの結果は見られない、INP がプラスに改善したことから、Taboola はパブリッシャーの認知度の向上につながりました

先ほど強調した同じお客様で別の Lighthouse を実行すると、新しいエンジンの使用時に Taboola によるメインスレッドのブロック時間が大幅に短縮されたことがわかります。

<ph type="x-smartling-placeholder">
</ph> 新しい TRECS エンジンとパフォーマンス フェーダー エンジンを適用してメインスレッドのブロック時間を短縮し、ブロックされたメインスレッド時間の Lighthouse 監査のスクリーンショット。監査にかかる時間は、最適化が行われる前の 712 ミリ秒からわずか 206 ミリ秒に短縮されました。 <ph type="x-smartling-placeholder">
</ph> Taboola の新しいエンジンにより、RELEASE.js のようなスクリプトは TBT を 485 ミリ秒(70%)短縮できました。

この結果は、LoAF を使用して INP の原因を特定し、それに伴ってパフォーマンス フェーダーを使って収益を獲得する手法を導入することで、Taboola のパートナーが広告とページのパフォーマンスを最大限に高められることを示しています。

まとめ

INP の最適化は複雑なプロセスです。特に、パートナーのウェブサイトでサードパーティのスクリプトが使用されている場合はなおさらです。最適化を開始する前に、INP を特定のスクリプトに帰属させることで、推測に頼ったり他のサイト パフォーマンス指標への潜在的なダメージを減らしたりすることができます。LoAF API は、ページに存在する他のテクノロジーからの干渉を排除しながら、特定の SDK 改善の機会を特定できるため、特にサードパーティに INP の問題を特定して対処するための有用なツールであることが実証されています。

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

Google の Gilberto Cocchi、Noam Rosenthal、Rick Viscomi と、Taboola のエンジニアリングおよびプロダクト チームの Dedi Hakak、Anat Dagan、Omri Ariav に、この仕事に協力してもらいました。