新しいメルカリ Web と そのパフォーマンス Shogo Sensui (@1000ch) at #高速化_findy (2023-03-22)

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

GroundUP Web プロジェクトの発足 新しいメルカリ Web の話 from 2020/02 to 2021/08

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

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

要件に応じた アーキテクチャの検討 もちろんパフォーマンスは重要である前提で、技術や設計を考える

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

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

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

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

GroundUP Web プロジェクトの成果

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

数ヶ月の運用を 踏まえた今後の方向性 期待通りに進んだこと・進まなかったこと

様々なトレードオフを踏まえて ● 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 サーバーの維持管理コストが未知数 🤔

まとめ

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

おわり メルカリ Web はこちらから👉