Trendyol が INP を 50% 削減した結果、クリック率が 1% 上昇した方法

このケーススタディでは、INP のデバッグと改善のワークフローを詳細に説明します。 Trendyol が使用している React で、PageSpeed などの Google ツールを活用している Insights（PSI）、Chrome DevTools、scheduler.yield API があります。

Mustafa Birinci

Gilberto Cocchi

Thierno Thiam

e コマースサイトを構成する 2 つの重要な要素は商品リスティングページです商品の詳細ページ（PDP）です。e コマースのトラフィックの多くは商品リスティングページ（メールキャンペーン、ソーシャルメディア、表示されなくなります。そのため、PLP のエクスペリエンスを購入までの時間を短縮することを念頭に置いて設計されています。優先順位付け成功するためにはユーザーエクスペリエンスの質が不可欠です研究発表をご覧くださいウェブパフォーマンスが消費者の投資する意思があることをオンラインでのブランドとの提携

Trendyol は、約 3,000 万人の顧客を抱える e コマースプラットフォームです。 240,000 の販売者を抱え、トルコ初の企業となりました。同社は e コマースプラットフォームのできます。

可能な限り最良のユーザーエクスペリエンスを大規模に提供するという同社の目標を達成するためコンテンツの柔軟性を保ちながら、古いバージョンの React の Trendyol は、重要な指標として Interaction to Next Paint（INP）に焦点を当てました。向上しますこのケーススタディでは、 PLP の導入により、INP が 50% 減少、検索が 1% 増加ビジネス指標。

Trendyol の INP 調査プロセス

INP はユーザー入力に対するウェブサイトの応答性を測定します。INP が優れているということは、ブラウザがすべてのユーザー入力にすばやく確実に応答し、ページを再描画します。これは、優れたユーザーエクスペリエンスの重要な要素です。

Trendyol が PLP で INP を改善する取り組みの第一歩は、改善を行う前のユーザーエクスペリエンスです。PSI レポートによると PLP の実際のユーザーエクスペリエンスは、 モバイルデバイスの IP アドレスに接続する必要があります。

PageSpeed Insights の CrUX レポートに基づく Trendyol の INP。2023 年 9 月 5 日時点での Trendyol の INP は 963 ミリ秒で、あります。 — </ph> 2023 年 9 月 5 日時点の PSI による Trendyol の INP。

優れた応答性を確保するには、サイト所有者は INP を以下または 200 ミリ秒です。つまり、その時点で Trendyol の INP は「要改善」あります。

幸いなことに、PSI は、Chrome ユーザーエクスペリエンスレポート（CrUX）と詳細なラボ診断データが提供されます。ラボを見る Lighthouse の JavaScript 実行時間監査によると、 search-result-v2 スクリプトが他のスクリプトよりも長い時間メインスレッドを占有していた使用できます。

Trendyol のウェブサイトにおける、Lighthouse の長文タスクのソース資料。長いタスクの主な発生源の 1 つは、Trendyol の PLP での検索結果を処理するスクリプトです。 — </ph> Lighthouse による Trendyol の JavaScript 実行時間監査（9 月時点） 2023 年 5 月 5 日、PSI。

実際のボトルネックを特定するために、Chrome のパフォーマンスパネルを使用しました。 DevTools を使用して PLP エクスペリエンスをトラブルシューティングし、あります。Chrome DevTools で CPU の 4 倍低速なモバイルのパフォーマンスをエミュレートする メインスレッドでの 700 ～ 900 ミリ秒のタスクを明らかにしました。メインのスレッドが他のタスクで 50 ミリ秒以上占有されている場合、ユーザー入力にタイムリーに応答できないため、向上させることができます

Trendyol の PLP に関する Chrome DevTools のパフォーマンスプロファイリングセッションのスクリーンショット。この図の長いタスクは、737.6 ミリ秒にわたって実行され、Intersection Observer コールバックの一部です。 — </ph> Performance Profiler のパネルを開きます。

最も長いタスクは、インスタンスの Intersection Observer API コールバックによって React コンポーネント内で検索結果スクリプトを実行しますこの時点で長いタスクを小さなチャンクに分割してブラウザにより多くの処理をユーザーとのやり取りなど、優先度の高い作業に対応する機会が得られます。

React をトリガーする setState オペレーションを使用すると、 Intersection Observer コールバック内の再レンダリングにはコストがかかります。ローエンドのデバイスでは問題となる可能性があります。そのためには、長すぎます。

これまでデベロッパーがタスクを小さなものに分割する方法の 1 つに setTimeout が関与します。この手法を使用して、別のタスクに setState 呼び出します。setTimeout では遅延が可能になりますが、優先度を制御できません。これにより、 scheduler.yield オリジントライアルに参加して、メインスレッドに送られた後のスクリプト実行の継続:

/*
* Yielding method using scheduler.yield, falling back to setTimeout:
*/
async function yieldToMain() {
  if('scheduler' in window && 'yield' in scheduler) {
    return await scheduler.yield();
  }

  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

/*
* Yielding to the main thread before changing the state of the component:
*/
const observer = new IntersectionObserver((entries) => {
  entries.forEach(handleIntersection);
  const maxNumberOfEntries = Math.max(...this.intersectingEntries);

  if (Number.isFinite(maxNumberOfEntries)) {
    await this.yieldToMain();

    this.setState({ count: maxNumberOfEntries });
  }
}, { threshold: 0.5 });

この生成メソッドを PLP コードに追加した結果、INP が改善されました。一連の小さなタスクに分割されました。これにより、優先度の高い処理（ユーザーの操作や後続のレンダリング処理など）をより迅速に行われるようになります。

Trendyol の PLP に関する Chrome DevTools のパフォーマンスプロファイリングセッションのスクリーンショット。これまで 737.6 ミリ秒で実行されていた長いタスクが、いくつかの小さなタスクに分割されました。 — </ph> タスクを小さなものに分割しました。

なお、Trendyol は、PuzzleJs フレームワークを使用してマイクロフロントエンドを実装しています。 React v16.9.0 を使用しています。React 18 でも同じパフォーマンスをしかし、さまざまな理由から Trendyol はあります。

ビジネスの成果

導入した INP の改善による効果を測定するために、A/B テストを実施して、ビジネス指標への影響を確認できますPLP の変更により、 INP の 50% 削減および 1% のコスト削減など、リスティングページから商品の詳細ページまでのクリック率が上昇ユーザーセッションごとに課金対象となります次の図を見ると、P-MAX の PLP の推移:

6 か月間にわたる Trendyol の 75 パーセンタイル INP のスクリーンショット。半年の終わりまでに、Trendyol の INP は約 1,400 ミリ秒から約 650 ミリ秒に減少しました。 — </ph> 経時的な 75 パーセンタイルの INP 改善。

まとめ

INP の最適化は複雑で反復的なプロセスだが、簡単にできる明確なワークフローが必要ですサイトのデバッグと改善を行うウェブサイトの INP は、独自のフィールドデータを収集するかどうかによって異なります。もし PSI と Lighthouse から始めることをおすすめします。目標を特定し問題のあるページが見つかった場合は、DevTools を使用してさらに掘り下げて再現を試みるサポートします。

ブラウザの処理時間を増やすために、ときどきメインスレッドに移るウェブサイトの応答性が向上し、顧客体験の向上につながります新しい Scheduling API scheduler.yield() のようにすると、このタスクが容易になります。

Google Cloud の Jeremy Wagner、Barry Pollard、Houssein Djirdeh に Google、Trendyol のエンジニアリングチームの協力を得て開発されました。