Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
React ViteからNext.jsへ切り替えたプロセスとApp Router化のボトル...
Search
sumiren
January 24, 2024
Programming
3
3.5k
React ViteからNext.jsへ切り替えたプロセスとApp Router化のボトルネック | 株式会社ヘンリー
株式会社ヘンリーからFindy様のイベントに登壇した際の記事です。
https://findy.connpass.com/event/306714/
sumiren
January 24, 2024
Tweet
Share
More Decks by sumiren
See All by sumiren
OpenTelemetryの位置づけと高度なオブザーバビリティオペレーション
sumiren
2
530
HoneycombとOpenTelemetryでオブザーバビリティに入門してみる
sumiren
2
2k
フロントエンドパフォーマンスの変遷とNext.jsに見る次の時代
sumiren
25
9.1k
クラウドへのOpenTelemetry導入のハマりどころ
sumiren
0
230
ローコード自動テストを1ヶ月半で導入した話
sumiren
0
780
スタートアップでのmabl導入事例とリーディングテクニック
sumiren
0
290
Next.js 13 Layout / Streaming SSR 仕組み解説
sumiren
3
1.8k
Other Decks in Programming
See All in Programming
How mixi2 Uses TiDB for SNS Scalability and Performance
kanmo
41
16k
Rails 1.0 のコードで学ぶ find_by* と method_missing の仕組み / Learn how find_by_* and method_missing work in Rails 1.0 code
maimux2x
1
250
苦しいTiDBへの移行を乗り越えて快適な運用を目指す
leveragestech
0
1.1k
Go 1.24でジェネリックになった型エイリアスの紹介
syumai
2
290
SwiftUI移行のためのインプレッショントラッキング基盤の構築
kokihirokawa
0
150
読まないコードリーディング術
hisaju
0
110
Honoとフロントエンドの 型安全性について
yodaka
7
1.5k
15分で学ぶDuckDBの可愛い使い方 DuckDBの最近の更新
notrogue
3
540
sappoRo.R #12 初心者セッション
kosugitti
0
280
Amazon Bedrockマルチエージェントコラボレーションを諦めてLangGraphに入門してみた
akihisaikeda
1
100
CDKを使ったPagerDuty連携インフラのテンプレート化
shibuya_shogo
0
110
未経験でSRE、はじめました! 組織を支える役割と軌跡
curekoshimizu
1
170
Featured
See All Featured
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.2k
How to Think Like a Performance Engineer
csswizardry
22
1.4k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
Speed Design
sergeychernyshev
27
810
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Music & Morning Musume
bryan
46
6.4k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Building Applications with DynamoDB
mza
93
6.2k
Making the Leap to Tech Lead
cromwellryan
133
9.1k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
33
2.8k
The Cost Of JavaScript in 2023
addyosmani
47
7.4k
Transcript
Copyrights(c) Henry, Inc. All rights reserved. React ViteからNext.jsへ 切り替えたプロセスと App
Router化のボトルネック
Copyrights(c) Henry, Inc. All rights reserved. 自己紹介 @sumiren_t (発音:すみれん) 仕事
• プロダクトエンジニア @ 株式会社ヘンリー • 技術顧問 / SWE @ フリーランス副業 数社様 強み 1 • フロント、バック、インフラ • 自動テスト、オブザーバビリティ • 組織マネジメント、プロジェクトマネジメント
Copyrights(c) Henry, Inc. All rights reserved. 会社名 株式会社ヘンリー 事業概要 電子カルテ/レセプト会計システム
“Henry” を開発・販売及び、 コンサルティング事業 所在地 東京都品川区東五反田2丁目9 −5 サウスウィング東五反田 3F 創業 2018年5月 代表者 逆瀬川 光人、林 太郎 社員数 50名(正社員)+業務委託 認証取得 ISMS 国際規格「ISO 27001」 医療ISAC規定認証 Mission 社会課題を解決し続け、より良いセカイを創る Service 電子カルテ / レセプト会計システム「Henry」 株式会社ヘンリー |社会課題の解決を目的に設立 2
Copyrights(c) Henry, Inc. All rights reserved. アジェンダ 1. React ViteからNext.jsに乗り換えた流れ
2. App Router化のボトルネック 3
Copyrights(c) Henry, Inc. All rights reserved. アジェンダ 1. React ViteからNext.jsに乗り換えた流れ
2. App Router化のボトルネック 4 関連ブログ記事:https://dev.henry.jp/entry/replace-vite-with-nextjs
Copyrights(c) Henry, Inc. All rights reserved. React + Viteを使っていた際は、First load
JSが4MBほどもあり、通信とブラウザ でのJS処理に時間がかかっており、FCPに悪影響を与えていた オーバーヘッド 参考数値 原因 JSチャンクの取得 開発マシン / 良好な通信状況で 1000ms 以上 (ブラウザキャッシュがない場合) 4MBものチャンクサイズ。 チャンク分割をしていなかった ブラウザでのReact レンダリング処理 開発マシン / 良好な通信状況で 〜200ms 程度 (JSのみキャッシュありの場合) SPAではFCPまでにHTMLとJSを読 み込みJSを実行する3ステップが必 要 【React + Vite時代のHenryのFCP課題】 5
Copyrights(c) Henry, Inc. All rights reserved. Next.js Pages Routerを採用することで、課題の解決を狙った 課題
ソリューション Next.jsにしたことによる 改善の参考数値 4MBの First Load JS Next.jsであればpageごとにビルドされ、その中 でのチャンク分割も標準である程度行ってくれ る。よって特別な工夫をしなくてもチャンクサイズ を抑えやすい First Load JSが 4MB → 最大1MB 開発マシン / 良好な通信状況で 1000ms → 300ms にオーバーヘッド改善 SPA特有のReactレン ダリング完了までの リードタイム Next.jsのプリレンダリングを利用すれば、 HTMLを読み込む1ステップだけでFCPを達成 できる。ハイドレーションのための JS実行は存 在するが、画面の描画には影響しない 開発マシン / 良好な通信状況で 〜200ms → 50ms にオーバーヘッド改善 【HenryのFCP課題を解決するためのNext.js採用】 6
Copyrights(c) Henry, Inc. All rights reserved. 補足:以前ブログ記事でNext.js移行でFCPが大幅改善したと説明した。当該記事では FCPが8倍改善しているが、実はここには認証処理をレンダリングの前提にしない対応をつ いでに入れており、その影響も受けていると想定される 【ブログ記事の切り抜き】
https://dev.henry.jp/entry/replace-vite-with-nextjs 7
Copyrights(c) Henry, Inc. All rights reserved. 移行プロセスとして、ViteとNext.js両方で動かせるようにアプリを修正し、テスト環 境をVite版とNext.js版の両方作って並行運用した src pages
pages page1.tsx page1next .tsx … … import build build 8
Copyrights(c) Henry, Inc. All rights reserved. こうした並行運用により、開発を止めずに移行したり、じっくりQAを行うことができ た サマリ 一斉切り替えの課題
並行運用のメリット 開発を止めない ViteからNext.jsに切り替える大量の差分を一度に マージすると、その間 Viteベースで開発しているプロ ダクトエンジニアに大きな手戻りを起こしてしまう。 Viteベースで機能開発しつつ、手隙の際に Next.js側 にアダプターを書く形で対応することができ、手戻りを 起こしづらい オンボーディングの時間 を取れる ある瞬間いきなりNext.jsに切り替えると、サーバーサ イドで動作するReactを書いたりフレームワークに慣 れず、プロダクトエンジニアの混乱が予想される Next.jsについてオンボーディングしたり、切り替えま でに慣れることができる(急ぎの機能開発は一旦 Vite だけ対応し、後でNext.jsで動くようにじっくり直すな ど) じっくりQAできる ある程度開発を止めることになるため、大規模なアー キテクチャ変更にも関わらず QAを急ぐことになる 本番にデプロイされている Vite版をテスト環境でQAし つつ、並行でNext.js版のテスト環境もQAできる 移行を中断できる QAの結果やっぱりViteに戻りたいといったときに、リ バートするだけでは済まない(プロダクトエンジニアが Next.jsベースですでに開発してしまっているため) 並行運用期間中はNext.js部分のコードベースを捨て るだけでViteに戻れる 9
Copyrights(c) Henry, Inc. All rights reserved. アジェンダ 1. React ViteからNext.jsに乗り換えた流れ
2. App Router化のボトルネック 10
Copyrights(c) Henry, Inc. All rights reserved. App Router化したい 11
Copyrights(c) Henry, Inc. All rights reserved. Next.js Pages Routerを導入してFCPは改善したものの、LCPには課題がある。SPAから 移行する際、データフェッチ戦略はクライアントサイドのままにした。基幹システムのバー
ティカルSaaSであるため、画面が複雑でGraphQLリクエストが大量に発生している 最も複雑な画面では、LCPのためだ けに10個程度のGraphQLリクエスト が発生。帯域幅次第で大きくパ フォーマンスが落ちる他、リクエスト がウォーターフォールになる画面は 顕著にLCPが落ちる。 12
Copyrights(c) Henry, Inc. All rights reserved. Next.jsの場合、App RouterではStreaming Server Renderingを利用できる。サーバーサ
イドでデータフェッチしつつ、chunked responseで画面のデータに依存しない部分はブラウ ザでレンダリングできる。サーバー間に通信回数と通信量を集約することで、データフェッチ の通信オーバーヘッドを削減できる また、Next.js 14で追加されたPartial Rendering(experimental)ではこの 一番上のBの部分をプリレンダリング することに挑戦している。(参考まで に、10ms〜50ms程度のリードタイ ム削減になると予想) 【Next.js公式より引用】 https://nextjs.org/docs/app/building-your-application/routing/loading-ui-and-streaming 13
Copyrights(c) Henry, Inc. All rights reserved. HenryにおけるApp Router化の最大のボトルネックはルーティングにある。複雑なルーティ ングとブラウザバックをサポートしており、そのためにPages RouterのAPIと挙動に大きく
依存している(Viteからの移行時も苦労した)。これらのサポートがまだ弱いApp Routerへ の移行が困難となっている next routerのrouteChangeイベント (添付コード)や、next routerが window.history.stateに書き込む遷 移ごとのkeyに依存している。 Next.js 14時点では、App Routerで はこれらの代替手段が現状ない。 14 ルーティングに関するヘンリーの過去発表内容:https://note.com/henry_app/n/n4a56775fb382
Copyrights(c) Henry, Inc. All rights reserved. HenryにおけるApp Router化の最大のボトルネックはルーティングにある。複雑なルーティ ングとブラウザバックをサポートしており、そのためにPages RouterのAPIと挙動に大きく
依存している(Viteからの移行時も苦労した)。これらのサポートがまだ弱いApp Routerへ の移行が困難となっている。 next routerのrouteChangeイベント (添付コード)や、next routerが window.history.stateに書き込む遷 移ごとのkeyに依存している。 Next.js 14時点では、App Routerで はこれらの代替手段が現状ない。 15 ルーティングに関するヘンリーの過去発表内容: https://note.com/henry_app/n/n4a56775fb382 【朗報】 Next.js 14.1で、nativeのpushState利用がサポートされた模様。 詳細見れていないが、ルーティング周りの柔軟性が上がり、 Pages Routerからの移行の裾野が広がった可能性あり https://nextjs.org/blog/next-14-1#windowhistorypushstate-and-wind owhistoryreplacestate
Copyrights(c) Henry, Inc. All rights reserved. まとめ 1. ViteからNext.js Pages
Routerへの移行はスムーズにでき、性能的も良くなったしトレンドとも 整合しててよかった 2. ルーティングをフレームワークのAPIや振る舞いを利用してカスタマイズしておりApp Router 化に苦しんでいるが、pushStateサポートなども来ておりNext.jsの今後に期待 a. とはいえ、仮にフィジビリティがあっても書き換えが大変なのは間違いない 16
Copyrights(c) Henry, Inc. All rights reserved. WE ARE HIRING! 私たちは、ヘンリーのミッションに共感する
新しいメンバーを求めています。 • 個人個人に合わせた勤務時間とフルリモート可で、 半数以上のメンバーが育児と仕事を両立しており、 海外からの勤務も可能です。 • 社員以外にも、フリーランスや副業などで 多くのスペシャリストが参加しています。