新しいメルカリ Web とそのパフォーマンス / The New Mercari Web and its performance

2023年3月22日に開催された Findy Tech Talk ~Frontend~ 「2023年のフロントエンド高速化手法~Fastlyとメルカリに学ぶ、パフォーマンスチューニング最前線」 (https://findy.connpass.com/event/276615/) の「新しいメルカリ Web とそのパフォーマンス」のセッション資料です。

Transcript

1. 新しいメルカリ Web と そのパフォーマンス Shogo Sensui (@1000ch) at #高速化_findy (2023-03-22)
2. Shogo SENSUI SIer での受託開発を経て、2012 年に株 式会社サイバーエージェントに入社。 様々な事業開発の傍ら、エンジニア組織 のマネジメントに従事。2018 年に株式会 社メルカリに入社後は、株式会社メルペ イの Frontend チームの立ち上げや Web 版の「メルカリ」の刷新、メルカリア プリのコードベース刷新を牽引した後に、 執行役員 VP of Engineering としてメル ペイのエンジニアリング部門を管掌。
3. GroundUP Web プロジェクトの発足 新しいメルカリ Web の話 from 2020/02 to 2021/08
4. GroundUP Web プロジェクトの発足背景 • レガシー Web を書き直すプロジェクトが進行していたが、思うようにスピードが 出ず長期化 ◦ 既存機能の互換性を維持して、技術のみを置換していた ◦ 同時に新しい機能開発も行っていた • Web に求めることを再整理し、経営として仕切り直しを意思決定 ◦ もともと Web である程度の数字規模があった ◦ Web ならではの事業ポテンシャルを期待できる
5. メルカリ Web に求め（られ）たこと • スピード感を以て負債を捨て切り、中長期的なプロダクトの成長に耐えうるソフト ウェアになっていること ◦ モダンな技術かつ持続可能なアーキテクチャのソフトウェア • アクセシブルで多言語に対応し、モバイルかデスクトップかを問わず iOS や Android 版と等しい機能性が提供されていること • リリースまでだけではなくリリース後も、組織として Web に対して継続的にコミッ トする体制になっていること ◦ ちゃんと Web でも機能等価性を維持していける組織構造に ◦ 数字規模で言えばアプリだが、鶏卵なので決めの問題
6. 要件に応じた アーキテクチャの検討 もちろんパフォーマンスは重要である前提で、技術や設計を考える
7. 思考の軸になったこと（技術） • ベースとなる実装技術として React と TypeScript ◦ 社内にあった豊富な知見と経験、そしてライブラリなどの資産 ◦ React のフットプリントが大きいので、軽量な代替ライブラリは頭をよぎった ▪ Preact とか、最近で言えば Solid.js とか ▪ 当時のエコシステムの成熟状況を踏まえて、 React に無難に着地 • （詳しくは後述）事前に HTML を生成するために Gatsby ◦ スケルトン UI を含む HTML を素早く表示させ、認知的な性能を担保 ◦ ページに応じた HTML を限定し、キャッシュ効率を高めたい
8. 思考の軸になったこと（要件） • ハイパフォーマンスでアクセシブルでセキュアで SEO フレンドリー ◦ 近接している関心事項としてデザインシステム ◦ 特定の UI ライブラリに依存しないよう Web Components • SEO フレンドリー ＝ 完成版の HTML をクローラーに返すこと ◦ 動的なデータを含む Declarative Shadow DOM であれば SEO 上は問題ない（はず） • SSR なのか CSR なのか ≒ Node.js の運用にコミットするのか ◦ 大量のトラフィックを捌く Node.js サーバーを運用したくないので、 CSR を選択
9. ブラウザからのアクセスの場合
10. クローラーからのアクセスの場合
11. GroundUP Web プロジェクトの成果
12. 性能向上による KPI 改善だけではなく • UI の刷新および抜本的な性能向上による KPI の改善 ◦ GMV をはじめとした各種 KPI のメルカリ Web の数字が倍増 • 積もりに積もった様々な技術的負債の返済 ◦ メンテナンスが難しくなっていた古いコードベースの撤廃 • 今後の事業を支えるソフトウェア基盤 ◦ iOS と Android だけでなく Web を踏まえた事業計画の幅出し
13. 数ヶ月の運用を 踏まえた今後の方向性 期待通りに進んだこと・進まなかったこと
14. 様々なトレードオフを踏まえて • Design System を Web Components から Pure React へ ◦ Web Components と React の二重になっているパッケージ管理の単純化 👍 ◦ 単一の UI ライブラリへの依存による Design System の可搬性の低下🤔 • 部分的な CSR から統一的な SSR へ書き直し中 ◦ React と Next.js による SSR の実現 ▪ 完成版 HTML レスポンスによるパフォーマンスのさらなる向上 👍 ▪ HTML が URL に対してユニークになるので CDN のキャッシュヒット率の低下 🤔 ◦ Rendertron で実装している Prerender 用のサーバーの撤廃 ▪ クローラーからのリクエストへのレイテンシが大幅に低減 👍 ▪ Node.js サーバーの維持管理コストが未知数 🤔
15. まとめ
16. 周辺要因を理解することも肝要 • 基礎技術としてブラウザや Frontend の知識は求められる ◦ ブラウザの振る舞いを理解する、修正する前に計測する ◦ web.dev のパフォーマンスタグ や超速本など • 決して凝ったものではなく、プレーンな設計と実装 ◦ ブラウザ処理の起点になる HTML がいち早く届けられていること ◦ 要件に応じて適切に技術的な選択ができることが重要 • これからの意思決定の積み重ねがソフトウェアを左右していく ◦ 品質に対する組織アテンションをどう維持していくのか
17. おわり メルカリ Web はこちらから👉