eBay のサイトやアプリのパフォーマンスを最適化して、ユーザー エクスペリエンスを向上させる。
スピードは、2019 年の eBay の全社的な取り組みであり、多くのチームがユーザーにとってサイトとアプリを可能な限り高速化することを決定しました。実際、eBay では、検索ページの読み込み時間が 100 ミリ秒改善するごとに、「カートに追加」の数が 0.5% 増加しました。
100 ミリ秒
読み込み時間の改善
0.5%
[カートに追加] 数の増加
eBay では、パフォーマンス バジェット（Chrome ユーザー エクスペリエンス レポートでの競合調査の結果から導き出されたもの）を導入し、ユーザー中心のパフォーマンス指標に重点を置くことで、サイトの速度を大幅に改善することができました。
また、Chrome ユーザー エクスペリエンス レポートのデータでも、こうした改善が強調されています。
まだ改善の余地はありますが、eBay がこれまでに得た教訓を紹介します。
ウェブ パフォーマンスの「カット」
eBay が実現した改善は、ユーザー ジャーニーに参加するさまざまなエンティティを削減する（サイズと時間の）「カット」によって可能になりました。この投稿では、eBay 固有のトピックではなく、ウェブ デベロッパー コミュニティ全般に関連するトピックを取り上げます。
すべてのテキスト リソースでペイロードを削減する
サイトを高速化する方法の 1 つは、読み込むコードを減らすことです。eBay は、ユーザーに配信される JavaScript、CSS、HTML、JSON のレスポンスの使用されていない不要なバイトをすべてカットすることで、テキスト ペイロードを削減しました。以前は、eBay は新機能を追加するたびに、使用されていないものをクリーンアップすることなく、レスポンスのペイロードを増やし続けていました。これが時間の経過とともに積み重なり、パフォーマンスのボトルネックになっていました。チームは通常、このクリーンアップ作業を先延ばしにしていますが、eBay がどれだけ節約できたかには驚かれるでしょう。
ここでの「カット」は、レスポンス ペイロードで無駄なバイトです。
スクロールせずに見える範囲にあるコンテンツのクリティカル パスの最適化
画面上のすべてのピクセルが同じくらい重要というわけではありません。スクロールしなければ見えない範囲のコンテンツよりも、スクロールせずに見える範囲のコンテンツの方が重要です。iOS、Android、デスクトップ、ウェブアプリはこの点を認識していますが、サービスについてはどうでしょうか。eBay のサービス アーキテクチャにはエクスペリエンス サービスと呼ばれるレイヤがあり、フロントエンド（プラットフォーム固有のアプリとウェブサーバー）が通信します。このレイヤは、アイテム、ユーザー、注文などのエンティティ ベースではなく、ビューベースまたはデバイスベースになるよう設計されています。次に、eBay はエクスペリエンス サービスのクリティカル パスのコンセプトを導入しました。これらのサービスにリクエストが届くと、他のアップストリーム サービスを並行して呼び出して、スクロールせずに見える範囲のコンテンツのデータをすぐに取得します。データの準備ができると、すぐにフラッシュされます。スクロールしなければ見えない範囲のデータは、その後のチャンクまたは遅延読み込みで送信されます。その結果、スクロールせずに見える範囲のコンテンツをより迅速に表示できます。
ここでの「カット」は、サービスが関連コンテンツを表示するために費やす時間です。
画像の最適化
画像はページ肥大化の原因の一つです。小さな最適化でも大きな効果を発揮します。eBay は画像に対して 2 つの最適化を行いました。
まず、eBay は、iOS、Android、サポートされているブラウザなど、すべてのプラットフォームにおける検索結果について、WebP 画像形式を標準化しました。検索結果ページは eBay で最も画像の多いページであり、すでに WebP を使用していましたが、一貫したパターンではありませんでした。
2 つ目は、eBay のリスティング画像は（サイズと形式の両方で）大幅に最適化されていますが、キュレートされた画像（ホームページのトップ モジュールなど）には、同じ厳密さは当てはまりませんでした。eBay には、さまざまなツールを通じてアップロードされる多くの手作業でキュレートされた画像があります。以前は、最適化はアップロードしたユーザーが行いましたが、現在は eBay がツール内でルールを適用するため、アップロードされたすべての画像が適切に最適化されます。
ここでの「カット」とは、ユーザーに送信される無駄な画像バイト数です。
静的アセットの予測プリフェッチ
eBay のユーザー セッションは 1 ページだけではありません。これはフローです。たとえば、ホームページから検索ページ、アイテムページへのナビゲーションをフローとします。では、フロー内のページ同士が助け合わないのはなぜでしょうか。これが予測プリフェッチの考え方であり、あるページで次の可能性のあるページに必要な静的アセットをプリフェッチします。
予測プリフェッチでは、ユーザーが予測されたページに移動すると、アセットはすでにブラウザ キャッシュに存在します。これは、URL を前もって取得できる CSS アセットと JavaScript アセットの場合です。ここで注意すべき点として、これは初めてのナビゲーションでのみ役立つということです。その後のナビゲーションでは、静的アセットはすでにキャッシュに保存されます。
ここでの「カット」は、最初のナビゲーションにおける CSS と JavaScript の静的アセットのネットワーク時間です。
上位の検索結果のプリフェッチ
ユーザーが eBay を検索すると、eBay の分析データによると、ユーザーが検索結果の上位 10 位にあるアイテムに移動する可能性が非常に高いことがわかります。そこで eBay は、検索からアイテムをプリフェッチして、ユーザーの移動に備えた準備を整えるようになりました。プリフェッチは 2 つのレベルで行われます。
第 1 レベルはサーバーサイドで行われ、アイテム サービスは検索結果の上位 10 アイテムをキャッシュします。ユーザーがこれらのアイテムのいずれかにアクセスすると、eBay はサーバーの処理時間を節約します。サーバーサイド キャッシュはプラットフォーム固有のアプリで利用され、グローバルに展開されます。
もう 1 つのレベルは、オーストラリアで利用可能なブラウザ キャッシュにあります。アイテムのプリフェッチは、アイテムの動的な性質により高度な最適化が行われました。また、ページの表示回数、容量、オークション アイテムなど、多くの違いがあります。詳細については、LinkedIn のパフォーマンス エンジニアリング ミートアップのプレゼンテーションをご覧ください。また、eBay のエンジニアによるこのトピックの詳細なブログ投稿もご覧ください。
ここでの「短縮」は、アイテムがキャッシュされる場所に応じて、サーバー処理時間またはネットワーク時間のいずれかになります。
検索画像の積極的なダウンロード
検索結果ページでクエリが大まかに発行されると、2 つのことが発生します。1 つは再現率/ランキングのステップで、クエリに一致する最も関連性の高いアイテムが返されます。2 つ目のステップは、リコール対象の商品アイテムに、送料などのユーザー コンテキスト関連の情報を追加することです。eBay は、最初の 10 個の商品画像をヘッダーとともにすぐにブラウザに送信し、マークアップの残りの部分が到着する前にダウンロードを開始できるようになりました。その結果、画像がより迅速に表示されるようになりました。この変更は、ウェブ プラットフォームに対してグローバルに展開されています。
ここでの「カット」は、検索結果画像のダウンロード開始時間です。
自動候補データ用のエッジ キャッシング
検索ボックスに文字を入力すると、候補がポップアップ表示されます。これらの候補は、少なくとも 1 日間は文字の組み合わせでは変更されません。リクエストをデータセンターに送信する代わりに、キャッシュに保存して CDN（最大 24 時間）から提供するのが理想的な候補です。国際市場では、CDN キャッシュが特に恩恵を受けています。
しかし、問題がありました。eBay では、候補のポップアップにパーソナライズの要素がいくつか含まれていましたが、これを効率的にキャッシュすることはできません。幸いなことに、カスタマイズと提案のユーザー インターフェースを分離できるため、プラットフォーム固有のアプリでは問題ではありませんでした。ウェブにとって、国際市場では、パーソナライズの小さなメリットよりもレイテンシの方が重要でした。そのため、eBay では、eBay.com のプラットフォーム固有のアプリと米国以外の市場に対して、CDN キャッシュからの自動候補をグローバルに提供できるようになりました。
ここでの「カット」は、自動候補のネットワーク レイテンシとサーバー処理時間です。
認識されないホームページ ユーザーのためのエッジ キャッシング
ウェブ プラットフォームの場合、認識できないユーザーのホームページ コンテンツは特定の地域で同じです。eBay を初めて使用するユーザー、または新しいセッションを開始するため、パーソナライズを行わないユーザーです。ホームページのクリエイティブは頻繁に変更されますが、キャッシュの余地はまだあります。
eBay は、認識できないユーザー コンテンツ（HTML）を自社のエッジ ネットワーク（PoPs）に短期間キャッシュすることにしました。初めてのユーザーは、遠く離れたデータセンターからではなく、近くのサーバーからホームページのコンテンツを閲覧できるようになりました。eBay は現在、国際市場でこれをテストしており、大きな効果が期待されています。
ここでも「短縮」は、認識できないユーザーに対するネットワーク レイテンシとサーバー処理時間の両方です。
他のプラットフォームの最適化
iOS/Android アプリの解析の改善
iOS/Android アプリは、レスポンス形式が通常 JSON のバックエンド サービスと通信します。これらの JSON ペイロードは大きくなる場合があります。eBay は、JSON 全体を解析して画面に何かを表示する代わりに、すぐに表示する必要があるコンテンツを最適化する効率的な解析アルゴリズムを導入しました。
コンテンツの表示が速くなります。さらに、Android アプリの場合、ユーザーが検索ボックスに入力し始めるとすぐに検索ビュー コントローラの初期化が開始されます（iOS ではすでにこの最適化が行われています）。これまでは、これはユーザーが検索ボタンを押した後にのみ発生していました。これにより、ユーザーはより早く検索結果にアクセスできるようになります。ここでの「カット」は、デバイスが関連コンテンツを表示するのに費やす時間です。
Android アプリの起動時間の改善
これは、Android アプリのコールド スタート時間の最適化に適用されます。アプリのコールド スタートが発生すると、OS レベルとアプリケーション レベルの両方で多くの初期化が行われます。アプリケーション レベルで初期化時間を短縮することで、ユーザーがホーム画面を素早く確認できるようになります。eBay がプロファイリングを行ったところ、コンテンツの表示にすべての初期化が必要になるわけではなく、一部の初期化は遅延できることが判明しました。
さらに重要なこととして、eBay は、画面へのレンダリングを遅延させるブロッキング型のサードパーティ分析呼び出しがあることを確認しました。ブロッキング呼び出しを削除して非同期にすることで、コールド スタートの時間が短縮されました。ここでの「カット」は、Android アプリの不要な起動時間です。
まとめ
eBay が行ったすべてのパフォーマンス「カット」は、全体として大きな変化をもたらしました。そして、それは長期にわたって行われました。リリースは 1 年を通じて段階的に行われ、各リリースにかかる時間が数十ミリ秒短縮され、最終的に eBay は次のようになっています。
パフォーマンスは機能であり、競争上の優位性でもあります。エクスペリエンスを最適化すると、ユーザー エンゲージメント、コンバージョン、ROI が向上します。eBay の場合、こうした最適化は、労力が小さいものから高度なものまで、多岐にわたりました。
「1,000 切り刻みのスピード」で詳細をご覧ください。また、eBay のエンジニアによる、近い将来のパフォーマンスに関する詳しい記事にもご注目ください。