Copyrights(c) Henry, Inc. All rights reserved. フロントエンド パフォーマンスの変遷と Next.jsに見る次の時代

Copyrights(c) Henry, Inc. All rights reserved. 自己紹介 @sumiren_t （発音：すみれん） ● プロダクトエンジニア @ 株式会社ヘンリー ● 技術顧問 / SRE @ 副業 3社様〜 1

Copyrights(c) Henry, Inc. All rights reserved. 会社名 株式会社ヘンリー 事業概要 電子カルテ／レセプト会計システム “Henry” を開発・販売及び、 コンサルティング事業 所在地 東京都品川区東五反田２丁目９ −５ サウスウィング東五反田 3F 創業 2018年5月 代表者 逆瀬川 光人、林 太郎 社員数 50名（正社員）+業務委託 認証取得 ISMS 国際規格「ISO 27001」 医療ISAC規定認証 Mission 社会課題を解決し続け、より良いセカイを創る Service 電子カルテ / レセプト会計システム「Henry」 株式会社ヘンリー ｜社会課題の解決を目的に設立 2

Copyrights(c) Henry, Inc. All rights reserved. 3 本日のスコープ ● 話す ○ フロントエンドパフォーマンスの視点から、アプリケーションアーキテクチャを振り返る ○ Next.jsのような先端フレームワークを使って今後どうなっていくのか議論する ● 話さない ○ フロントエンドのプログラミングパラダイムの変遷 ○ INPなど画面表示以外のパフォーマンス ○ クラウドインフラのアーキテクチャやエッジロケーション、エッジランタイム ○ Server ActionsやRSC ○ ヘンリーの事例 ● 注意点 ○ ※登壇者の思いや洞察を一定程度込めているため、ファクトと解釈が混在する部分があります。情報の正当性は各位 の責任でご判断ください ○ ※視聴者様としてフロントエンド初心者の方も想定しているため、あえて専門用語を使わず平易な言葉や独自の用語で 書いている箇所がございます

Copyrights(c) Henry, Inc. All rights reserved. 4 フロントエンドアーキテクチャの変遷 レンダリング アーキテクチャ ブラウザリロード（初回表 示） ブラウザサイドナビ ゲーション 画面内に閉じる操作 レガシーMPA SSR SSR SSR レガシーMPA + Ajax SSR SSR JS fetch/DOM更新 SPA CSR CSR JS fetch/DOM更新 Next.js（など） SSR or Prerendering CSR JS fetch/DOM更新 次世代Next.js Streaming SSR & Partial Prerendering CSR JS fetch/DOM更新

Copyrights(c) Henry, Inc. All rights reserved. 5 レガシーMPAのペイン レンダリング アーキテクチャ ブラウザリロード（初回表 示） ブラウザサイドナビ ゲーション 画面内に閉じる動き レガシーMPA SSR SSR SSR レガシーMPA + Ajax SSR SSR JS fetch/DOM更新 SPA CSR CSR 同上 Next.js（など） SSR or Prerendering CSR JS fetch/DOM更新 次世代Next.js Streaming SSR & Partial Prerendering CSR JS fetch/DOM更新 本質的にブラウザリ ロードと同等 遅い フェッチのある操作につい て、画面の状態をサーバー 上でシミュレートして SSR するのはキツい

Copyrights(c) Henry, Inc. All rights reserved. 6 レガシーMPA + Ajaxによる改善 レンダリング アーキテクチャ ブラウザリロード（初回表 示） ブラウザサイドナビ ゲーション 画面内に閉じる動き レガシーMPA SSR SSR SSR レガシーMPA + Ajax SSR SSR JS fetch/DOM更新 SPA CSR CSR JS fetch/DOM更新 Next.js（など） SSR(Prerendering) CSR JS fetch/DOM更新 次世代Next.js Streaming SSR & Partial Prerendering CSR JS fetch/DOM更新 ブラウザサイドでDOM更新す ることで複雑な Webアプリが作れるように

