Next.jsメモ
sakuNext.js - Linkとナビゲーション -
こちらのドキュメントを改めて読んでいる。
以下自分の主観・意訳も含む（認識違ってたら指摘お願いします）
最近話題になっているRemixの方がWeb標準だ〜とか言われるけど（自分も正直Web標準に関して詳細には理解していない）、Next.jsはページ内リンクをWeb標準のリンク要素（こういう使い方でいいのかな？）であるaタグではなく、Linkコンポーネント（Link API）を使用する。
厳密にはaタグも使える？？けど、Next.jsとしてLinkタグの使用を推奨してる。なぜならLinkタグはNext.jsが独自に最適化した仕組みで、Next.jsを選定したユーザーの体験を最適化できるものだから。
このLinkとナビゲーションの概念を理解するには以下の概念も合わせて知っておく必要がある。
- Next.jsのレンダリング
- プリフェッチ
- ストリーミング
- Client-side transitions
次へ続く =>
sakuNext.jsのレンダリング
Next.jsのレンダリングについて、詳しくは公式ドキュメントや有難いことに同じくZenn上に上がっている「Next.jsの考え方」を読んだいただくことをオススメします。
ここではざっくり自分の理解だが、Next.jsは基本的に3つのレンダリングが可能である。
いやもしかしたら4つ？5つ？かもしれない。ここは自信ない。
ただ自分の知る限りは以下の感じかなと
- SSG
- ISR
- SSR
他にも、CSRとかPPRとかもできる。
※ 'use client'などを使用する => CSR（この認識だと色々不足してそうだけど）
※ PPR = やり方忘れたけど、Next.js v14系？くらいから実験導入されてる
ひとまず主要レンダリングがSSG・ISR・SSRだと仮定すると、Next.jsかなりサイト・アプリパフォーマンスやSEOなどに強いと言われるのもなんとなくわかるし、フレームワークとしての思想もそっち寄りのものなのかな？と思う。
SSG・ISR・SSRは使用場面などでカテゴリ分けすると、以下の感じかと思う。
SSG・ISR => 静的（最新情報でなくてもいい場合）
SSR => 動的（情報の鮮度が重要）
静的と動的なレンダリング性質を併せ持つNext.jsだけど、共通するのはサーバー処理があることである。SSGとISRはビルド時・再検証時・キャッシュ切れ時、SSRはコンテンツ更新時とかの違いはあれど、基本的にサーバーでレンダリングされる。
次へ続く =>
sakuNext.jsのレンダリング2
だいぶ脱線気味で若干疲れましたが...
基本的にNext.jsがサーバーを使用し処理をしているというつながりで、"RSC" 、いわゆるReact Server Componentという概念もよく関わっているっぽい。正直自分は理解が足りないのでここはうまく書けない...字の如くいくと、サーバーで処理されるReactのコンポーネントということだろうか。
このRSCがNext.jsではどのように動いているかだけど、RSCペイロードという形で、サーバーから手順書みたいに分割ストリーミングされる。
この分割ストリーミングされるというのが、従来のSSR（サーバーでHTMLを作成して返す）とは異なる。（Next.jsでも初回は返すんだっけ...？自信無くなってきた）
本日はもう眠いのでこの辺で。
次へ続く =>
sakuプリフェッチ
以下を前述したが、具体的にNext.jsが推奨するLinkコンポーネントがどのように最適化されているのか、その代表例がプリフェッチという概念だと思う。
厳密にはaタグも使える？？けど、Next.jsとしてLinkタグの使用を推奨してる。なぜならLinkタグはNext.jsが独自に最適化した仕組みで、Next.jsを選定したユーザーの体験を最適化できるものだから。
プリフェッチとは、Astroなど他フレームワークでも出てくる概念ではあるが、なんだろうか。
時から推測すると、プリ（前もって） + フェッチ（取得）的な感じで、何かを前もって取得するのだろう。
Linkコンポーネントにおいて、その"何か" というのは、そのLinkコンポーネントを使ってナビゲートされる先のページ/画面の情報である。
通常のaタグの遷移では、ページをフルロード（同ページ内リンクは除く）が、Next.jsのLinkコンポーネントの場合、Linkコンポーネントがビューポートに入ったタイミングで前もって遷移先画面の情報を取得している。このロジックのおかげで、遷移後の画面表示が著しく速くなり、これがユーザー体験をよくさせる。
今更ながら、よく考えるものだなとすごく思った。画面を早く表示する為には、大きく2方向あると思っていて、以下かなと思った。
- 表示速度自体の改善（色々やり方はあると思う）
- 表示コンテンツの取得タイミングを早める
私の場合は、おそらく前者の方を思って、画像などの大きいオブジェクトを最適化したり、不要コード削除したりしてしまうと思う。それ自体は決して無駄ではないと思うが、よくよく考えれば後者のアプローチもあるなと思った。
このプリフェッチはLinkコンポーネントを使用したらデフォルトでtrueになっていて、場合によってはfalseにすることもできる。
ユーザーが画面を見れるようになるための、表示速度自体は増すが、当然ながら裏でプリフェッチというネットワークを使用した処理が走ってるので、先取り取得する必要性が薄いコンテンツまで全てtrueにすると、プリフェッチしただけになってしまい、リスクもある。
次へ続く =>
sakuNext.jsとVercel
何となくでしか使用してなかったが正直相性がよすぎる。
というのもそう感じる理由は、主に以下
- Next.jsのレンダリング（SSGやSSR、ISR）に設定無しで対応してる
- Vercelにデプロイする前提のパッケージが多々ある
正直、まだ走りたての個人開発やスタートアップでNext.jsとVercelがセットで使用されるかが分かった気がする。
Next.js自体が独自のAPIが多く、それらを使いこなせればだいたい何でもできるという便利さがあるが、それのほぼ大体に対応してるインフラが少ない気がする。Vercelはそれらに最適化されてるので、何も考えないでも使えてしまう、便利さと怖さがある。
但し、商用で使用するには機能が少なかったり、料金が固定で高かったりするので、意地でもCloudflareなどに乗せる気持ちも理解できる。