Zomato は、インドの多国籍レストラン情報集約サイトのフード デリバリー企業です。インドだけでも 500 都市の顧客にサービスを提供しています。4, 300 万人以上のアクティブ 顧客と 1 日 150 万人以上の平均注文数を有する同社は、国内で最も人気のある料理の注文および宅配サービスの一つです。これは、お客様が使用しているデバイスの種類やネットワークの可用性も異なることを意味します。そのため、迅速な配送に加え、スムーズかつシームレスなアプリでのエクスペリエンスも求められます。
ユーザーは迅速なアプリの起動時間と応答性を期待しています。この指標の改善は、App Vitals に直接影響を与えるだけでなく、注文の完了数を増やし、Zomato の戦略を支え、新しい市場に拡大し、低価格から中価格帯のデバイスでより良いエクスペリエンスを実現します。これにより、最終的には次世代の 10 億人のユーザーを獲得できるようになります。アプリの起動時間は、ユーザーが販売目標到達プロセスの下流に進むにつれ、目標到達プロセスの規模を拡大する予測因子としても機能します。
そして Zomato は、App Vitals に重点を置いたことで大きなメリットを得ました。たとえば、アプリの読み込み時間を 30% 高速化すると、1 日目の顧客維持率は約 90% 向上しました。
課題
Zomato は開発のペースが速いうえ、機能の追加に注力しているため、お客様にとって有益ではあるものの、コードベースと UX を最適化する必要がありました。新機能を追加する一方で、パフォーマンスも同等に保ちたいと考えていました。複数の SDK が必ずしも必要ではないリソースを消費するため、コードベースを合理化、合理化する必要がありました。
これらすべての根底にあるのは、Zomato がインドの Tier 2 および Tier 3 の都市に進出したことです。この都市では、ユーザーが主に低～中規模のデバイスを使用し、処理能力が比較的限られています。これらのデバイスを採用することで、チームは上位層のデバイスと同じ世界クラスのユーザー エクスペリエンスを実現する必要がありました。
取り組みの内容
Zomato はシンプルなルーブリックを使用してオーバーヘッドを分析しました。開発チームの労力よりも費用対効果が最大となるソリューションはどれでしょうか。このルーブリックを使用し、チームは 4 か月間にわたる最適化と改善の取り組みから始めました。
最初のステップは、システム トレースを調べて問題を発見し、時間ベースの分析を行い、それに応じて優先順位を付けることでした。Perfetto は、Android プロセスを分析、プロファイリング、トレースするための完璧なツールです。Zomato はこのツールを使用して、アプリの起動時に初期化されているすべての SDK をトレースし、削除または読み込みが遅れる SDK を指摘しました。
以前の SDK と未使用のサードパーティ ライブラリの削除は、労力が少なく、高ゲインのタスクであったため、最優先でした。このアプローチにより、Zomato はアプリの起動時間を 20% も節約できました。
多くのサードパーティ ライブラリはコンテンツ プロバイダを使用してアプリの起動時に初期化します。これはアプリの起動時間に影響します。Zomato はログインに Facebook SDK を使用しますが、ユーザーは他のログイン オプションも利用できるため、起動時に SDK を初期化することは非効率的です。App Startup ライブラリの導入により、Zomato はユーザーが Facebook のログイン オプションを選択した場合にのみ SDK を読み込みます。これにより、起動時間が最大 6% 短縮されました。
次のステップは、Zomato のような複雑な UI 構造ではビュー自体のレンダリングとインフレーションにかなりの時間がかかる場合があるため、ビューのインフレーション時間を改善することでした。Viewstub を使用すると、ビューを作成できますが、必要な場合以外はビュー階層には追加できません。view スタブは、View を使用するよりも効率的です。ビューが「GONE」状態であっても、ビューがインフレートし、メモリと CPU 使用率が大量に消費されます。Zomato は、ログイン アクティビティでビュー階層をフラット化し、レイアウトとビュースタブをマージしました。これらの変更により、インフレーション時間が 7% 大幅に短縮されました。
Android Profiler は、CPU アクティビティ、メモリ、ネットワークをリアルタイムで追跡できるため、メモリ使用量の最適化に役立ちました。プロファイラを利用することで、ロック状況とメモリ オーバーヘッドの根本的な問題を特定し、それに応じて修正することができました。Zomato はキャッシュ メカニズムにも取り組み、メモリ不足の問題が 60% も大幅に減少しました。
| 行動 | 変更前（秒） | 後（秒） | 改善率 |
|---|---|---|---|
| 従来の SDK の削除、未使用のサードパーティ ライブラリの削除 | 487 万 3 | 3,813 | 21.74% |
| ライブラリの遅延読み込み | 3,814 | 3577 万台 | 6.2% |
| レイアウトの改善、viewstub | 2,529 | 2,348 | 7.15% |
アプリの起動時間 = アプリの初期化 + ライブラリの読み込み時間 + インフレーション時間の表示
結果
Zomato のパフォーマンスが向上したことで、エクスペリエンスが大幅に向上しました。UI のさらなる改善とキャッシュにより、ジャンクも減少しました。
アプリからホームページへ（アプリのアイコンをクリックして、完全に読み込まれた使いやすいホームページが表示される）ことは、Zomato が社内で追跡した主要なビジネス指標です。改善導入後、この指標は大幅な増加が見られました。完全に読み込まれたページにアクセスしたユーザーは、この期間に約 20% 増加しました。
これにより、1 日目の顧客維持率が約 90% 向上しました。こうした改善は、ファネルの順調に下流にも影響し、全体的な注文スルー率（ホーム -> メニュー -> カート -> 注文）は約 1.5% 改善しました。つまり、前月に約 60 万件の注文です。
Firebase のパフォーマンスのコールド スタートアップ指標によると、平均で 25% の改善がありました。ローエンド/ミッドエンドのデバイスでは、アプリのコールド スタートアップ時間が最大 30% 短縮されました。
アプリの起動時間のパフォーマンスは、ユーザーの認識に影響を与える重要な指標であり、パフォーマンスを最適化する取り組みは、ビジネスにも大きな影響を与える可能性があります。
「Zomato では、卓越したカスタマー エクスペリエンスの提供と構築を常にイデオロギーの中心に据えていました。パフォーマンスは重要な要素の一つだと考えています。そのため、チームは Google のデベロッパー ツールを使用してアプリの読み込み時間を改善するエンジニアリング エクセレンスに尽力し、リアルタイムで大きな成果を確認できました。これにより、インドのオンライン注文ニーズに応える超高速アプリを提供し、将来の発展のベンチマークとなることを願っています。」
- Zomato、エンジニアリング マネージャー Sajal Gupta 氏