Copyrights(c) Henry, Inc. All rights reserved. 7 レガシーMPA + Ajaxのペイン レンダリング アーキテクチャ ブラウザリロード（初回表 示） ブラウザサイドナビ ゲーション 画面内に閉じる動き レガシーMPA SSR SSR SSR レガシーMPA + Ajax SSR SSR JS fetch/DOM更新 SPA CSR CSR JS fetch/DOM更新 Next.js（など） SSR(Prerendering) CSR 同上 次世代Next.js Streaming SSR & Partial Prerendering CSR 同上 辛さが減ったとはいえ、 手続き的なDOM操作を ブラウザ側で書くのは やはり辛い（jQuery地獄など） ここがページ全体の読み 込みになる問題が未解決 なのが大きい

Copyrights(c) Henry, Inc. All rights reserved. 8 SPAによる改善 レンダリング アーキテクチャ ブラウザリロード（初回表 示） ブラウザサイドナビ ゲーション 画面内に閉じる動き レガシーMPA SSR SSR SSR レガシーMPA + Ajax SSR SSR JS fetch/DOM更新 SPA CSR CSR JS fetch/DOM更新 Next.js（など） SSR or Prerendering CSR 同上 次世代Next.js Streaming SSR & Partial Rendering CSR 同上 ローレベルなアーキテクチャは変わっていないが、 UI = f(state)により宣言的に書けるように 空のindex.htmlを配信し全ての画面 をJSで構築。画面間の遷移が DOM 書き換えのみとなり高速化

Copyrights(c) Henry, Inc. All rights reserved. 9 初回表示以降は改善されたが...？ SPAのペイン レンダリング アーキテクチャ ブラウザリロード（初回表 示） ブラウザサイドナビ ゲーション 画面内に閉じる動き レガシーMPA SSR SSR SSR レガシーMPA + Ajax SSR SSR JS fetch/DOM更新 SPA CSR CSR JS fetch/DOM更新 Next.js（など） SSR or Prerendering CSR 同上 次世代Next.js Streaming SSR & Partial Rendering CSR 同上 データフェッチがブラウザサイドに 統一され、FCPが速くなった代わり に、LCPは遅くなった FCPが速くなったのもデータフェッチ を後ろに回しただけであり、 FCPに 到達プロセスはむしろ煩雑化してい る

Copyrights(c) Henry, Inc. All rights reserved. 10 SPAのペイン 図解補足 レガシーMPA SPA データフェッチ HTML生成 リクエスト受信 200ms 300ms HTML 表示 空のhtml配信 JS配信 JS実行・ 初期表示 350ms データフェッチ （ネットワークオーバーヘッドあり） 200ms 空のhtml表示 ※数値はイメージです JS実行・ DOM更新 500ms レガシーMPAではほぼ FCP=LCPだった クライアントサイドフェッチに統一されて FCPが速くなっ たが、あくまでデータフェッチを後ろに回しただけで、 FCPまでのプロセスに4ステップかかっていて無駄が 多い また、ブラウザとサーバー間を何度も 行き来することでデータフェッチが遅 れ、LCPは遅くなった

Copyrights(c) Henry, Inc. All rights reserved. 11 Next.js ! レンダリング アーキテクチャ ブラウザリロード（初回表 示） ブラウザサイドナビ ゲーション 画面内に閉じる動き レガシーMPA SSR SSR SSR レガシーMPA + Ajax SSR SSR JS fetch/DOM更新 SPA CSR CSR 同上 Next.js（など） SSR or Prerendering CSR JS fetch/DOM更新 次世代Next.js Streaming SSR & Partial Prerendering CSR JS fetch/DOM更新 Next.js自体は2016年か らある。2020年あたりか ら強くなってきた（遅咲 き？）。 MPAのように初回レスポンス時にサーバーサ イドでフェッチとReactをレンダリングを行い、 完成形のHTMLを返せるように。これにより数 ステップで初めてFCPとなる無駄と、LCPの遅 延を削減（SSR） SPAのようにクライアントサイドフェッチに寄せる設計の場 合、さらにFCPが強化。サーバーサイドでの Reactレンダリ ングをビルド時に行うことで、実行時の Reactレンダリング の時間を削減(Prerendering) ただしMPAとは違い、初回表示以外 はSPAと同じアーキテクチャを維持。 SPAの強みは全て踏襲。

