Laravelのフロントエンドを Next.jsに段階的に移行している話 2024/2/28 TechBrew in 東京 〜フロントエンド技術選定、その後どうなった？〜 株式会社じげん　松本拓人

たかとく(松本拓人) 所属 出身 趣味 最近の関心ごと 技術スタック 株式会社じげん エンジニア 栃木 マンガ、アニメ、サウナ、ジム web アクセシビリティ、hono PHP(Laravel) 、TypeScript 、 React/Next.js 、 @takatoku_learn 年齢 25( エンジニア歴3 年) 自己紹介

No content

サービス説明 国内日本最大級のリフォーム会社マッチングサービス 月間平均ユーザー数120 万人を誇る 厳選した全国4,000 社以上のリフォーム会社からニーズに即した業者をオ ンラインで簡単に検索でき、一括見積もり・比較が可能

技術スタック 段階的にこちらに移行中

コード品質の低さによる可読性と拡張性の低下 デザインの統一感がない エラーやバグの検知が遅い 不必要なライブラリ・モジュールの読み込み フロントエンド起因のコンパイルの時間増加 旧来の環境の問題点 旧来のリショップナビのフロントエンド環境の問題点 責務の集中 循環参照 デッドコードの放置

コード品質の低さによる可読性と拡張性の低下 デザインの統一感がない エラーやバグの検知が遅い 不必要なライブラリ・モジュールの読み込み フロントエンド起因のビルド時間増加 品質維持の仕組みを導入しにくい 多様なフロントエンド要求に対応できない リファクタリング js フレームワーク(vue) の拡充 フロントエンドを切り出し新しいフレームワーク導入 SEO に対して弱くなる懸念 vue2→vue3 へのアプデート大変 時間はかかるが、フロントエンド分離を選択 なぜ移行するのか 旧来のリショップナビのフロントエンド環境の問題点 解決手段として

段階的な移行 フロントエンド移行はTop ページから 段階的に始めた 全体の移行には時間がかかりすぎる 開発者の負担的にも、事業リスク的にもビックリラ イトは非現実的 定期的に成果を出せた方がビジネス側を説得しやす い top ページから段階的に始めることで、複雑なペー ジはナレッジが溜まってきてから取り組むことがで きる top ページはサイトの顔であるためデザインの方向 性を決めやすい

Next.js （App router ） 技術選定 フロントエンド分離先で採用するフレームワークは を採用

選定理由 Next.js を選んだ理由 コミュニティの信頼度が高い 後方互換性が意識されたバージョンアップ 情報量が多い 導入事例も豊富で詰まったときにも大体情報がある ライブラリが豊富 react 界隈のライブラリを使える 技術的な選択肢の幅が多い パフォーマンスのチューニングもある程度選択肢がある レンダリング方法、キャッシュ、etc... 人数が少なくても開発、追従が可能 全てカスタムで選定、実装すると属人化やバージョンア ップがしんどい 前提 フロントエンド専門チームはな く、ある程度フルスタックにエ ンジニアが活動している C 向けのサービスなので、SEO 対策を意識した実装が必要

候補に上がったフレー ムワーク vue(Nuxt) Remix Svelte Preact webComponent 系 コミュニティ信頼度の問題 バージョンアップによる後方互換の不安 利用率が低いフレームワークだと経験者採 用が難しい 情報量が少なく、詰まった場合に解決に時 間がかかる 管理するべきライブラリが増えることによ り、フロントエンドに時間が取られる 候補に上がったフレームワーク 採用されなかった理由

移行してみて ESLit やPrettier などにより、コーディングの品質を保つ仕組みを導入可 能に Storybook の導入により、デザイナーとのコミュニケーションコスト削減 情報がたくさんあり、つまるところが少なかった SSR がパフォーマンスのボトルネックになってない ストリーミングやdynamic import になどパフォーマンスチューニングの幅が広い App router 以降のコロケーション実現によりコードの見通しが良くなっ た 良かったこと

移行してみて 残念だったこと vercel 上で動かさないとNext.js のフルパワーは出せない 新しくstable になった機能でもnode.js 上で動くのか心配 Next.js(vercel) に依存しすぎてしまう キャッチアップコストが高い 複雑なフレームワーク仕様や独自コンポーネント、fetch api のラップ、キャッシュの罠など覚え るべき事項が多い 技術の進化が早すぎる 周辺ライブラリが追従してない場合がある 不安定なフレームワーク挙動 ベストプラクティスの変化が激しい

【SP 】 リリース前 リリース後 Performance 87 96 FCP 1.2s 1.3s LCP 3.7s 2.5s TBT 120ms 90ms CLS 0 0 Speed Index 3.8s 2.2s Accessibility 85 96 BestPractice 92 95 SEO 83 98 【PC 】 リリース前 リリース後 Performance 89 100 FCP 0.5s 0.4s LCP 1.4s 0.5s TBT 0ms 0ms CLS 0 0 Speed Index 0.8s 0.6s Accessibility 83 96 BestPractice 83 100 SEO 83 100 現在の姿 リリース前後でlight-house スコアが上昇 * リリース当時のスコア

現在の姿 Next.js 独自コンポーネントをラップするなどして変化に強い設計に（third party ライブラリも同様） コンポーネント分類にatomic design の採用をやめ、独自のルールを採用 (feature ディレクトリに近いものを導入)← 近いうちにまとめて記事にするかも 状態管理にはContext API を使用 バックエンドとの通信にopen api 、コード自動生成にorval を使う server action を使うかどうか悩み中

最後に まだまだ移行途中 完遂目指して頑張ります！ フロントエンジニアも募集してるので興味あればぜひカジュアル面談を🙇