こんにちは。
今回はnext.js 13を扱うにあたって、
レンダリングが実際どのように動いているか
ちゃんと把握出来ていない人も
しっかりここを把握しておこうということで、
初心者にも分かりやすく、
そして自分のまとめ用にこの記事を進めていこうと思います。
多少遠回りをしますが、
next.jsの概念とレンダリングの仕組み
が本記事で理解できると思います。
この記事は、
この後の「next.js 13でmiddlewareを使ってログイン機能を実装する」
というところの導入にもなるので、
理解しておいて損はありません。
クライアントサイドナビゲーションとは何か？
まずはnext.jsがどうゆうものなのかを説明するために、
少し遠回りをしようと思います。
next.jsのレンダリングの理解に
クライアントサイドナビゲーションはかかせません。
クライアントサイドナビゲーションとは、
Webアプリケーションにおいてページ間を移動する際に、
サーバーへのリクエストを行わずに行うナビゲーションの方法です。
これは、
複数のページを持つアプリケーションで、
最初のページの読み込み時に
他のページの情報もサーバーから読み込み、
クライアントサイドに保存することで可能にします。
これは、
SPA(シングルページアプリケーション)でよく使用され、
ページの遷移が速く感じられることや、
サーバーへの負荷を減らせることなど、
メリットがあります。
一方で、
これだと、最初のページのロード時の読み込みデータ量が多いので、
当然初回ロード時のロード時間は大きくなってしまいます。
それを解決する鍵となるのが
SSR(サーバーサイドレンダリング)です。
SSRとは？SSRは何故速いのか？
SSR(サーバーサイドレンダリング)。
サーバーサイドレンダリングとは、
クライアント側（ブラウザ）ではなく、
サーバー側でHTMLコンテンツを生成する手法です。
具体的には、
ユーザーがWebページにアクセスするとそのリクエストはサーバーに送られ、
サーバー上でアプリケーションが実行され、
生成されたHTMLがクライアントに送信されます。
これをすると何がいいかというと、
- サーバーは高性能なCPUやより速いメモリ、高速なI/Oを備えており、
複数のリクエストを並行して処理する能力がある。 - サーバーは通常、バックエンドのデータベースやAPIに近い位置にあります。
これにより、サーバーがデータを取得してHTMLにレンダリングする過程で発生する
ネットワーク遅延を削減できる。
つまり、JS → HTMLに変換する作業(レンダリング)は、
サーバーの優秀なコンピュータを使った方が早いということです。
ここで、
１番最初に話したクライアントサイドナビゲーションを思い出すと、
SPAを作るうえで、１番最初だけSSRでページ１、ページ２、ページ３
などのコンポーネント情報をとってきて、
あとはクライアントサイドナビゲーションで画面遷移すれば、
最速を実現出来るんじゃないかな。
クライアントサイドナビゲーションは、
初期ロードの時間コストが問題になっているのだから。
つまり、
最初の時間のかかる作業だけ、
SSRに任せて、あとはクライアントサイドナビゲーションを使う
という合わせ技です。
この考えはとても理にかなっていました。
その結果、
この考えをデフォルトでやろうとしているのが、
Next.js です。
Next.js は何を可能にしたのか。
では、
これによって何のメリットを得られたのかそれぞれまとめます。
SSRによる初期ロードの高速化は、次のような利点をもたらします：
- ファーストビューの高速表示：ユーザーが最初にウェブサイトにアクセスしたときに、すぐにコンテンツが表示されるため、エンゲージメントが向上します。
- SEOの強化：検索エンジンはレンダリング済みのHTMLコンテンツをより効率的にクロールし、インデックスすることができます。
一方で、クライアントサイドナビゲーションは、以下のメリットを提供します：
- 迅速なページ遷移：必要なHTMLやデータは既にクライアント側にあるため、ページ間を移動するときにサーバーにリクエストを送る必要がなく、遷移が速くなります。
- リソースの節約：サーバーに何度もリクエストを送らないため、サーバーのリソースを節約できます。
- ユーザー体験の向上：ページ遷移の際にページ全体をリロードする必要がないため、ユーザー体験が向上します。
これによって、
SSRを初回ロードに使用し、
その後のインタラクションはクライアントサイドナビゲーションで行うことで、
ロード時間の短縮とリッチなユーザー体験の両方を実現することができるようになりました。
ただ、
これだとちょっと複雑な実装になってしまうので、
デフォルトでこれをやろうとしているのがNext.jsなわけです。
ここからは、
本記事一番重要なレンダリングの概念。
Next.js 13のレンダリングはどのようにして行われているのか？
について話していきます。
Next.js 13のレンダリングはどのように行われているのか。
まず一つ疑問を解決させておきます。
next.jsがSSRとクライアントサイドナビゲーションのいいとこどり
なのは分かったけど、
本当に、初回ページロード時に他のすべてのページを読み込むのは
効率がいいと言えるのか？
です。
当然最初にSSRでたくさん読み込んだページの中には、
ユーザーが訪れないページも沢山あるので、
それは無駄なロードと言えます。
そんなことをしているのかという疑問です。
Next.js 13は、初回ページロード時にすべてのページを読み込むのか？
ここが一番重要なのですが、
答えはNoです。
Next.js 13のSSRでは、
訪れた特定のページのコンポーネントのみをサーバー側でレンダリングし、
その結果のHTMLをクライアントに送ります。
これを具体的に説明すると、
ユーザーの初回ロード時(/ページなどへのアクセス時)に、
next.js 13 はその特定のページ(ここでは/ページ)の情報のみをＳＳＲします。
そこからの画面遷移は、
画面遷移先のコンポーネントがすべてクライアントサイドのキャッシュにある場合、
クライアントサイドナビゲーションを行いますが、
そうでない場合は、
必要な情報をサーバーからとってくる必要があります。
どうゆうことかというと、
初回ページ(/)がコンポーネントa,b,cで構成されているとき、
コンポーネントa,b,cはクライアントサイドにキャッシュとして保存されます。
そして、遷移先ページがコンポーネントb,c,dで構成される時、
ページ遷移時の動作は、
コンポーネントbとcはクライアントサイドのキャッシュからとってきて、
コンポーネントdはサーバーサイドからとってくる必要があります。
つまり、
従来のクライアントナビゲーションは
画面遷移がクライアントサイドで完結していたのに対して、
Next.js 13でのクライアントサイドナビゲーションは
大体がサーバーから情報をとってくる必要がある点、
大きく異なります。
ここが重要なポイントです。
Next.jsでは大体の初回画面遷移時、
サーバーを経由します。
サーバーサイドコンポーネントとクライアントサイドコンポーネント
上記で、
「コンポーネントdはサーバーサイドからとってくる必要があります」
と言いましたが、
これはクライアントサイドとサーバーサイド、
どちらでレンダリングされるのでしょうか？
答えは、
「自分で決めることが出来る」です。
コンポーネントには、
クライアントサイドコンポーネントと
サーバーサイドコンポーネントがあるので、
どちらとして記述するかで、
画面遷移時にどちら側でレンダリングするか決める事が出来ます。
具体的には、
デフォルトで普通にコンポーネントを書くとＳＳＲが行われます。
けれど、
コンポーネントの一番最初(importよりも前)に
“use client”ディレクトリを加える事で、
これはクライアントサイドコンポーネントとなり、
クライアントサイドでレンダリングされます。
まとめ
Next.js がどうゆう機能を持ったものなのか、
少しでも理解に近づけたら幸いです。
以下は、
今回の記事の重要なポイントをまとめます。
Next.js 13では、
- 画面遷移毎に大体サーバーから必要最低限の情報をとってくる必要がある。
- １度訪れたページはクライアントサイドのキャッシュに保存されるため、
従来のクライアントサイドナビゲーションが起こる。 - これをまとめると、
１度訪れたページに戻ったりするDocument、解説ブログなどが相性いいかも。 - ＳＳＲの方が、レンダリング速度は速い。
次回は、この基本を元に、
「firebaseを使ったログインによるトークン認証をmiddlewareで実装」
をしていきます。
宜しくお願いします。
コメント