Copyrights(c) Henry, Inc. All rights reserved. 12 まだ進化するのか...？ レンダリング アーキテクチャ ブラウザリロード（初回表 示） ブラウザサイドナビ ゲーション 画面内に閉じる動き レガシーMPA SSR SSR SSR レガシーMPA + Ajax SSR SSR JS fetch/DOM更新 SPA CSR CSR 同上 Next.js（など） SSR or Prerendering CSR JS fetch/DOM更新 次世代Next.js Streaming SSR & Partial Prerendering CSR JS fetch/DOM更新 SSR（サーバーサイドフェッチ）に倒すと、どうしても FCPはSPAよりやや遅く なる。かといってSPAライクにクライアントサイドフェッチすると LCPが伸び る。いいとこ取りができたら最高

Copyrights(c) Henry, Inc. All rights reserved. 13 次世代Next.js - Next.js App Router🔥🚀 レンダリング アーキテクチャ ブラウザリロード（初回表 示） ブラウザサイドナビ ゲーション 画面内に閉じる動き レガシーMPA SSR SSR SSR レガシーMPA + Ajax SSR SSR JS fetch/DOM更新 SPA CSR CSR 同上 Next.js（など） SSR or Prerendering CSR JS fetch/DOM更新 次世代Next.js Streaming SSR & Partial Prerendering CSR※ JS fetch/DOM更新 さらに、データフェッチをサーバーで行う画面であっても、確定して いる画面パーツはビルド時点で判断して Prerenderingしておくこと で、レスポンス速度を最適化 （Partial Prerendering、2024年3月時点でexperimental） ストリーミングにより、データフェッチをサーバーで行いつつ確定し ている画面パーツを返せる。これによりフェッチを待たずに FCPを 達成しつつ、ラウンドトリップは 1回に抑えLCPも短縮する （Streaming Server Rendering） ※：厳密にはSSRを含みますが、RSCの範囲のため割愛します

Copyrights(c) Henry, Inc. All rights reserved. 14 一周回ってレガシーMPAに似た形になったが、 差は歴然 レガシーMPA Next.js App Router データフェッチ HTML生成 リクエスト受信 200ms 300ms データフェッチ 確定しているHTMLを ストリーミングで返す 10ms response HTML生成 データフェッチ HTML生成 できたところから ストリーミングで返す ※数値はイメージです 250ms 初回表示時の動きについて、 FCPは圧倒的に速くなり、 LCPまで短縮されている

Copyrights(c) Henry, Inc. All rights reserved. 15 一周回ってレガシーMPAに似た形になったが、 差は歴然 レガシーMPA Next.js App Router データフェッチ HTML生成 リクエスト受信 200ms 300ms データフェッチ 確定しているHTMLを ストリーミングで返す 10ms response HTML生成 データフェッチ HTML生成 できたところから ストリーミングで返す ※数値はイメージです 250ms 初回表示時の動きについて、 FCPは圧倒的に速くなり、 LCPまで短縮されている 初回表示以降のSPAの強みも全て維持

Copyrights(c) Henry, Inc. All rights reserved. 16 余談：認証アーキテクチャも1周回ると予想 認証アーキテクチャのトレンド 解説 レガシーMPA サーバーサイドステートフルセッション レガシーMPA + Ajax SPA ブラウザサイドステートレストークン バックエンドをステートレス APIにするトレンドにより、認証状態をサー バー側に持たず、トークンの検証のみで認証できる JWTを Authorizationヘッダに入れる設計に。 IDaaS利用がスタンダードに Next.js（など） 次世代Next.js サーバーサイドステートフルセッション 1ラウンドトリップで初回表示とサーバーサイドデータフェッチ開始を実 現するには、Cookieに認証情報が含まれている必要あり。 HttpOnly にするにはサーバーで認証情報を発行するのが安全。 どうせサーバーが認証状態管理の責務を持つなら、ステートフルなセッ ションに戻すほうがシンプル。 expireを伸ばしたり強制expireも柔軟に やりやすく、トークン検証もローテーションも不要。 IDaaSを拡張したセッション as a Serviceが流行ると予想。

Copyrights(c) Henry, Inc. All rights reserved. 17 Next.jsはSPAの強みを活かしつつ、 SSRやPrerenderingや Streaming SSRやチャンク分割を活用して、 めちゃくちゃ創意工夫して サイトパフォーマンスを実現している まとめ

Copyrights(c) Henry, Inc. All rights reserved. Thank you We are hiring!! https://henry.jp/ https://dev.henry.jp/ 技術ブログやってます 18