サーバーサイドレンダリングについて、改めて勉強し直してみる
サーバーサイドレンダリング（以下 ssr）についての知見がふわっとしているので、改めて勉強し直してみます。
ssr とは
この記事がわかりやすいです。
「サーバーサイドレンダリング」とは一体なんでしょうか？混乱を避けるため厳密な説明は避けますが、少なくとも私たち Web デベロッパーのここ数年の文脈においては、 「(元々ブラウザ上でしか動かなかった)JavaScript をサーバー内部で実行して、HTML を生成すること」を指します。
なるほど？
でもまだピンときてません、多分そもそもクライアントとサーバーの間で行われているリクエストのフローが理解できていないからだと思います。
ssr と クライアントサイドレンダリング（以下 csr） の違い
この記事がわかりやすいです。
なるほどー。
シンプルに HTML/CSS/JacaScript のみで動くアプリケーションの場合
上記の記述っぷりは多少引っかかりますが、言いたいことはよくわかりますし、このケースが書いてあるのでとてもすんなり理解できました。
上記のケースがいわゆる静的（static）なサイト、つまり url ごとに html ファイルが切られているケースなんですかね？
ssr = static だと思っていたんですが、自分の認識は全く間違っていたみたいです。
ssr のメリット
よく聞くのは、以下の 2 つなイメージです。
- 初回レンダリングが早い
- seo に強い
一つずつ考えていきます。
初回レンダリングが早い
ssr では、サーバー側の Nodejs の上で JavaScript を実行して html を生成してそれをクライアント側に返すみたいなので、確かに早そうです。
初回のレンダリングについては理解できたんですが、2 回目以降のレンダリングはどうなるんですかね？
spa の場合と static な場合で全く挙動が異なりそうなんですが。
spa と static の違い
この記事に答えが書いてありました、図付きでとてもわかりやすいです。
想像通り、サーバーで html ファイルを単数持つのか、複数持つのかの違いがあるみたいです。
改めて、初回レンダリングが早いというのは
csr の spa よりは、ssr の方が早いよって感じみたいです。
csr の static なケースとかはどうなんだろう。
そう考えると、csr の spa ってかなり遅そうな印象です。
引っかかってるポイント
この記事によると、
サーバ側で React Component のビルドを行い、初回の HTML 生成（レンダリング）をサーバ側で行うことをサーバサイドレンダリング(SSR)と呼びます。
ということは、2 回目以降もサーバー側でレンダリングする場合は ssr と呼ばない…？
ちょっと頭がこんがらがってきました。
seo に強い
twitter とか facebook とかは、確か js ファイルをクロールしてくれないみたいなことを聞いたことがあります。
よって、クローラがサーバーに対しリクエストを要求した時、static なサイトは言わずもがな、html だけを返す ssr も url ごとの meta データが送られるってことですかね？
ちょっと中途半端な記事になってしまいましたが、なんとなーく理解できてきました。
今の自分の知識でまとめてみると、
- サーバー側で JavaScript を実行してクライアント側に html を返すのが ssr
- クライアント側で JavaScriot を実行するのが csr
- url ごとに html ファイルが切手ある場合は static
- html ファイルがエントリポイントにしかないのが spa
- ssr = spa でないという認識は間違い
これくらいは理解できました、なるほどなぁ。
加えて、個人的な感想としては、
- csr の spa は確かに遅そうだけど、code splitting したら大したことないんじゃないの？
- url ごとに seo 対策が必要なケースでも、必ず ssr をしなきゃいけないということはないと思う
- 経験上、ssr なサイトを作るのは、やっぱり大変
- やっぱり ssr はいらないんじゃないのって思った（小並）
- 今のとこ最強なのは static かなぁと…gatsby も react-static も nextjs もそうだし
- twitter や facebook の seo を気にしないなら spa で十分
って感じです。
まだふわっとしていることも多いんですが、今日はこのくらいで。