1 of 17

新しいメルカリ Web と

そのパフォーマンス

Shogo Sensui (@1000ch) at #高速化_findy (2023-03-22)

2 of 17

Shogo SENSUI

SIer での受託開発を経て、2012 年に株式会社サイバーエージェントに入社。様々な事業開発の傍ら、エンジニア組織のマネジメントに従事。2018 年に株式会社メルカリに入社後は、株式会社メルペイの Frontend チームの立ち上げや Web 版の「メルカリ」の刷新、メルカリアプリのコードベース刷新を牽引した後に、執行役員 VP of Engineering としてメルペイのエンジニアリング部門を管掌。

3 of 17

GroundUP Web

プロジェクトの発足

新しいメルカリ Web の話 from 2020/02 to 2021/08

4 of 17

GroundUP Web プロジェクトの発足背景

  • レガシー Web を書き直すプロジェクトが進行していたが、思うようにスピードが出ず長期化
    • 既存機能の互換性を維持して、技術のみを置換していた
    • 同時に新しい機能開発も行っていた
  • Web に求めることを再整理し、経営として仕切り直しを意思決定
    • もともと Web である程度の数字規模があった
    • Web ならではの事業ポテンシャルを期待できる

5 of 17

メルカリ Web に求め（られ）たこと

  • スピード感を以て負債を捨て切り、中長期的なプロダクトの成長に耐えうるソフトウェアになっていること
    • モダンな技術かつ持続可能なアーキテクチャのソフトウェア
  • アクセシブルで多言語に対応し、モバイルかデスクトップかを問わず iOS や Android 版と等しい機能性が提供されていること
  • リリースまでだけではなくリリース後も、組織として Web に対して継続的にコミットする体制になっていること
    • ちゃんと Web でも機能等価性を維持していける組織構造に
    • 数字規模で言えばアプリだが、鶏卵なので決めの問題

6 of 17

要件に応じた

アーキテクチャの検討

もちろんパフォーマンスは重要である前提で、技術や設計を考える

7 of 17

思考の軸になったこと（技術）

  • ベースとなる実装技術として React と TypeScript
    • 社内にあった豊富な知見と経験、そしてライブラリなどの資産
    • React のフットプリントが大きいので、軽量な代替ライブラリは頭をよぎった
      • Preact とか、最近で言えば Solid.js とか
      • 当時のエコシステムの成熟状況を踏まえて、React に無難に着地
  • （詳しくは後述）事前に HTML を生成するために Gatsby
    • スケルトン UI を含む HTML を素早く表示させ、認知的な性能を担保
    • ページに応じた HTML を限定し、キャッシュ効率を高めたい

8 of 17

思考の軸になったこと（要件）

  • ハイパフォーマンスでアクセシブルでセキュアで SEO フレンドリー
    • 近接している関心事項としてデザインシステム
    • 特定の UI ライブラリに依存しないよう Web Components
  • SEO フレンドリー ＝ 完成版の HTML をクローラーに返すこと
    • 動的なデータを含む Declarative Shadow DOM であれば SEO 上は問題ない（はず）
  • SSR なのか CSR なのか ≒ Node.js の運用にコミットするのか
    • 大量のトラフィックを捌く Node.js サーバーを運用したくないので、CSR を選択

9 of 17

ブラウザからのアクセスの場合

10 of 17

クローラーからのアクセスの場合

11 of 17

GroundUP Web

プロジェクトの成果

12 of 17

性能向上による KPI 改善だけではなく

  • UI の刷新および抜本的な性能向上による KPI の改善
    • GMV をはじめとした各種 KPI のメルカリ Web の数字が倍増
  • 積もりに積もった様々な技術的負債の返済
    • メンテナンスが難しくなっていた古いコードベースの撤廃
  • 今後の事業を支えるソフトウェア基盤
    • iOS と Android だけでなく Web を踏まえた事業計画の幅出し

13 of 17

数ヶ月の運用を

踏まえた今後の方向性

期待通りに進んだこと・進まなかったこと

14 of 17

様々なトレードオフを踏まえて

  • 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 of 17

まとめ

16 of 17

周辺要因を理解することも肝要

  • 基礎技術としてブラウザや Frontend の知識は求められる
    • ブラウザの振る舞いを理解する、修正する前に計測する
    • web.dev のパフォーマンスタグや超速本など
  • 決して凝ったものではなく、プレーンな設計と実装
    • ブラウザ処理の起点になる HTML がいち早く届けられていること
    • 要件に応じて適切に技術的な選択ができることが重要
  • これからの意思決定の積み重ねがソフトウェアを左右していく
    • 品質に対する組織アテンションをどう維持していくのか

17 of 17

おわり

メルカリ Web はこちらから👉